1. RE: Namespace Proposal
I'am in full agreement with IRV to use the prefix notation.
I don't want the with/without stuff too much typing and confusion.
I just want to be able to include a file and assign it the namespace
of my choosing and use that namespace as a prefix to its routines.
This is the cleanest approach that is used in other langauges.
What everyone has to keep in mine is that Rob has to be able to parse
the code easily without breaking the old code. Anyone that has written
any large program knows how hard it is to keep the names unique
without conflicting with someone elses include files.
I also want to see FORWARD references without the routine_id baloney.
Bernie
2. RE: Namespace Proposal
There is an additional namespace problem to be addressed. When you've
been using tiny include files and then decide to tidy things up by
copying them into the main file, you lose the namespace protection
afforded by separate files.
A simple solution to this problem is to add two keywords:
BeginIncludeFile
EndIncludeFile
3. RE: Namespace Proposal
> -----Original Message-----
> From: Kat [mailto:gertie at PELL.NET]
> Sent: Saturday, 23 June 2001 1:57 PM
> To: EUforum
> Subject: Re: Namespace Proposal
>
Hi Kat,
> >
> > I noticed some mention on the topic of dot notation.
> >
> > If dot-notation is so important
> >
> > this.variable
> > this.sequence
> > this.integer
> > this.atom
> > this.routine_id (hehe yeah right)
>
> You know, that would sure make it easy to do this:
>
> s = this.*
Except that the notation is referring to namespaces.
s = this.*
would assign all global variables, constants (and routines?) to s, if
applied to namespaces. Probably not what you meant.
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au
---------------------
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
4. RE: Namespace Proposal
> -----Original Message-----
> From: Travis Beaty [mailto:travisbeaty at arn.net]
> Sent: Saturday, 23 June 2001 12:01 PM
> To: EUforum
> Subject: Re: Namespace Proposal
G'Day Travis,
>
> Here, I feel that I must agree with Derek that the
> "namespace" idea would be
> best.
No, I think that Derek was just shooting the breeze with this boneheaded
suggestion. It would leave us no better off than now, and probably worse
off, because it makes the author of a library the custodian of a namespace
ID. But what happens when some other person happens to pick the same
namespace ID? BANG! Name clashes are again possible! Stupid idea really.
Don't know what he was thinking. Probably should have finished eating
breakfast before trying to engage brain.
>The biggest reason for this would be uniformity,
> especially among any
> future libraries which would implement the namespace system.
>
> For instance, suppose that win32lib.ew used the namespace
> "win." Now then, the
> name for this namespace would be set within the include file
> itself, not within
> the user's code. This would make other people's code more
> readable, in my
> opinion, because it would "standardize" the win namespace
> with win32lib.ew.
> For instance, with the namespace being declared in the
> win32lib.ew include
> file, anyone familiar with that library would be able to see
> its use in Mr.
> Jones' program:
>
> include win32lib.ew
>
> sequence
> theVersion
>
> theVersion = win.getWin32libVersion()
>
>
> If the user declares the namespace, the user might declare
> such a namespace as
> "win," or "win32", or "winnythepoo." That, I feel, would
> make it much harder
> for others to read the code.
However, I completely agree with you over these concerns, Travis. Its just
that the solution I suggested would give even more problems than we have
now. I guess we just have to trust in the good graces (and common sense?) of
other coders.
> The only problem I can see with namespaces is that, in a way,
> it only jacks the
> conflict up to a higher level. What if file A declares the
> namespace "myFile,"
> and file B declares the namespace "myFile"? Will this be
> considered a naming
> conflict, or will file B's symbols be added to the namespace
> previously created
> by file A?
>
> Another question would be scoping. In the following example,
> what would be the
> result?
>
> -- myLib.ew
>
> include myFirstLib
> namespace myLib
> include mySecondLib.ew
>
> -- end of code
>
> Now, let's assume that the only namespace declared is in
> myLib. Would symbols
> in myFirstLib be in the global namespace and symbols for
> mySecondLib be in the
> myLib namespace? If mySecondLib has the namespace "Second"
> declared, would
> "Second" therefore be a subset of the "myLib" namespace? I
> fear there would be
> a lot of hashing out syntax using this setup.
These are just some of the issues my suggestion would raise.
> All things considered, I know I would be a lot more
> comfortable using the
> namespace system, and I do feel that, as much trouble as it
> will be to setup
> and implement, it would be the most readable of the proposals
> I've seen thus
> far, as it would provide with a namespace standarization of
> libraries -- when
> the reader of my code sees the "win" namespace, or the "obj"
> (objecteu(?))
> namespace, the reader knows exactly where it's coming from,
> without hesitation.
>
I hereby formally withdraw my earlier "namespace" suggestion. I think it
would be too problematic.
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au
---------------------
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
