Re: Euphoria features
-----Original Message-----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Friday, November 12, 1999 9:56 PM
Subject: Re: Euphoria features
>Jason Gade wrote:
>[...]
>>First off, I think that Euphoria is very cool the way that it is.
>
>Before going any further, I'll second this observation.
I'm glad that someone agrees!
>
>>The infamous construct of
>>
>> xy = get_position()
>> position( xy[1], xy[2] )
>>
>>should never have been begat. The most Euphorian solution should have
been
>>for position() to take a sequence as a parameter list instead of
integers.
>
>I agree. Alas, it's already been done. BUT... it might not
>necessarily be set in stone. I know Rob has opted to break
>old code before by introducing short-circuting to 'if'
>statements (I *still* don't understand why, but anyway.)
>So, there is somewhat shaky precedent to justify changing
>'position' and any other built-in functions to be more
>orthogonal. Fix it *before* Euphoria takes over the
>programming industry. Note, I'm not necessarily in favor
>of such a change; I'm just thinking about the
>ramifications versus benefits.
>
>>I am even thinking (though not convinced) that functions and
procedures
>>should *always* take one parameter, and that '&' should replace ',' as
a
>>parameter separator.
>
>!!!
>
>You know, this thought had occured to me recently as well,
>but I forced it aside. ("My, what an odd thought you are!
>Shoo, before someone notices you!") But honestly, I think
>it would have worked out very nicely had Euphoria been
>designed that way from the start; '&' in place of ','
>would have been all that was needed. (Well, okay, for
>those of you who would complain about the need to depress
>the shift key to make the '&' character, we can also
>imagine Rob had used ';' instead of '&' for
>concatenation...) Oooh, this thought is starting to
>really demand my attention... I think I'll have to sleep
>on it.
Orthogonal is very good for Euphoria. Repeat after me, "Functions and
Procedures must accept all arguments that make sense for that operation."
>
>>Although I don't know object orientation very well, I do believe that
>>Euphoria should lean in that direction.
>
>It does somewhat already, probably more than any of us
>currently realizes (keep reading....)
>
>>I think that the 'type' declaration can adequately handle structures,
but it
>>would be longer to program than in other languages.
>
>I agree, it works to an extent. The problems most
>people have with that method though are:
>
>1) You'd usually use constants to access the elements,
> and then you run into scoping problems again (and
> I admit, STRUCT37_NAME gets messy...)
>2) It's TOO flexible. You'd have a hard time setting
> up a structure that way that could be used to
> extract records of exactly x bytes in length,
> each consisting of exactly y fields (each being a
> specific number of bytes in length), from a file.
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.
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.
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.
>
>>I think that routine_id() is okay, but that it should be global.
>
>Mmm, I'm not settled either way with that...
>
>> It should be combined with variable_id() though, even though I
would loathe
>>to see pointers in Euphoria. It could be useful in overriding scope
when
>>necessary.
>
>Well, while this would be useful for a one-line swap function,
>I don't see much point in the pass-by-reference methodology it
>would bring about. Speed's not a concern since Eu usually just
>passes pointers. And I would think the desire to avoid the
>messiness of passing multiple variables through several levels
>could be removed by just redesigning the setup (i.e., use
>local variables rather than parameters.)
>
>I do agree with the 'no pointers' though.
>
>Oh, and I think I'll bring this up; if 'variable_id' ever
>*were* implemented, I'd be willing to bet that it would be
>limited to the current scope. 
I see routine_id() and variable_id() more in the way of scope
resolution/object orientation in order to publicize code and variables in
includes. I don't mean to use these constructs to globalize identifiers
that aren't meant to be globalized. Although a person could do so if she
chooses.
>
>>I can forsee a Euphoria in which most 'objects' are defined in
separate
>>include files that contain functions for working with that object.
>>Object-oriented, but not in the non-flexible way that most OO
languages are
>>defined.
>
>You know, I really don't see anything stopping us from
>programming in this manner right now. I guess in a sense,
>many libraries already do that somewhat (I know Picasso
>does, by lumping the routines into POLYGONS.E, TEXTURES.E,
>etc.) I guess no one thinks of it as OOP when achieved in
>such a 'raw' way; I know I often fall into the trap of
>thinking 'object-orientation' = 'elaborate framework'.
I agree with you in that we are not (much) prevented programming in OO
methods. Just a few back-breaking work-arounds that we must deal with, but
that OO is also probably much easier than the published OO libraries in the
archive would have one believe.
>
>>Sequences are very powerful, and I think that we haven't even
scratched the
>>surface yet in their utility.
>
>That's an understatement! 
>
>
>Rod Jackson
>
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 ...
J.
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
|
Not Categorized, Please Help
|
|
