1. Idea for NameSpace-problem
There is this idea I already have for a couple of years and it would sove
the name space problem, althrough I figured that it would be very
impracticle for performace, because of the advanced management that has to
be done.. i got this idea, finding a way to -context sensitive- program.
Here it goes:
- An item is a combination of a two procedures and a function. It can be
sent ONE value and receive ONE value. An variable in Euphoria works the same
way: you initialize it with a value (first procedure), you set/sent a value
(second procedure) and you read/receive a value(the only function). Only
with such variables you can be sure when you set it to, for example 100, it
will also return 100. Off course this depends on the purpose of an item.
- A program is also an item, the first time the program starts the
init-procedure is called, then when for example a second document is opened
the set-procedure is called. (Like DDE in windows does).The init-procedure
gets the command line as its value. the set-procedure gets the filename in
this example and the gets-function returns a status value (like "abort(65)"
does). Ussually the init procedure doesn't do much, and the set procedure is
the real program, however there are situations where you a different
procedure for another instance of a program is a real advantage.
- The program item is the parent item. All other items are his direct
children.
- These children can make either brothers (items on their own level) or
childrens.
- Childrens are completely hidden from their aunts,uncles and grandparents.
They can not be called by them, nor call them themselves. They can only have
contact through the parent. They 'filter' / 'passthrough' everything. It is
only available so can make sure no one else has acces to those items. (the
performance will also be a bit more, with children items)
- The item is refered to by the name it is declared by. Within a routine no
other item is visible, they all HAVE to be declared before you can use them.
This gives you a nice lookup table of which items you mess around with.
- The name can be a short and cryptic one, that may be interpretered in many
ways. For
example, it could be called 'text'
- There are two possible ways of declaration, one called adopting and
creating.
- When you adopt an item, you only create a local reference. It is not an
instance nor a clone or something. When you set an item to a certain value
this value is read by all other item that have adopted him. You can consider
this the same as globals in Euphoria, only you have to specify which globals
you want to have acces to.
- All items can be adopted. So any item can be changed. All this however
within one parent. Which is the case with the program-item. DOS can not
acces any item except the program-item. All other items are his -direct
childeren if you think in tree-systems. However remember that the
program-item doesn't have to be the one to create the items, they could also
have been created by sisters and brothers.
- So you either adopt an item (only a brother item BTW) to give yourself
acces to that item or you create one. When you create an item it is
available to all your brothers and sisters. This creating is a dynamic
thing, it occurs. It is not a declaration like adopting is. The
adopting-declaration of an item that does not exist either gives an error,
or is pretended to be some other item. This means, within the declareration
you can specify second, third, fourth, etc. items that the system should try
to adopt when the preceeding item was unavailable. Often you will find
yourself putting a default value here (a value is also an item, a clone of
the atom or sequence item, which provide the routines to initialize, store
and lookup the value) which can be overridden by a custom setting (item
thus) IF available.
- Together with an item is saved the path it took to get there. The path is
list of items. The path will be the path of the item that had adopted you
with the name of that item appended. This path is used when we get to
naming conflicts. The item 'text' occurs, for example, three times. With
three different paths, then it is a simple alphabeticall comparisation,
which 'text' we mean. We start at the beginning and whose path is more like
the path of the item adopting, that item is the one that gets adopted.
However in the declaration of that adopting you could also specify a piece
of the path, so you can also acces items out of your -context-. Note that
the path lookup and generation occurs only during the decleration of the
item. Which item created it is not important. However there will be
situation where more items are in context. Now we open up our box of tricks,
and execute a statement using a value of that item, for every item that is
available. So an ==> text = text & '\n' <== would then apply to all items
in context. (that match equally well to the pieces of path used at the
decleration). Also I would like to notice that the pieces of path in the
decleration can contain many wildcards, like 'NOT' and 'OR' so we can
specify even better which items do match our selection and which don't.
- During the creation we also give an value to the item, this value is
passed as the ONLY argument to the initialization procedure. So an item,
with the routines of an atom, has to be passed its initialization value
during creation. Why have this initialization procedure ? Cause we can
clone, and actually that is the only way to make an item. As a clone of a
different item. Standard, the items atom, sequence and integer are
available. The item program also. Creating a clone of this, enable
program-in-program. Only within the program-item you could during
development create a new -fresh- item. Later on you could only clone those
items. You could for example have a window item, which you initialize with
the name of the window. The window item's initialization procedure creates a
bunch of new items, called height, width, top, left, backgroundcolor, etc.
Where the window item's set and get routines automatically adopt them. And
there path is thus very close to the item that cloned the window item.
- The selection of the item, and the initialization argument are on one line
together with spaces. So an item could just use the argument given as a path
to one of his children, example ==> system users Ralf MY_PASSWORD secret1
text <== 'Ralf' is the last available item at this point, it will pass
"MY_PASSWORD secret1 text" to the item Ralf, which then uses that argument
to select which child he wants to adopt. This way we do have acces to
private items, but the parents item has to pass it through and can thus
filter it. Also the item that is adopting may be unaware of the security at
all. Since if it was a brother item, it would have worked either.
Well, that was mine idea, I hope I haven't bored or confused ya too much. If
there is any part you do not understand I'll try to redo that piece of
explenation. It would solve both the naming convention and the context
sensitive programming problems, wouldn't it ?
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
ICQ:9389920
2. Re: Idea for NameSpace-problem
> -----Original Message-----
> From: Ralf Nieuwenhuijsen [SMTP:nieuwen at XS4ALL.NL]
> Subject: Idea for NameSpace-problem
>
>There is this idea I already have for a couple of years and it would
sove
>the name space problem, althrough I figured that it would be very
>impracticle for performace, because of the advanced management that has
to
>be done.. i got this idea, finding a way to -context sensitive-
program.
>Here it goes:
Why not just implement simple OOP objects? That way all globals are
referred to by their declared object names
--object file
--myobject.eo
public integer test -- exposed variable
private integer myvariable -- private variable
private procedure DoSomethingElse() --private to the object, can be
called only within the object
--code here
end procedure
public procedure DoSomething() --exposed procedure similar to "global"
DoSomethingElse()
end procedure
myvariable = 0
--------------------------------------
Then you could say:
--test.ex
obj junk, junk2
junk = include myobject.eo --euphoria object
junk2 = junk --create a copy of the object
junk.test = 1 --this is legal
junk2.test = 5
--junk.test = 1, junk2.test = 5
junk.myvariable = 1 --this is not legal
junk.DoSomething() -- this is legal
junk.DoSomethingElse() -- this is not
This way namespace is preserved and its not too "foreign" and
un-readable. Just a couple of more keywords and a few extra rules.
JMHO,
Greg Harris
3. Re: Idea for NameSpace-problem
> Why not just implement simple OOP objects? That way all globals are
> referred to by their declared object names
I went with Euphoria precisely because I wanted to avoid an OOP metaphor.
I also agree with the need for separate namespaces, but I'm unwilling to
go whole hog. I like the fact that Euphoria still lets you write quick and
dirty scripts, and there's no OOP tongue I know of that lets you do that
without a lot of handwaving.
Someone proposed having things accessible by tacking on the .e filename or
whatever (so graphics.e.line or graphics_e_line, or possibly include
graphics.e as graphics and use graphics_whatever), and I think this is a lucid
solution without going object crazy.
--
Cameron Kaiser * spectre at sserv.com * http://www.sserv.com/
--
Visit the leading Internet starting point today!
http://www.sserv.com/
--
4. Re: Idea for NameSpace-problem
> -----Original Message-----
> From: Cameron Kaiser [SMTP:spectre at WWW2.BUOY.COM]
> Subject: Re: Idea for NameSpace-problem
>
>
>> Why not just implement simple OOP objects? That way all globals are
>> referred to by their declared object names
>I went with Euphoria precisely because I wanted to avoid an OOP
metaphor.
>I also agree with the need for separate namespaces, but I'm unwilling
to
>go whole hog. I like the fact that Euphoria still lets you write quick
and
>dirty scripts, and there's no OOP tongue I know of that lets you do
that
>without a lot of handwaving.
True..I'd like to be able to do both. For quick and dirty stuff, its
great not to have to use it. But for large programs it would be nice if
you could i.e. for a zillion include files or in Windoze programming
which uses objects allot!
>Someone proposed having things accessible by tacking on the .e filename
or
>whatever (so graphics.e.line or graphics_e_line, or possibly include
>graphics.e as graphics and use graphics_whatever), and I think this is
a lucid
>solution without going object crazy.
This drives me crazy having to try to remember all the cryptic variable
names that I have to use to avoid conflicts with everybody else's
include files. :)
IMHO,
Greg Harris
5. Re: Idea for NameSpace-problem
At 10:07 AM 4/21/98 -0400, Cameron Kaiser wrote:
>I went with Euphoria precisely because I wanted to avoid an OOP metaphor....
>I like the fact that Euphoria still lets you write quick and
>dirty scripts, and there's no OOP tongue I know of that lets you >do that
without a lot of handwaving...
Agreed, we should never *require* the oop style.
It overcomplicates simple tasks.
The problem is this: programs that are worth money aren't
simple tasks.
Just before a program evolves to the point that is it saleable
(i.e. you're going to get paid for writing it)
it also gets so complex that it is nearly impossible to test,
debug and maintain. This seems to be true no matter what
language it's written in. The only solution is organization:
write neatly packaged modular code. Certain language
features help us do that. Let's start by adding the simple
ones: perhaps the dotted notation mentioned by several
people.
Irv
----------------------------------------------------------
--Visit my Euphoria programming web site:--
--http://www.mindspring.com/~mountains --
----------------------------------------------------------
6. Re: Idea for NameSpace-problem
> >Someone proposed having things accessible by tacking on the .e filename
> or
> >whatever (so graphics.e.line or graphics_e_line, or possibly include
> >graphics.e as graphics and use graphics_whatever), and I think this is
> a lucid
> >solution without going object crazy.
>
> This drives me crazy having to try to remember all the cryptic variable
> names that I have to use to avoid conflicts with everybody else's
> include files. :)
Well, that's true of any object metaphor though. Granted that the 8.3
convention really exacerbates this, but if you use (another suggestion)
include coolmod.e as coolmodule
as someone else suggested, then you can call the module anything you like.
coolmodule.bletch = foo
Even class IDs in Windows can clash; it's just that the number is so large
that this is unlikely.
--
Cameron Kaiser * spectre at sserv.com * http://www.sserv.com/
--
Visit the leading Internet starting point today!
http://www.sserv.com/
--
7. Re: Idea for NameSpace-problem
Am I missing something here.. Euphoria is already OOP-Enabled, only not
OOP-Activated to speak in the words of the guy behind all the OOP-Ideas..
I proposed the idea, knowing OOP was already available in Euphoria, and
orginally just trying to find a way to context-sensitive program. However I
am pretty pleased some of you actually read it all, it is pretty complex to
grasp I guess.
OOP is a programming style, and Euphoria makes it very easy to program that
way. Look at my old GFX, the virtual screens & sprites, were all programmed
OOP style.
Just call the routine belonging to the 'object', passing all non-static vars
as a sequence which we call the object sequence. The static vars are kept as
locals within the file that holds the routines.
And thanx to the new routine id's we can now also have custom routines, for
those objects that will have a simelar interface for the programmer (to use
those routines), but need different routines for that task.
Maybe some1 knowing all the right terms and whos able to write them also,
write a little tutorial for those thinking Euphoria isn't OOP.
Only inheritance is a missing point, but with nowadays programming editing
capabilities we can cut & past just as easily.
Euphoria is just way beyond OOP, a lot more mature and has a more liberal
wider perspective than most programming languages. All limitiations lie
behind the hardware.
Ralf N.
-- Previous message:
>> Why not just implement simple OOP objects? That way all globals are
>> referred to by their declared object names
>I went with Euphoria precisely because I wanted to avoid an OOP
metaphor.
>I also agree with the need for separate namespaces, but I'm unwilling
to
>go whole hog. I like the fact that Euphoria still lets you write quick
and
>dirty scripts, and there's no OOP tongue I know of that lets you do
that
>without a lot of handwaving.
True..I'd like to be able to do both. For quick and dirty stuff, its
great not to have to use it. But for large programs it would be nice if
you could i.e. for a zillion include files or in Windoze programming
which uses objects allot!
>Someone proposed having things accessible by tacking on the .e filename
or
>whatever (so graphics.e.line or graphics_e_line, or possibly include
>graphics.e as graphics and use graphics_whatever), and I think this is
a lucid
>solution without going object crazy.
This drives me crazy having to try to remember all the cryptic variable
names that I have to use to avoid conflicts with everybody else's
include files. :)
IMHO,
Greg Harris
8. Re: Idea for NameSpace-problem
- Posted by MAP <ddhinc at ALA.NET>
Apr 21, 1998
Here's my idea on how the namespace concept should be applied:
---------------------------------------------------------------------
namespace foo
atom a
integer b
namespace bar
atom a
function afunc (atom a)
return a*a
end function
end namespace -- bar
foo:a = 1 -- unneccesary
a = b -- fine, assumes local namespace
bar:a = a -- yup
a = bar:afunc(a) -- that's legal
a = afunc(a) -- not legal
end namespace -- foo
-- outside the foo namespace they'd be called
foo:a
foo:b
foo:bar:a
foo:bar:foobar()
---------------------------------------------------------------------
for new libraries and programs:
---------------------------------------------------------------------
-- foolib.e
global namespace foolib -- as a convention, (not enforced by compiler)
-- the namespace exported should be the name of
-- the lib.
-- also note that since the namespace is global,
-- everything with it is global.
constant SOME_CONST = 1
function some_func(atom a)
return a * a
end function
end namespace -- foolib
atom someatom -- not visible outside foolib.e
---------------------------------------------------------------------
-- someprog.ex
include "foolib.e"
atom someatom
someatom = foolib:some_func(2)
---------------------------------------------------------------------
for new programs using old (non-namepace) libs:
---------------------------------------------------------------------
-- foolib.e
global constant SOME_CONST = 1
global function some_func(atom a)
return a * a
end function
constant SOME_OTHER_CONST = 2 -- note that even though this lib is
-- wraped in the calling program,
-- non-globals are not exported
atom someatom -- not visible outside foolib.e
---------------------------------------------------------------------
-- someprog.ex
namespace foolib -- wrap the old lib into a namespace
include "foolib.e"
end namespace -- foolib
atom someatom
someatom = foolib:some_func(2)
---------------------------------------------------------------------
I think this method provides a better flexibilty than some of the
others mentioned. lib<underscore>var_name is impractical I think
because underscore is already a legal variable name character...
you can't change that without breaking almost all existing code,
and if you leave it to the compiler to make the distinction it
just adds additional overhead. I don't like the lib<dot>var_name
either because the dot representation is generally used for
structures in most languages. I still hope to see Euphoria
implement structures at some point.
This method should also allow programmers to add a more
object-oriented style to their programs, without forcing the
issue or breaking old code.
Opinions?
Regards,
Christopher D. Hickman
9. Re: Idea for NameSpace-problem
Cameron suggested:
>include coolmod.e as coolmodule
>
>as someone else suggested, then you can call the module anything you =
like.
>
>coolmodule.bletch =3D foo
So if you had:
include foo as bar1
in one file, and
include foo as bar2
I would hope that the interpreter would only load the file once, and =
know that "bar1" and "bar2" refer to the same file.
The syntax was initially appealing, but I'm not sure that the caller =
should be in charge of the name space. On the other hand,
> global namespace foolib
seems like a good suggestion, so the included file defines what the =
namespace is. But:
> end namespace -- foolib
is somethin I'm not crazy about. I would want the namespace to apply to =
the whole library, not just portions of it.
I also think it would be a good idea for multiple files to share the =
same namespace.
--------
Christopher D. Hickman offered:
foo:bar:foobar()
which, while I *think* I understand the logic, makes me shudder. I would =
think that you would want all namespace references to tie back to a =
*single* level:
bar:foobar()
--------
Irv Mullins suggested:
>You basically never make an assignment directly to a variable,
>but instead use the object's method: for example:
>every gadget inherits a (relative) location: {x1,y1} which
>we'll call COORDS, so to move a gadget, we say:
>win =3D Set(win,"btn1",COORDS,{50,20})
I've encountered have been a significant slowdown when working with =
structures, rather than "pure" variables. For example, eBasic converts =
QBasic code such as:
foo =3D bar + grill
into:
local[1] =3D local[2] + local[3]
Certain operations (such as '&') take *much* longer when you are working =
with a structure instead of a 'pure' variable.
>win =3D Set(win,"btn1",COORDS,{50,20})
Actually, a more "pure" method might be to use the index of the object =
instead of the actual object, such as:
SetWin( MyWindow, "btn1",COORDS,{50,20})
It's a bit redundant to call a routine that's supposed to 'set' =
something, and have still to assign the results - such is the cost of =
not being able to pass be reference.
-- David Cuny
10. Re: Idea for NameSpace-problem
> Cameron suggested:
>
> >include coolmod.e as coolmodule
> >
> >as someone else suggested, then you can call the module anything you like.
> >
> >coolmodule.bletch = foo
>
> So if you had:
>
> include foo as bar1
>
> in one file, and
>
> include foo as bar2
>
> I would hope that the interpreter would only load the file once, and know that
"bar1" and "bar2" refer to the same file.
Actually, if you did this, I would _expect_ it to intentionally have two
instances (hell, I *am* going OOP 
. I would assume someone doing something
like that has a good reason for wanting two copies of some_fun accessible
through two different namespaces.
> The syntax was initially appealing, but I'm not sure that the caller should be
in charge of the name space. On the other hand,
Why not? The caller's the one that has to use it.
> I also think it would be a good idea for multiple files to share the same nam
espace.
And by letting the caller define which namespace it goes into, you can do
that exact thing. I would write it as
include foo as bletch
include bar as bletch
and the caller will see them as one big, gross library. Conflict resolution
between functions and variable would be a stinkiness though, and I guess that
is one disadvantage of letting the caller dictate the name space. But no one
said that programming was dummy proof -- this isn't EuphoriaBeans after all
--
Cameron Kaiser * spectre at sserv.com * http://www.sserv.com/
--
Visit the leading Internet starting point today!
http://www.sserv.com/
--
11. Re: Idea for NameSpace-problem
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Apr 21, 1998
-
Last edited Apr 22, 1998
David Cuny wrote:
>into:
> local[1] = local[2] + local[3]
>Certain operations (such as '&') take *much* longer when you are working
with a structure instead of a 'pure' >variable.
Not true, the overhead is speed is caused by the interpreter not knowing the
structure during pre-compilation.
If Euphoria would enable structures, they could execute that kind of code
*much* faster. Simply because they can then replace local[2] with a direct
pointer to the memory space, instead of having to lookup the pointer during
runtime. (only the pointer of local is directly embedded in the run time
stack)
>>win = Set(win,"btn1",COORDS,{50,20})
>Actually, a more "pure" method might be to use the index of the object
instead of the actual object, such as:
> SetWin( MyWindow, "btn1",COORDS,{50,20})
>It's a bit redundant to call a routine that's supposed to 'set' something,
and have still to assign the results - such >is the cost of not being able
to pass be reference.
It would certainly not be more "pure", but more "used" is the word your
looking for. Technically it isn't even called OOP. Four reason why the other
method is the better choice:
1) In real oop, we do set something inside the object, but we manage the
data of that object ourselves, in this case the managing of that data is the
job of the library, which has to re-invent dynamic allocation all over
again.
2)I'll explain that a bit more: You now have a pointer, and to that pointer
belongs a bunch of data, prolly stored in a sequence, where the
pointer/reference is used as an index. This would be very memory
inefficient, cause even when a pointer is unloaded, and most data is
released we still got to keep an empty sequence. Plus looking the sequence
up takes time.
3) Also, if we manage the data ourselves we can copy the object, and clone
it as many times as we wish.
4) We can now add routines, also capable of doing something with that
object, from different programs, or from our own program. This enables
*inheritence*, something your method simply doesn't allow. A type check can
prevent any mis-use anyway.
Example (usage of GFX): (note that cloning a virtual screen, will not copy
the contents of that screen, it will simply have two different
configurations of the same screen, and that can bu used for some weird
effects, or to have screens in screens)
my_screen = MakeVS ({320,200}, VS_MEMORY) -- Makes a virtual screen,
and stores it in my_screen
my_sprite = MakeCS (..) -- Makes a sprite
my_sprite2 = my_sprite -- Clone the sprite
DrawCS (my_screen, my_sprite)
my_sprite = MoveCS (my_sprite, {100,100}) -- Moves 100 up and
to the right
my_sprite2 = MoveCS (my_sprite2, {-100,100}) -- Move 100 up and
to the left
CopyVS (my_screen, Monitor) -- Displays the virtual screen on the
monitor
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
12. Re: Idea for NameSpace-problem
- Posted by MAP <ddhinc at ALA.NET>
Apr 22, 1998
In yesterday's post I included some code showing what I'd like to see
done with namespaces. Let me take a minute to reverse myself on one
particular convention I mentioned. I said that in a situation like
this:
global namespace somelib
atom x
end namespace
that x would be global. After thinking about that some I realized
that that would not serve the purpose I had in mind for doing
namespaces this way, it should be
global namespace somelib
global atom x
end namespace
to make x visible outside that namespace thru somelib:x.
In David Cuny's post he expressed some trepidation over having
the "end namspace" declare the end of the namespace rather have
it run to the end of the file, and over the nested syntax for
namespaces, like foo:bar:some_func(). My intention for this usage
of namespaces was to provide a method for more than just resolving
library conflicts, but to allow the user a great deal of flexibility
in controling the scope of variables and functions within a program
as well. The result is something like the features of OOP languages
that use classes with public and private portions for controling
which aspects of a group of features are exposed or hidden.
You could do something like:
global namespace widgets
namespace low_lev_ctrl
sequence bar
sequence foo
global function something_low_level(atom x, atom y)
if length(foo) = length(bar) then
return (x * y))
end if
return ((x + length(foo) - length(blah)) * y)
end function
end namespace -- low_lev_ctrl
global namespace windows
sequence window_list
global procedure resize(atom handle, integer x, integer y)
if handle then
window_list[handle][some_property] =
something_low_level(x, y)
end if
end procedure
end namespace -- windows
global namespace buttons
-- various button controls
.
.
.
end namespace -- buttons
-- more widgets
.
.
.
end namespace -- widgets
Notice that the namespace low_lev_ctrl was not preceded by global, that
would mean that this namespace is not exported outside the namespace
it resides in. something_low_level() would be accessable only to other
items within the widgets namespace. In addition, the sequences foo and
bar within low_lev_ctrl were not declared global (perhaps a better
keyword
is export) and are not visible outside of low_lev_ctrl at all.
You're prolly wondering "why do this?". Well for small projects I
wouldn't
bother with it at all, it's usually very simple to track dependancies
and side affects without all the extra work in a small program. But in
a large project, especially one that requires maintenance after sitting
around for a while it's not so easy. This method allows you to limit
dependancies and side-affects. You won't be tempted to use
something_low_lev() in other aspects of you programming than within
widgets (which would normally occur in a quick fix situation).
So, if you do away with this procedure or alter it in some fashion,
you have limited the scope of it's possible side-effects to just
the portion of code related to the problem. It makes fixing bugs and
adding new features in future versions a simpler task. And it makes
sure your not tempted to box yourself in with some fix-all function
that may eventually require you to rewrite a major portion of your
code.
Of course, as I said before, this is designed not to break any old
code already existing or force you to use it in a situation you don't
feel it's necessary. For simply resolving lib conflicts you would
just put a namespace at the top of the file and end namespace at the
bottom. (the "end namespace" is also necessary for the situation where
the user wraps an old library inside his/her own program to resolve
conflicts, see yesterdays post for an example of that).
Regards,
Christopher D. Hickman
13. Re: Idea for NameSpace-problem
- Posted by MAP <ddhinc at ALA.NET>
Apr 22, 1998
Oops, I need to be more diligent about proof-reading my posts
*before* hitting the send button in the future...
In my latest post, the line:
> window_list[handle][some_property] = something_low_level(x, y)
should read:
> window_list[handle][some_property] = low_lev_ctrl:something_low_level(x, y)
Thanks,
Christopher D. Hickman
14. Re: Idea for NameSpace-problem
How about this,
eg the libraries red.e and blue.e both contain the procedures window, hide,
show and order.
include red.e
setname window as Rwindow,
hide as Rhide,
order as NULL -- this would exclude the procedure 'order'
include blue.e
setname hide as Bhide,
show as Bshow
red's procedures would then be:
Rwindow
Rhide
show
and blue's would be:
window
Bhide
Bshow
order
Simple, neat, no more name conflicts, any problems with this?
-Molasses
15. Re: Idea for NameSpace-problem
Ok, I admit I haven't been paying too much attention to what other people
have suggested, or even the actual problem, but how about this idea:
eg If libraries red.e and blue.e both have procedures named window, hide,
show and order.
include red.e
setname window as Rwindow,
hide as Rhide,
order as null -- this exludes the procedure 'order'
include blue.e
setname hide as Bhide,
show as Bshow
After this the procedures for red.e are:
Rwindow
Rhide
show
And for blue.e they are:
window
Bhide
Bshow
order
No more name conflicts, any problems with this?
(don't flame me all at once :) )
-Molasses
16. Re: Idea for NameSpace-problem
At 03:09 PM 4/22/98 +1000, Molasses wrote:
how about this idea:
>
>eg If libraries red.e and blue.e both have procedures named window, hide,
>show and order.
>
>include red.e
>setname window as Rwindow,
> hide as Rhide,
> order as null -- this exludes the procedure 'order'
>
>include blue.e
>setname hide as Bhide,
> show as Bshow
>
>After this the procedures for red.e are:
>Rwindow
>Rhide
>show
Not bad, but it does add another layer of indirection -- meaning
you have to search for where Bshow is defined in order to find
out it is really named show in blue.e.
Another way of saying the same thing might be:
include foo.e
import show as foo_show -- sort of an alias
etc...
I prefer the more direct way, however:
include foo.e as foo
include bar.e as bar
Then we have direct access to any globals in these two
files as follows:
x = foo:show
y = bar:show
After all, whoever wrote the include file probably wanted us to
have access to all the globals (const/var/functs...) anyway,
so we shouldn't have to specifically *import* them one by one.
There is something to be said for being able to override an
existing name (as in your null example above) but using the
xxx:yyy method eliminates this problem as well
( just call your local var/func without any leading xxx: )
The only change to Euphoria (I think) would be to have
the include process add the prefix (xxx:) to each global
in the included file -- making the name a bit longer.
The only error checking needed would be for duplicate
prefixes: you shouldn't be able to say, for example:
include foo.e as foo
include bar.e as foo << error
If you didn't add the 'as xxx' clause, includes would work
just like they do now, so no existing code would be "broken".
Irv
17. Re: Idea for NameSpace-problem
> At 03:09 PM 4/22/98 +1000, Molasses wrote:
> how about this idea:
> >
> >eg If libraries red.e and blue.e both have procedures named window,
hide,
> >show and order.
> >
> >include red.e
> >setname window as Rwindow,
> > hide as Rhide,
> > order as null -- this exludes the procedure 'order'
> >
> >include blue.e
> >setname hide as Bhide,
> > show as Bshow
Irv wrote:
> I prefer the more direct way, however:
> include foo.e as foo
> include bar.e as bar
> Then we have direct access to any globals in these two
> files as follows:
> x = foo:show
> y = bar:show
>
> After all, whoever wrote the include file probably wanted us to
> have access to all the globals (const/var/functs...) anyway,
> so we shouldn't have to specifically *import* them one by one.
Yes, but I don't believe one person's library would completely match that
of another's. You would probably only need to rename a few procedures, and
that would save you having to type xxx: in front of everything.
-Molasses
18. Re: Idea for NameSpace-problem
>> After all, whoever wrote the include file probably wanted us to
>> have access to all the globals (const/var/functs...) anyway,
>> so we shouldn't have to specifically *import* them one by one.
>
>Yes, but I don't believe one person's library would completely match that
>of another's. You would probably only need to rename a few procedures, and
>that would save you having to type xxx: in front of everything.
Which would you rename? The ones you found crash your program, detected
after they crashed your program! I prefer Irv's way.
Regards,
Daniel Berstein.
