1. RE: Namespace improvement ?
- Posted by Chris Bensler <bensler at nt.net>
Feb 01, 2005
-
Last edited Feb 02, 2005
Christian Cuvier wrote:
>
>
> > Matt Lewis wrote:
> >
> >>> Yes, please elaborate. I recall you mentioning that you'd dropped the
> >>> namespace thing, but I don't recall any negative aspects being in there,
> >>> other than the time it would take:
> >
> >
> > It was months ago, so I don't remember all the details, but
> > I think there were basically two negatives that started
> > to loom larger in my mind:
> >
> > 1. The change was going to add complexity and subtlety to
> > namespace rules that many people already had trouble
> > remembering.
> >
> > 2. After porting thousands of lines of C code to Euphoria
> > (i.e. the front-end), I had a couple of nasty cases where I
> > accidentally declared a global variable in two different files.
> > No error message was given, yet I was updating two different
> > variables, not one. It took a while to figure out what was
> > happening. Since the proposed change to the namespace rules
> > would increase the chances of this sort of bug going
> > undetected, I considered that to be a negative thing,
> > that would partially offset the positive effect of fewer
> > spurious error reports.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > http://www.RapidEuphoria.com
>
> An easy and cleaner way aroubnd this would be to implement
> promoting/demoting
> of a global identifier.
>
> Assume my_global is defined in libs A2 and B2. Library A1 includes A2,
> B1
> includes B2. As long as you don't include A1 and B1 together, no
> problem.
>
> Now if program P includes both A1 and B1, a nama clash occurs on the
> first
> invocation of my_global in any of the five involved files. An easy way
> for the
> author of P to avoid this, while still relying on the UNMODIFIED A* and
> B*
> (this reduces package sizes, negates compatibility issues etc, this is
> why
> IK's way out by symbol renaming is not usable) could be to do this:
>
> }}}
<eucode>
> include A1 as a1
> demote my_global from a1
> include B1 as b1
> </eucode>
{{{
>
> The middle line would prevent unqualified accass to a1:my_global.
> Additionally:
> - P can still access a1:my_global as appropriate using the explicit
> namespace;
> - A1 and B1 are no longer affected, as their symbol tables are not
> affected by
> the demote command from P;
> - If, at some point, P finds it more convenient to access b1:my_global
> without
> the b1:, it still can by issuing:
>
> }}}
<eucode>
> demote my_global from b1
> promote my_global from a1
> </eucode>
{{{
>
> promote would just undo demote's effect.
> - P doesn't need to know how A1 includes A2, or any detail of this kind.
> It
> just has to know that A1 knows about a global called my_global.
>
> This implies that every file has the following symbol tables:
> - local identifiers
> - global identifiers from directly included files (these tables would be
>
> inherited)
> - the default (unqualified) namespace, where symbol visibility could be
> adjusted.
>
> The bottom line is:
> - A file always can see globals from files it includes, files the latter
> files
> include and so on;
> - A file can see any global unqualified symbol if this symbol was not
> demoted;
> - A file cansee any global by using the appropriate namespace qualifier;
> - demote is reversed by promote and vice versa.
>
> Is this confusing?
> Would it break any code?
>
> I'll consider implementing it in the 2.5 source, as no mod to the IL
> appears
> to be necessary. promote and demote are just directives targetting the
> parser,
> and are not supposed to generate any code. The only issue is adding an
> intermediate layer of symbol tables between local and global tables, one
>
> intermediate table for each file.
>
> No timetable for this though, as I don't have much free time and I'd
> like to
> release Syntax2 for xControls - way to go still.
>
> CChris
>
>
The attraction of Euphoria is it's simplicity, and it's powerful use of
the few existing concepts that are available.
I think there is a good solution the the namespacing problem, but it
requires breaking backwards compatability. IMO for this change, it would
be worth breaking from the mould...
My suggestion is that the scope of an include file should only extend to
the caller. IOW an included file should be local to the file that
includes it, instead of global. This would make an included file part of
the same local scope as the calling file. If you want to allow an
include file to be accessed by 3rd-party files (B includes A, C includes
B), you include the first file as global.
Ex1.
-- fileB.e --
include fileA.e <-- fileB can access any globals in fileA.e
<-- (locally included)
-- fileC.e --
include fileB.e <-- fileC cannot access fileA,
<-- because fileA was not included globally.
Ex2.
-- fileB.e --
global include fileA.e <-- fileB.e and any files that include it,
<-- can access any globals in fileA.e
<-- (globally included)
-- fileC.e --
include fileB.e <-- fileA.e is included globally in fileB.e,
<-- so fileC.e can access the identifiers in fileA.e
-- fileD.e --
include fileC.e <-- fileD.e cannot access any identifiers declared
<-- in fileB.e or any files it includes, because
<-- fileB.e was not included globally in fileC.e
Notice, that there is no new concepts introduced whatsoever.
The solution elegantly takes advantage of the existing concept of global
scope and extends it to apply to included files.
It's graceful, intuitive and actually brings includes into a common
concept of scoping rules, just like any other identifier. The only
drawback is that it breaks compatability, which I don't think is a big
deal, weighed against the advantage of a better include system.
Why do I think the include system needs to be changed, and why does it
affect namespacing?
It should be changed because, a great majority of the time, when a
programmer includes a file, it is used only internally within their
project. Currently, we have to resort to creating lengthly and obscured
global identifiers, so that internal files can interface with eachother,
meanwhile, all those globals are exposed to the whole of the
application, not just the part that require it.
It affects namespacing, because as I said, currently we must contaminate
the global namespace, in order to interface between internal libs. This
is the most profound impact on 'global pollution'. If we can address
that issue, we have solved 80% of the namespace problem.
With an include system like I described, I think that the need for
namespacing could be virtually eliminated.
To address the namespacing issue directly, I propose an 'alias' keyword.
Alias would allow the programmer to specifiy exactly which identifier
they want to refer to and make a shortcut method of identifying it.
Eg
include fileA.e as fileA
include fileB.e ad fileB
alias fooA = fileA:foo, fooB = fileB:foo
This would solve any indiscrepencies, as the programmer would have full
control of what they want to refer to, without having to resort to using
qualifiers throughout their code.
Chris Bensler
Code is Alchemy
2. RE: Namespace improvement ?
Chris Bensler wrote:
>
> The attraction of Euphoria is it's simplicity, and it's powerful use of
> the few existing concepts that are available.
>
> I think there is a good solution the the namespacing problem, but it
> requires breaking backwards compatability. IMO for this change, it would
> be worth breaking from the mould...
>
> My suggestion is that the scope of an include file should only extend to
> the caller.
.....
> To address the namespacing issue directly, I propose an 'alias' keyword.
> Alias would allow the programmer to specifiy exactly which identifier
> they want to refer to and make a shortcut method of identifying it.
I couldn't agree more vigorously!!!
Simplicity is elegance, and Euphoria does a good job at it. Resolving
the namespace issue as Chris suggests, would make it conceptually
crystal clear. At the same time it would mean less work in the vast
majority of projects.
IMO, if A includes B which includes C, then it is no business of A
to know anything about C (not even that there is such a thing as C).
If the programmer of B specifically wants something visible at "upper
level" (in this case A), then let him explicitly state that in B.
If somebody needs to use C directly, then let him, by importing C
directly into A. But nothing from C should get to A via B -- not
automatically.
Aliases would be an easy, logical, and even error-resistant way to
"carry C names from B to A". (Badly said, short-circuit at my brain
cell #2938492839423.)
----
Of course this may crap up a lot of existing code. Since I don't have
code of my own that is affected by this, I feel QUALIFIED
to think about this "objectively".
I think this is a pretty important issue.
-- Another Euphoric, since Nov. 18, 2004 --
3. RE: Namespace improvement ?
- Posted by Chris Bensler <bensler at nt.net>
Feb 02, 2005
-
Last edited Feb 03, 2005
Georg Wrede wrote:
<SNIP>
> Of course this may crap up a lot of existing code. Since I don't have
> code of my own that is affected by this, I feel QUALIFIED
> to think about this "objectively".
>
> I think this is a pretty important issue.
>
> -- Another Euphoric, since Nov. 18, 2004 --
Realistically, it would break most everybody's code.
However, the transition would be very minor (change all cases of
"include foo" to "global include foo"). I deal with worse scenarios,
just trying to rectify the mess that namespacing makes.
Chris Bensler
Code is Alchemy
4. RE: Namespace improvement ?
Chris Bensler wrote:
>
>
> Georg Wrede wrote:
>
> <SNIP>
>
> > Of course this may crap up a lot of existing code. Since I don't have
> > code of my own that is affected by this, I feel QUALIFIED
> > to think about this "objectively".
> >
> > I think this is a pretty important issue.
> >
> > -- Another Euphoric, since Nov. 18, 2004 --
>
> Realistically, it would break most everybody's code.
> However, the transition would be very minor (change all cases of
> "include foo" to "global include foo"). I deal with worse scenarios,
> just trying to rectify the mess that namespacing makes.
>
> Chris Bensler
Then,
If you don't want to break existing code (or future code based on today's rules
why not make the change:
"local include foo" to make foo's globals actually local to the including
file?
This would simply require that the new behavior be invoked explicity.
Verne Tice
5. RE: Namespace improvement ?
- Posted by Chris Bensler <bensler at nt.net>
Feb 03, 2005
-
Last edited Feb 04, 2005
Verne Tice wrote:
>
>
> posted by: Verne Tice <fredfarkle at highstream.net>
>
> Chris Bensler wrote:
> >
> >
> > Georg Wrede wrote:
> >
> > <SNIP>
> >
> > > Of course this may crap up a lot of existing code. Since I don't have
> > > code of my own that is affected by this, I feel QUALIFIED
> > > to think about this "objectively".
> > >
> > > I think this is a pretty important issue.
> > >
> > > -- Another Euphoric, since Nov. 18, 2004 --
> >
> > Realistically, it would break most everybody's code.
> > However, the transition would be very minor (change all cases of
> > "include foo" to "global include foo"). I deal with worse scenarios,
> > just trying to rectify the mess that namespacing makes.
> >
> > Chris Bensler
>
> Then,
>
> If you don't want to break existing code (or future code based on
> today's rules
> why not make the change:
>
> "local include foo" to make foo's globals actually local to the
> including
> file?
>
> This would simply require that the new behavior be invoked explicity.
>
> Verne Tice
Because that's a band-aid solution and doesn't actually solve the
problem. I dislike hacks and shims. Hacks perpetuate more hacks.
I would rather do it right once than do it poorly 10 times.
Chris Bensler
Code is Alchemy
6. RE: Namespace improvement ?
- Posted by Chris Bensler <bensler at nt.net>
Feb 03, 2005
-
Last edited Feb 04, 2005
Juergen Luethje wrote:
>
>
> Me wrote:
>
> <snip>
>
> >> Chris Bensler wrote:
> >
> > <snip>
> >
> >>> Realistically, it would break most everybody's code.
> >>> However, the transition would be very minor (change all cases of
> >>> "include foo" to "global include foo").
> >
> > Yes, very minor. And this replacement can be done automatically by a
> > small program.
>
> <big snip>
>
> Another idea with the same effect, that does not break a single line of
> existing code ...
> ( I don't remember whether or not this has also been discussed before.)
>
> Let the syntax of the 'include' statement alone, and introduce a new
> keyword, say 'shared', that can be used, whereever 'global' can be used:
> shared sequence foo
> shared function foo()
> etc.
>
> The only difference to 'global' would be, that the 'shared' symbols are
> only shared between the file where they are defined, and the file that
> *directly* includes this file.
>
> Regards,
> Juergen
>
> --
> Have you read a good program lately?
>
I strongly oppose any solution geared to compromise, when a better
solution is available.
Fix the scope of includes properly, and be done with it. We don't need
to introduce any new concepts, just ammend the current concept of
includes.
Chris Bensler
Code is Alchemy
7. RE: Namespace improvement ?
Chris Bensler wrote:
>
>
> Juergen Luethje wrote:
> >
> >
> > Me wrote:
> >
> > <snip>
> >
> > >> Chris Bensler wrote:
> > >
> > > <snip>
> > >
> > >>> Realistically, it would break most everybody's code.
> > >>> However, the transition would be very minor (change all cases of
> > >>> "include foo" to "global include foo").
> > >
> > > Yes, very minor. And this replacement can be done automatically by a
> > > small program.
> >
> > <big snip>
> >
> > Another idea with the same effect, that does not break a single line of
> > existing code ...
> > ( I don't remember whether or not this has also been discussed before.)
> >
> > Let the syntax of the 'include' statement alone, and introduce a new
> > keyword, say 'shared', that can be used, whereever 'global' can be used:
> > shared sequence foo
> > shared function foo()
> > etc.
> >
> > The only difference to 'global' would be, that the 'shared' symbols are
> > only shared between the file where they are defined, and the file that
> > *directly* includes this file.
> >
> > Regards,
> > Juergen
> >
> > --
> > Have you read a good program lately?
> >
>
> I strongly oppose any solution geared to compromise, when a better
> solution is available.
>
> Fix the scope of includes properly, and be done with it. We don't need
> to introduce any new concepts, just ammend the current concept of
> includes.
>
> Chris Bensler
> Code is Alchemy
>
I will elaborate a little bit on my perspective regarding this.
Take C for example, or better yet, C++.
They are both good languages, but they have been severely 'compromised'
for the sake of satisfying immediate demands and for the concern of not
inconveniencing the current user-base.
If backward compatability really is that big of a concern (and I don't
think it is one bit), there are methods that can be taken to introduce
new functionality, and ween out the old, called deprication. Large
software projects almost inevitably have to deal with legacy behaviour
at one time or another, and they do.
Chris Bensler
Code is Alchemy
8. RE: Namespace improvement ?
- Posted by Chris Bensler <bensler at nt.net>
Feb 07, 2005
-
Last edited Feb 08, 2005
Juergen Luethje wrote:
<SNIP>
> The approach with a new keyword such as 'shared' might be even more
> flexible than the 'local/global include' idea:
> The author of a file that will be included in one or more other files
> can decide *for each symbol individually* whether it is local, 'shared'
> or global.
>
> One might say that an additional scope such as 'shared' can be confusing
> for newbies. Maybe, I don't know.
>
> You know that I always supported the 'local/global include' idea in the
> past. But to be honest, we have to face the fact that this also can be
> confusing for newbies:
> Say someone defines a global procedure foo() in a file A, which then is
> 'locally included' in file B. File B is included in file C. Now s/he
> writes foo() in file C, expecting that this will call the procedure in
> file A. We know that this will not work, but a newbie might think:
> I declared procedure foo() as global, so why *isn't* it global?!?
>
> That means a symbol declared as global will only be "really global", if
> the file in which it is defined is "globally included". So some symbols
> will be only "relative global", while others will be "really global".
> ( Or maybe "local global" and "global global" -- SCNR 
)
> *That* is confusing, isn't it?
>
> The more I think about it, the more it seems to me that, when a new
> scope is created, a new keyword for this scope should be used -- for
> the sake of clarity.
>
> Another difference:
> Using 'local/global include', the author of the includ*ing* file(s)
> determines the scope. Using my 'shared' idea, the author of the
> includ*ed* file(s) determines the scope.
> I don't know what is better / more flexible or whatever.
>
> I just wanted to throw the idea with a new keyword for a new scope into
> the discussion, leaving it to the experts to judge about it. But it was
> not meant as a compromise.
>
> Regards,
> Juergen
>
> --
> I didn't have time to write a short letter,
> so I wrote a long one instead.
> [Mark Twain]
>
The problem with 'shared', is that you are simply extending the existing
functionality, instead of rectifying the situation.
People would still be able to make everything global, (and they will)
'shared' would supplement the problem, so if used correctly, they would
be able to produce well insulated code, but the actual problem of
reducing the global pollution is not really addressed.
Also, there is already lots of code in the archives that is casuing
problems already, by the use of global. Using shared would mean that
they have to go back through all of their code, and figure out which
'global's they want to make 'shared' instead. That's alot of work that I
don't think many people will do. So what we end up with is the same
problem, with an optional solution.
That is why I considered it to be a comprimise.
Global include demands that the user specify how they intend for the
library to be used, which IMO is the correct behaviour. I don't care
what the authors intentions were, if I find a good use for a bit of
code, I would like to be able to use it without having to resort to
customizing the lib.
One of my philosophies for programming is that a good program/api never
has to be edited, or even looked at by 3rd parties. If proper
documentation is available, I should never have to look at other peoples
confusing code, and have to figure it out.
Chris Bensler
Code is Alchemy
9. RE: Namespace improvement ?
- Posted by Chris Bensler <bensler at nt.net>
Feb 07, 2005
-
Last edited Feb 08, 2005
Kat wrote:
>
>
> On 6 Feb 2005, at 16:15, Juergen Luethje wrote:
>
> <snip>
>
> > That means a symbol declared as global will only be "really global", if
> > the file in which it is defined is "globally included". So some symbols
> > will be only "relative global", while others will be "really global".
> > ( Or maybe "local global" and "global global" -- SCNR )
> > *That* is confusing, isn't it?
> >
> > The more I think about it, the more it seems to me that, when a new
> > scope is created, a new keyword for this scope should be used -- for
> > the sake of clarity.
> >
> > Another difference:
> > Using 'local/global include', the author of the includ*ing* file(s)
> > determines the scope. Using my 'shared' idea, the author of the
> > includ*ed* file(s) determines the scope.
> > I don't know what is better / more flexible or whatever.
> >
> > I just wanted to throw the idea with a new keyword for a new scope into
> > the discussion, leaving it to the experts to judge about it. But it was
> > not meant as a compromise.
>
> Bach (Eu clone by Karl) uses "import" for a local global to the file
> which
> imports it.
>
> Kat
>
'import' would be my second choice, next to 'global include'.
The problem with import is like I explained for 'shared'. The actual
problem is not being addressed, only supplemented. This means that
people can still use global and contaminate the global namespace just
the same, and they will. Especially if they don't fully understand the
concept of 'import' vs 'include'.
Chris Bensler
Code is Alchemy
10. RE: Namespace improvement ?
Chris Bensler wrote:
>
>
> Kat wrote:
> >
> >
> > On 6 Feb 2005, at 16:15, Juergen Luethje wrote:
> >
> > <snip>
> >
> > > That means a symbol declared as global will only be "really global", if
> > > the file in which it is defined is "globally included". So some symbols
> > > will be only "relative global", while others will be "really global".
> > > ( Or maybe "local global" and "global global" -- SCNR )
> > > *That* is confusing, isn't it?
> > >
> > > The more I think about it, the more it seems to me that, when a new
> > > scope is created, a new keyword for this scope should be used -- for
> > > the sake of clarity.
> > >
> > > Another difference:
> > > Using 'local/global include', the author of the includ*ing* file(s)
> > > determines the scope. Using my 'shared' idea, the author of the
> > > includ*ed* file(s) determines the scope.
> > > I don't know what is better / more flexible or whatever.
> > >
> > > I just wanted to throw the idea with a new keyword for a new scope into
> > > the discussion, leaving it to the experts to judge about it. But it was
> > > not meant as a compromise.
> >
> > Bach (Eu clone by Karl) uses "import" for a local global to the file
> > which
> > imports it.
> >
> > Kat
> >
>
> 'import' would be my second choice, next to 'global include'.
>
> The problem with import is like I explained for 'shared'. The actual
> problem is not being addressed, only supplemented. This means that
> people can still use global and contaminate the global namespace just
> the same, and they will. Especially if they don't fully understand the
> concept of 'import' vs 'include'.
>
> Chris Bensler
> Code is Alchemy
>
>
Only library writers are to bother with the difference of concepts, and they
are not expected to be newbies in programming, so that it is quite likely that
they
understand the difference and use both statements wisely.
The code base for Euphoria as we know it rom the archive is not very large.
It is simply not pragmatic to sxitch from soome semantics to another
breaking a large part of that not-too-large code base.
I agree that the preferrable way to go is to make the tighter scope the default,
while keeping the option to allow some symbols be seen by modules not inclufing
the file directly.
You have to rely on peoples wisdom if you want to achieve anything. We are not
alking
about newbie programmers, they don't write libraries. The following could work:
- Stamp the include statement as deprecated, to be deleted rom sime future
version on;
- Use something akin to Bach's import/promote/demote mechanism, and recommend
it as the preferred coding way;
- Perhaps going as far as issuing a warning on the use if the include statement,
in order to emphasize that it is kind of lazy, unelegant coding which may
hamper further development of the library.
Don't kil current coe. Some talented people had to fight wth the current
situation
in order to come up with reliable libs. The surest path is not always the
shortest.
CChris
11. RE: Namespace improvement ?
Pete Lomax wrote:
>
>
> <snip>
> Sorry to stir this up any more, but somehow I feel a moment of
> clarity.
>
> The complete solution is staring us in the face, however it has a
> price...
>
> Deprecate global completely, or at least live with the consequences it
> creates.
>
> "export" (or some equivalent word) means the variable is visible
> locally, and in the immediately including file, but /no-where/ else.
> Most importantly, the variable is NOT visible to files it includes.
> ************************************************************************
> If an include file needs to see a variable, it must explicitly include
> the file it is defined in, which may be the parent (!!). [Doing this
> does not currently cause _any_ problems].
>
> The cost is that eg
> include win32lib.ew
> might need to become
> include win32lib.ew
> include w32advapi.ew
> include w32comctl.ew
> include w32comdlg.ew
> include w32DLL.ew
> include w32file.ew
> include w32gdi.ew
> include w32Kernel.ew
> include w32Keys.e
> include w32msgs.e
> include w32ole.ew
> include w32Shell.ew
> include w32sock.ew
> include w32support.ew
> include w32tk.e
> include w32user.ew
> include w32winmm.ew
> and equally that most of those included files would need to explicitly
> include win32lib.ew and some of their siblings.
>
> Obviously not all programs would require the full set, and it would be
> perfectly possible to "wrap" all routines in a library which you want
> to been seen externally at the top level, so none of the above are
> necessary.
>
> This WOULD solve ALL the problems. I don't need to add cmiiw.
>
> This, obviously, IS NOT GOING TO HAPPEN UNLESS someone makes the
> required changes to eu.ex and gets most of the standard programs and
> libraries working. I would love to do this, but I have other things to
> attend to. While I share some of your grievances, PLEASE STOP WHINGING
> AT ROB (OR EACH OTHER), IT WON'T F***ING HELP!!!
>
> With apologies,
> Pete
> PS I might suggest that no "export" identifier can ever be referenced
> without a namespace qualifier, being an easier way to force this.
>
Some of us would like to see Euphoria do better than it is.
I for one would like to see well planned solutions, which do not
infringe on my coding ability or add alot of extraneous work to
compensate for bad designs.
I'm not talking about adding a new scope. I'm talking about ammending a
current one.
Anyways, enough, I really don't care enough to bother arguing about this
kind of crap. I have no delusions of RDS getting off their butt and
doing anything constructive with euphoria's future.
As far as I'm concerned, it's a lost cause already.
I just can't resist trying to be helpful. That's my fault, and I
apologize for trying.
Chris Bensler
Code is Alchemy
12. RE: Namespace improvement ?
Pete Lomax wrote:
>
>
> Chris Bensler wrote:
> >I just can't resist trying to be helpful.
> Your dictionary has a different definition of helpful to mine.
>
> Pete
>
Are you trying to say that not everybody thinks alike? What a
revelation. I think that's why people often have DEBATES, like Juergen
and I were involved in.
Chris Bensler
Code is Alchemy
13. RE: Namespace improvement ?
- Posted by Georg Wrede <georg at iki.fi>
Feb 09, 2005
-
Last edited Feb 10, 2005
Ehhh, we are not getting anywhere with this discussion.
Lemme phrase the problem in another way:
Andy has written a low level file he wants "The B kind of people" to
include in their projects. He documents it meticulously.
Ben stumbles upon this file, and decides to write a high level file
to do more elaborate things. He reads Andy's docs and starts to write.
Obviously, Ben assumes that Andys variables and functions will not
pollute Ben's "clients'" namespace. Ben documents diligently what
functions and constants he wants his "clients" to use. Those he also
explicitly makes visible to the "includer" of his file.
Carl finds Ben's file, and its documentation. He decides to use it
in his following application. Naturally, he assumes, the only
things that he has to be carerul with, are the names that Ben has
documented.
The next-to last thing he could possibly fear is, that a lot of
Ben's undocumented crap pollutes his namespace.
But, the very ultimate thing (he couldn't even begin to fear) is,
that all kinds of crap from _Andys_ file would crap his namespace.
Heck, Ben's never even told anybody that he'd never've been able to
write his own file without Andy's excellent low level routines,
constants and stuff. So, Carl never saw the train that came and
squashed him right in the intersection.
((You better read the above twice before reading the rest.)) 
--------------------------
Put it another way:
(Disclaimer: in the following I've used author names from this
forum. The names have been chosen totally arbitrarily, to create
a sense of reality here. Please, anybody, don't get offended.)
I write a library for machine-to-machine communication. This library
is all about MAC addresses and Bootp and stuff.
Chris Bensler sees this, and writes a library for reliable file
transfer on top of this, that can also be used to transport messages.
Pete Lomax sees Chris' library and writes a distributed file
system on top of that.
Patrick Barnes sees Pete's file system, and decides to write a
computer farm operating system on top of it.
Now, the late, Carl Sagan sees Patrick's library, and decides to
write a "truly" global app on top of it, to finally find the
Extra Terrestials. (No disrespect intended here!)
------
My question is: who in the previous train of programmers wants
his namespace occupied by gratuitious entities????????????
Aren't they all happy with what's documented and relevant to the
immediate Purpose of the (single) library each of them are using?
If Carl Sagan wanted to use some (or all) of the routines in
my original Machine-To-Machine library, wouldn't he import it
explicitly???? And the same with Pete's stuff, right? So Carl
Sagan would be happy with Pete's stuff, -- BUT ONLY if he wanted
it himself. And definitely not by Pete's stuff secretly sneaking
in Carl's namespace, just because he happened to "use" Patrick's
code.
-----------
If I write code in Euphoria, I _WANT_ to _not_ know about the
thousands of constants and functions that exist within Windows.
If I explicitly "import", "include" (or whatever the word would
be called tomorrow) some library, I definitely want to only have
to deal with what the library author advertises as useful.
I want to receive HTTP messages without knowing about MAC addresses.
Or without having to search through trees of include files -- just
to see if my mysterious bug was because I happened to step on a
name defined in the ancestor of my import's great grandfather.
Or even my import's father.
-- Another Euphoric, since Nov. 18, 2004 --
14. RE: Namespace improvement ?
Patrick Barnes wrote:
>
>
> I agree with your examples... we need a better way of managing scope.
> Rob! Are you truly happy with the namespacing and scoping system? You
> shouldn't be, it (as has been shown many times) is full of problems.
>
> On Wed, 09 Feb 2005 14:08:42 -0800, Georg Wrede
> <guest at rapideuphoria.com> wrote:
> > Patrick Barnes sees Pete's file system, and decides to write a
> > computer farm operating system on top of it.
>
> What on earth is a computer farm operating system? I mean, I suppose
> I'm flattered that I'd write something I had no idea about.
>
> --
> MrTrick
>
I agree with George's analogy also. Well put George.
Unfortunately, the issue is not what the problem is, but how to resolve
it.
Did you know that this issue has been raised since early in 1999?
If we, as users of Euphoria can't even agree on how to address the
problem, I wouldn't expect Rob to assert his veto-power and 'do what's
best for us'. We've all seen the outcome of that.
Until Rob decides to establish some structured support and development
practices that *includes* the participation of Euphoria's users, we are
doomed to quarrel about things that will never be resolved.
The only alternative and successfull method I know of, is if someone
does it themselves, Rob likes it, and implements it officially.
( A la Matt Lewis )
Chris Bensler
Code is Alchemy
