OpenEuphoria

RE: Pete: Your question

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Nov 05, 2003
• 556 views

Al Getz wrote:
> 
> Here's the "useful" example code:
> 
> 
> --file.e--------------
> global sequence Rect
> global sequence Button
> ----------------------
> 
> 
> --MyFile.exw---------------
> declare file.e as r1
> declare file.e as r2
> 
> r1:Rect={10,10,200,400}
> r2:Rect={20,20,200,400}
> 
> r1:Button={10,10,80,30}
> r2:Button={10,40,80,30}
> ---------------------------
> 
> 
> Havent you used structs in C?
> We dont have to go "r1:x:y:z:k:name=value"
> to use this feature.  We only need the
> one level "r1:variable=value".

This really seems like overkill, to include multiple instances of a 
library to be able to have multiple instances.  You seem to be insisting 
on using global variables from the files.  What's wrong with storing the 
data in a local variable?  Structures in C certainly don't require the 
executable code to be included/compiled multiply.

> >Why *deliberately* refer to two *different* x using the same name, 
> >no clues, when you can make it obvious which you mean?
>
> I explained that already, but it's simple:
>
> When you declare a local x in one include file and a local x in 
> another include file you dont want them to have the same value all 
> the time do you ???  The idea is to have the two x used for 
> different things, but you can still call them 'x' so that your 
> meaning in both files stays the same.  The idea is to keep the 
> meaning of the variable the same while being able to assign the 
> different local instances different values.  It's the same here, 
> although this intends to use a whole bunch of well structured 
> variables instead of just one at a time.
>
> There's nothing scary about it if you know how to use it, and it's 
> very simple to learn but you have to try.

First, you're using *global*, not *local* variables.  This adds a lot to 
the overhead of a program.  Let's assume that this is how your winclass 
library were written, and that I was writing a large app, where I was 
required to have, say, 100 extra includes (though I could imagine 
needing even more than that).  What a waste of resources, when all I 
needed was some extra local variables to store additional instances of 
widgets.

Second, this method is completely static (you can't robustly dynamically 
include files--i.e., it won't work when translated).  If this method is 
so important, then you should be able to easily make copies of your 
files to different names:

fileA.e becomes:

fileA1.e
fileA2.e
...etc...

...and you include them only in the fileA*.e form:

include fileA1.e as a1
include fileA2.e as a2

You still have only one file to maintain (the original fileA.e), and you 
don't have to rely on any tricks to get them all included as separate 
instances of the same code.

If you need lots of instances or need them to be dynamic at run-time, 
then you're better off with a different design, using the id/instance 
paradigm.  IMHO, you'd be better off with that design anyways, since 
it's more scalable.

What you're really after is OOP, or at least certain aspects which are 
actually quite easy to implement already, as Pete has sort of 
demonstrated.  You simply store the instance data in sequences and use 
an id to refer to it.  Then every access has an additional subscript 
access, but for most operations this will be negligible.  It's then 
possible to optimize for the cases where that's important.

Matt Lewis