Re: Namespace Proposal
Howdy y'all!
> That is exactly the problem. If we all could cooperate, we would already
> take
> pains to always name our variables *differently* from everyone else's
> variables.
> That doesn't happen now, so why should we expect it to suddenly work in the
> future when even more people are writing Euphoria code?
Hmmmm. I can see your point. I guess for clarification about this, I should
ask how possible namespace clashes are handled in, say, C++. Does C++ have a
convention when it comes to declaring namespaces (other than std of course)?
If the system in C++ works, perhaps we should adopt a similar policy. If it
doesn't work, then we should not implement it. Basically, I am not real
adamant on how namespaces should be implemented, but I agree that they should
be implemented.
On the subject of name decoration, I have tried to do that as much as possible;
however, as I've come from a Pascal background, I have a habit of creating
those wonderful three-mile-long variable names ... so, a constant named
TRAVIS_NEWGRAPHIC_PIXELLOC_X doesn't scare me all that much (although *I*
wouldn't do that!!). However, the C'sters out there try to keep their variable
names as short as possible, I've found, so name decoration would undoubtedly
not be on their list of Utopic fixes.
> How do you prevent me from namespacing my include file in the "win"
> namespace also? You would just have to go in and change it - making things
> even more confusing, since your program code would have no indication that
> such a thing had been done.(assuming my code wasn't shrouded, in which case
> you
> would be s.o.l.)
You make a valid point here as well. I *suppose* that if that were done, of
course the symbols of your include file would be added to win32lib's namespace
come hell or high water, at which time name clashes could occur. And, if
you're code was shrouded, that would be a humdinger, wouldn't it? On one hand,
it would be a matter of "the meaner dog wins," because if you have a new seldom
used library clashing with win32lib.ew, chances are that the voice of the Grand
Euphorium would have the author of the new, seldom-used library change it. On
the other hand, if you have two libraries of equal use which clash, therein
lies the one nasty pickle. In that case, one could simply state as a
"Euphorian Code of Namespace Ethics" that whichever library was developed first
keeps the namespace name. Basically, seniority. If a coder does not wish to
follow this, and instead decides that he or she **will** use the win namespace,
then they will find that their library becomes little used or used only in
programs which do not incorporate win32lib.ew.
I guess an example of this would be if I wrote a library which did not have one
routine name shorter than 50 characters, and this library was shrouded. It
might be useful, but would people use it with routine names such as
thisHereIsAVeryVeryLongRoutineNameJustToPissPeopleOff()? Just as this would
irk people, so would the namespace clash cited above.
> Unless someone wants to set up an UNCLE (Universal Namespace CLearinghouse
> for Euphoria) Organization, with broad enforcement powers, I think it will
> work much better if we are allowed to rename at the time we do the include.
There would be no need for UNCLE ... the seniority rule would really be self-
policing, to an extent.
> There's no reason that doing so would make code harder to understand After
> all, the naming would take place right out in the open at the top of the
> file, where anyone could (and should) read it - not hidden away somewhere
> else, making you read
> all the include files to find it.
In some ways, this is certainly true. However, since half the time, our eyes
control our brains, it would be so easy to read this include file:
include win32lib.ew as win
win.getOpenFileName()
then read this include file:
include win32lib.ew as gui
gui.getOpenFileName()
and then instantly deduce that win.getOpenFileName() and gui.getOpenFileName()
are two different routines.
Just my two cents there ... I can still be talked into defecting! hehehe
Travis Beaty
Claude, Texas.
|
Not Categorized, Please Help
|
|
