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