Re: Euphoria features
Jason Gade wrote:
>Yes, but one must think "outside of the box" (I *love* that cliche) in
>regards to data types. Sequences can both represent structured data and
>unstructured data. It is up to the programmer to clear up the ambiguities.
>And using constants isn't *that* hard! If you are making up
>structures/sequences that are *that* long then they need to be broken up
>into smaller bites (no pun); just like functions need to be broken up when
>they get too long.
If I have two or more files with the same field name in them, but in different
positions, constants just became a major source of difficult to avoid
error. Now, I have to think up two or more names for the identical field.
This is not only confusing, it is just flat wrong. Prefixing solves the
problem with no violence to content or meaning.
>
>Neither a proc/func nor a struct definition should take up more than say two
>pages in an editor. If they do, then they need to be broken down into
>smaller units.
Agreed, but the structures must be nested, or I will have to piece them
together at the time that they are used together, another code-expensive
and error prone task that has no purpose that I can think of.
>The cool thing about sequences is that they can contain other sequences.
>And even though it should be simpler in the language, you can always define
>sequences in a type for early version error checking.
Agreed, but remember the overhead problem. Type checking can be very
expensive outside of built in types...and even with built in types, if it is
over-used.
>Two ideas that I have had for OO sequences, without adding a lot of overhead
>are as follows:
>
>The first element of an object is the instance (from 1 on to ... )
>
>Then, sequence itself contains all of the elements of the object. Different
>functions in the include file return or execute various members or methods
>of the object. Simplicity within the Euphoria paradigm is the key, and this
>would eliminate the assignment or copy constructort.
>
> sequence Dungeon -- New variable
> Dungeon = NewDungeon() -- from include file
>
>The NewDungeon() function will return a sequence containing the instance of
>the variable, and then all of the elements.
>
>The other idea is to use static sequences within the include file to keep
>track of various properties of an object and use the instance variable to
>track which element the programmer is referring to. Of course, then the
>programmer would have to write her own assignment and copy constructors.
>That would bypass the efficiency of sequences, unless the data is static to
>the class and not to the instance, of course.
>
> hit_points = GetPlayerHP(rogue)
>
>This would set the object hit_points to whatever GetPlayerHP returns for
>that variable.
>
>It doesn't matter if the elements are contained in the object itself or
>within static variables indexed by instance within the include file. It is
>up to the programmer. As long as the documentation or the code is clearly
>written ...
Can't begin to say that I understand exactly all of this, but I think that it
implies dynamic use of the interpreter to execute the elements of an
instance(did I get anywhere close to that?). We don't currently have that
capability, though I can think of 101 uses for it.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
