Improvements
On Sat, 26 Aug 2000, Rob wrote:
> Derek Parnell writes:
> > this discussion reminds me to ask what plans do you
> > have for the next (and subsequent) release of Euphoria
> The translator will keep me busy for several more weeks.
> After that I'll do some namespace improvements,
> after consulting with this mailing list.
1. There's general agreement that we need to eliminate namespace collisions,
without breaking already existing code, if possible.
2. The proliferation of OOP add-ons shows that some variation of
the object-oriented approach is wanted by at least some of us.
Unfortunately, all of these efforts are made slower, more difficult
and syntactically awkward by the lack of access to Euphoria internals.
Here's my proposal:
1. The interpreter should append (internally) an indicator to each
global variable or routine which indicates which include file it came from.
When a variable or routine is referenced, if there is only one use of that
name, things work just as they do now..
If there is more than one like-named variable or routine, the most-recently
declared version is assumed, but a warning message (similar to the
unused variable message) is issued. For example:
mainprog.ex - line 39
coords = {10,20} <- referencing sequence coords from window.e
window.e - line 100
x = foo() <- referencing function foo() from button.e
That way, if the program doesn't act as expected, we have a clue as to what is
wrong, and once things work ok, we can turn off the warnings.
Suppose we want to override the default "most recently declared" rule, and
want to refer to the coords variable in button.e, not the one in window.e?
The alternatives include:
button.coords = {10,20} -- dot notation as in Pascal, etc. (one keystroke)
button->coords = {10,20} -- (minus,shift, > = 3 key strokes, no more meaning)
button~coords = {10,20} -- let's be different.
It's also _very_ useful to have a more concise notation for referencing
multiple vars, e.g.
with button do
coords = {10,20}
size = {400,200}
end with
or, button~
coords = {10,20},
size = {400,200}
You'll notice that this more or less emulates the dreaded "structure":
without calling it that. ;)
However, I'd really like to see this taken a step further:
Once we have a way to declare variables / functions / procedures with the
same name in more than one include, think how nice it would be if we could
declare multiple instances of things described in those include files:
-- button.e
global sequence coords, size, colors, text
global procedure show()
.....
-- window.e
global sequence title
global procedure show()
....
-- MyProgram.ex
include button.e as button -- kind of an improved "type" declaration
include window.e as window
button ok_btn, cancel_btn -- create 2 instances of each new improved "type"
window mainwin, about
ok_btn~size = {80,20} -- each instance has its own copy of the variables
cancel_btn~size = {120,20}
ok_btn~text = "%OK"
cancel_btn~text = "&Cancel"
mainwin~coords = {1,1} -- coords inherited from button.e
mainwin~title = "My Program"
about.~title = "About this program...."
Let's take this to its logical conclusion, and in the process, improve on the
usual OOP notation as follows:
show(mainwin)
show(ok_btn)
show(cancel_btn)
Note that there is a show() procedure declared in button.e, and another
different show() procedure declared in window.e,
Euphoria should be able to call the correct one based on information stored
in the instance passed to the call - i.e. show(mainwin) calls window.e show(),
while show(ok_btn) and show(cancel_btn) call the show() procedure in button.e.
No dot notation needed!
If there were no locally declared show() routine in window.e, however, then the
global procedure show() in button.e would be called, as button.e was included
before window.e. That wouldn't necessarily be a problem, but it might justify a
warning message.
Not having access to the internals of Euphoria, I don't know how hard it would
be to implement this, but I can't see anything impossible about it.
Regards,
Irv
|
Not Categorized, Please Help
|
|
