🚀 go-pugleaf

I've been passing all contributions to the template file format discussion
to Tim, he has asked me to post the following...
 
 
----------------------------cut--here-------------------------------------
 
Re:Glass files - a short addendum...
 
A few people have commented on the naming of icons and asked how the lookup
of icon names would work - a library? a relocatable module?
 
Now then, here I must confess to being a bit of a heretic - I'd always
thought that a constant header file would be generated and would be used
with the source (whether for C, ARM, BASIC, Pascal etc).  ie the
compiler/assembler would actually use the icon number directly (via a
#define) or in the case of BASIC, the interpreter would use the variable
contents to get the number.  There may be problems in getting this to work
with BASIC (I looked at using LIBRARY to do this - I think it's a
non-starter as it won't share variables) but there must be *some* way to do
it reasonably elegantly, and, as Dick Alstein pointed out, BASIC is handy
for small apps, and it's dead cheap (=free); I consider ensuring that the
format is usable by BASIC important.
 
There are two reasons why I don't think icon names should be used at run
time:
 
(1) It's inefficient. Just think about it - *every* time you change an
icon's contents, set its flags, read its selection state, decode a mouse
click - you go through a string look up table routine.  This may be
acceptable to some people, but not to me, because, well...see (2).
 
(2) What's the point?  Heretical, I know, but what do you actually gain by
being able to decode icon names at run time? If you change a name, the
source has to change too - so recompilation is necessary. If you change icon
names around, the program no longer works properly - so why do you need it?
Why not just leave it to the compiler/interpreter?  There's only one
instance I can think of that that might warrant it:
 
 You want to change the icon ordering - without string lookup this
 will require re-compilation.
 
But why would the *end-user* want to do this?  It would be a *very* minor
advantage for the programmer to be able to do this without re-compiling.
 
In summary, I don't consider the overhead (having to keep icon names in
memory, having to scan them for every icon access) to justify the additional
functionality (which I perceive to be zero). I am open to suggestion - if
anyone can think of any reason why run-time look up would be desirable, post
to this group - giving a convincing example! I am, as you may have divined,
somewhat sceptical, but I don't mind being proved wrong. Also, failing a
suitable alternative solution for BASIC, we might as well do it...
 
As to the suggestion of a module to support loading etc of Glass files -
this seems a good idea as it negates the need for specific prog.lang.
libraries, and avoids duplication of effort by co-resident applications.
Comments? Anyone against this?
 
Finally, thanks for the general tone of the comments on the format so far -
helpful, constructive and technically sound.  Keep it up :-)
 
Tim Browse.
 
PS. I know BASIC does a string lookup to access variables anyway, but
that's a side issue. I don't see that it warrants run-time look-up.
Unless you know better?
PPS.Stop press - I've just thought of a reason which may justify decoding
icons at run-time, but I want to see if anyone else thinks of it :-)
If you want a hint, have a look at Glazier's template file(s).
                                                           |
                                  this is a clue ! --------+
 
---------------------------cut--here---------------------------------------