1. Re: Implementing structures
Irv wrote:
>>If structures turn out to be slow, so be it. I bet they won't be =
slower than
>>QbaSick! The real question is: could structures be implemented with an
>>include file, or will it require RDS to hack the code?
Francis Bussiere has already put together a complete library ("Object =
Oriented Programming Example") that's available in the Euphoria Archive. =
It looks nice, but (please correct me if I'm wrong) it doesn't do type =
validation or handle structures inside of structures.
Let me see if I understand what you are asking for:
1. Ability to define sequences with structured elements.
2. Type checking for the elements.
3. Ability to re-use element names with different structures
4. Implemented as an include file.
Assuming that something like *this* is the optimal syntax:
myPoint.x =3D 11
myLine.point1.x =3D 32
x =3D myLine.point2.y
I can offer the following versions:
[Fairly Little Overhead]
myPoint =3D set( myPoint, ptX, 11 )
myLine =3D set( myLine, {lnPoint1, ptX}, 32 )
x =3D get( myLine, {lnPoint2, ptY} )
In this example, we are using sequences for the structures, and "real" =
Euphoria symbols for the element names. We can't name the elements 'X' =
or 'Point1', because of name conflicts - what if we include a library =
that also defines 'X' as an element (or variable).
[A Bit More Overhead]
myPoint =3D set( myPoint, "x", 11 )
myPoint =3D set( myLine, {"point1","x", 32 )
x =3D get( myLine, {"point2", "y"} )
or:
myPoint =3D set( myPoint, "x", 11 )
myPoint =3D set( myLine, "point1.x", 32 )
x =3D get( myLine, "point2.y" )
Here, we avoid name conflicts by having maintaining the identifiers =
ourselves. It's a bit more overhead, but not that much more than the =
original example. We still use Euphoria for assignment, so we get the =
automatic garbage collection.
[The Most Overhead]
set( "myPoint.x", 11 )
set( "myLine.point1.x", 32 )
x =3D get( "myLine.point2.y" )
Finally, this example shows the routines maintaining all the structures. =
Not only is this the most amount of overhead, but it is up to the =
programmer to deallocate structures created in routines.
Do any of these appeal to you (or other people)?
-- David Cuny
PS: When are you going to post your Win95 for DOS program? I'd *love* to =
take a look at it. I'm still working on the next release of my DOS =
window manager - I'm in the process of reworking it so a single BitBlt =
routine underlies all the graphic routines. Hopefully, I'll have another =
release ready next week.
