OpenEuphoria

Re: Eu improvements (part 4)

• Posted by Karl Bochert <kbochert at copper.net> Jan 05, 2007
• 694 views

c.k.lester wrote:
> 
 
> > My posts were about 2 features that might make me a Euphorian again:
> >   .  Pass By Reference
> 
> Don't know why this is needed. Can you give an example where PBR is required?
> 
Not needed, just desireable. The minor advantage is speed when dealing
with large sequences (we like Eu for its speed, right?) A much bigger
advantage is that it allows a flag to be returned cleanly.

> >   .  Structured Sequences
> 
> Yes. Gimme. :)
> 
> > not about OOP or ways to implement it.
> 
> Sorry, that was just a tangent I thought I was following you on! heh.
> 
A tangent that traps many on this list, I think.

> > With that in mind, I would ask those who disagree which category
> > they place themselves in:
> > 1) Good ideas, but flawed implementation
> > 2) I don't like PBR
> > 3) I don't like SS
> > 4) Both are instruments of the devil
> > 5) Irrelevant  -- Euphoria is perfect
> 
> I'm in the "Euphoria is perfect... and would be even more perfect with
> structured sequences!" :D
> 
> Adding structured sequences would not break anything, and would give us
> a more powerful language syntax but still keep it all simple.
>
And thid is not true of PBR?
 
> }}}
<eucode>
> type text(sequence s)
>    return is_all_ascii( s )
> end type
> 
> sequence Company is
>    text name
>    Address headquarters
>    --...
> end sequence
> 
> sequence automobile is
>      Company maker
>      text model
>      atom year
>    --...
> end sequence
> </eucode>
{{{

> 
> Although, I still don't like the use of static variable names. For example,
> what if we create a huge program with lots of includes and code and has the
> automobile.maker text all throughout but we want to change the definition to
> Company manufacturer at some point, thus breaking all that code (which now
> needs to be automobile.manufacturer)?
>
No different than occurs now when any other id is changed.
 
> Oh, well, this should all be in a database anyway. :)
> 
> How about instead of
> 
> sequence Company is
>    --...
> end sequence
> 
> we use
> 
> record Company
>    --...
> end record
>
> because that's really what it seems to be: a database record.
Wouldn't bother me!

KtB