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.
>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.
>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.
>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 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'.
>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
|
Not Categorized, Please Help
|
|
