1. Namespace idea
Rob,
One suggestion for the namespace problem (borrowed from C++ with
modifications):
The following would be added to the language
1. Dot notation (or any prefered eqivalent alternative)
2. namespace / end namespace
3. using/ stop_using
The namespace keyword would define a namespace which would be in effect
until the next end namespace. Namespaces could be nested, and a given
namespace could be closed and reopened later.
If this were part of Euphoria, Win32Lib would need no alteration ecept for
its first line to be namespace Win32Lib and its last line to be end
namespace. In the case I needed a namespace for say graphics.e (which I
wouldn't modify and lose its stamped status)
namespace Graphics_e
include graphics.e
end namespace
would accomplish the same thing as putting namespace/end namespace in the
file itself.
The using keyword allows us to dispense with dot notation in many cases.
Let's say were using Win32lib and it didn't have any name clashes. Then
using Win32lib
would allow Win32lib routines/constants to be referenced without the dot.
Using would allow multiple namespaces:
using foo, bar, blech
and would be cumulative:
using foo
using bar
using blech
would be equivalent to the above example.
The keyword stop_using would remove one or more namespaces form the using
list.
stop_using bar
would prevent using bar routines/data without the dot, but continue to allow
it for foo and blech.
stop_using ALL would clear the entire using list.
The seach order for a routine or data:
1. If the reference is in a namespace, that namespace.
2. If that namespace is nested in another namespace, the enclosing
namespace.
3. Rule 2 is applied recursively.
4. The global namespace.
5. The namespaces in the using list, in the order they were declared.
Thus an example
using foo,bar,blech
namespace ugly
namespace mug
yuck(17,"ABC")
the interpreter would try in order:
ugly.mug.yuck
ugly.yuck
yuck
foo.yuck
bar.yuck
blech.yuck
Just some food for thought--this concept is very powerfull but might be to
complex for users. It's not hard to implement, I've already done so for OOP
code in Object Euphoria. (Except stop_using(), this is original for this
proposal.)
-- Mike Nelson
2. Re: Namespace idea
Thanks Mike.
I'll store your ideas with Irv's and look at them
in detail once the translator work settles down.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Namespace idea
On Tue, 29 Aug 2000, you wrote:
> Rob,
>
> One suggestion for the namespace problem (borrowed from C++ with
> modifications):
>
> The following would be added to the language
> 1. Dot notation (or any prefered eqivalent alternative)
> 2. namespace / end namespace
> 3. using/ stop_using
I like the idea (but not the choice of keywords:)
How about the even simpler and more Euphoric:
namespace W32Lib
include win32lib.e
end namespace
with W32Lib do
foo() bar() blecch() -- that would be win32lib's foo, bar & blecch
with something_else do
foo() -- this is something_else's foo
end something_else
end W32Lib
Regards,
Irv
4. Re: Namespace idea
<snipsnipsnip>
mike nelson:
> using foo,bar,blech
> namespace ugly
> namespace mug
> yuck(17,"ABC")
> the interpreter would try in order:
> ugly.mug.yuck
> ugly.yuck
> yuck
> foo.yuck
> bar.yuck
> blech.yuck
after reading your post, i pondered it for a while, and grew to like it...
as well as some other namespace suggesstions prior to this post, irv, etal.
i have one serious fear with your post however...
i feel as though all those namespace lookup for each call of a function
will *DRASTICALLY* alter the speed of recursion, which is one of EU's
main strong points...
i will however assume that rob can apply some cacheing for the function
lookups for recursion to alleviate any overhead your suggesstion might have
:)
--Hawke'
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
5. Re: Namespace idea
Hawke wrote:
<snip>
> after reading your post, i pondered it for a while, and grew to like it...
> as well as some other namespace suggesstions prior to this post, irv,
etal.
>
> i have one serious fear with your post however...
> i feel as though all those namespace lookup for each call of a function
> will *DRASTICALLY* alter the speed of recursion, which is one of EU's
> main strong points...
> i will however assume that rob can apply some cacheing for the function
> lookups for recursion to alleviate any overhead your suggesstion might
have
> :)
> --Hawke
Hawke,
In the compiler, all ambiguity resolution would be done at compile time--run
time cost zero. In the interpreter, ambiguity resolution would be done once
the first time the symbol is encountered, the interpreter would replace it
with the appropriate fully-qualified symbol--cost fairly small. The
programmer could also be given the option of specifing an absolute symbol
name: all symbols would be included in the global namespace (named
"global"), some of them would be nested in another namespace. Thus
global.foo.yuck
would mean "use yuck from the foo namespace in the global namespace; if it
doesn't exist there, give an error, don't search elsewhere while
foo.yuck
would use the search algorithm. So the small cost could be reduced to zero
in critcal cases.
-- Mike Nelson
would search as alredy suggested.
