1. namespace-nonproblem
Let me check I got this straight. You have 2 or more include files
written by different people, but when you include them one attempts
to redefine a global variable or routine or constant.
Isn't the easiest course of action to edit the offending source file
and change the identifier?
Matthew McNamara _
mat at iconz.co.nz o( )
The Internet Company of New Zealand / /\
2. Re: namespace-nonproblem
> Let me check I got this straight. You have 2 or more include files
> written by different people, but when you include them one attempts
> to redefine a global variable or routine or constant.
Right.
> Isn't the easiest course of action to edit the offending source file
> and change the identifier?
Well, sure, global search and replace is rarely a problem. But on the other
hand, you'll have to do this all over with a future version of the library,
and there's no guarantee that you'll get them all anyway. It's ultimately
more trouble than it's worth.
Even on computers like the Commodore 64, which I do a fair amount of work on
(currently constructing a DOOM clone for it), modules keep their own
namespaces of a sort. All of my routines have their own workspaces, and
modules communicate through predeclared tracts of shmem. So even older systems
which had no overt object encapsulation or anything like that still had
rudimentary namespace considerations.
--
Cameron Kaiser * spectre at sserv.com * http://www.sserv.com/
--
Visit the leading Internet starting point today!
http://www.sserv.com/
--
3. Re: namespace-nonproblem
At 02:13 AM 4/23/98 +1200, Matthew McNamara wrote:
>Let me check I got this straight. You have 2 or more include files
>written by different people, but when you include them one attempts
>to redefine a global variable or routine or constant.
>
>Isn't the easiest course of action to edit the offending source file
>and change the identifier?
>
Ah...no.
For several reasons:
1. You will have to ship the edited file(s) along with your program
to everyone who uses it. Now there will be two versions of that
file -- eventually 3 or 5 or 12..... now which one is the right one?
2. The modified file will "break" most if not all previous programs
written to include it. (Guaranteed to upset folks.)
3. Sometimes names make sense. It is a shame to change
them to something less intuitive, simply because you have
already used that name for something else.
Irv
----------------------------------------------------------
--Visit my Euphoria programming web site:--
--http://www.mindspring.com/~mountains --
----------------------------------------------------------
4. Re: namespace-nonproblem
On Wed, 22 Apr 1998, Irv Mullins wrote:
> At 02:13 AM 4/23/98 +1200, Matthew McNamara wrote:
>
> >Let me check I got this straight. You have 2 or more include files
> >written by different people, but when you include them one attempts
> >to redefine a global variable or routine or constant.
> >
> >Isn't the easiest course of action to edit the offending source file
> >and change the identifier?
> >
> Ah...no.
> For several reasons:
> 1. You will have to ship the edited file(s) along with your program
> to everyone who uses it. Now there will be two versions of that
> file -- eventually 3 or 5 or 12..... now which one is the right one?
Do you really want your users to modify your source code? 
Only library authors would worry about distributing maintainable source
code, and a library author would not have this problem in the first case.
The aim here is to use more than 1 library to create an application,
not to create another library. (or am I missing something?)
> 2. The modified file will "break" most if not all previous programs
> written to include it. (Guaranteed to upset folks.)
So have more than 1 copy.
> 3. Sometimes names make sense. It is a shame to change
> them to something less intuitive, simply because you have
> already used that name for something else.
>
Unless you're in the business of making libraries from other
libraries, identifiers are not important. At the end of the
day what matters is that your spreadsheet (or whatever
application) worked out your tax correctly and displayed it
in a warm and satisfying shade of pink.
> Irv
> ----------------------------------------------------------
> --Visit my Euphoria programming web site:--
> --http://www.mindspring.com/~mountains --
> ----------------------------------------------------------
>
Matthew McNamara _
mat at iconz.co.nz o( )
The Internet Company of New Zealand / /\
5. Re: namespace-nonproblem
Matthew: No flames intended, but I think you might
have missed something here:
>> At 02:13 AM 4/23/98 +1200, Matthew McNamara wrote:
>>
>> >Let me check I got this straight. You have 2 or more include files
>> >written by different people, but when you include them one attempts
>> >to redefine a global variable or routine or constant.
>> >
>> >Isn't the easiest course of action to edit the offending source file
>> >and change the identifier?
>> >
>> Ah...no.
>> For several reasons:
>> 1. You will have to ship the edited file(s) along with your program
>> to everyone who uses it. Now there will be two versions of that
>> file -- eventually 3 or 5 or 12..... now which one is the right one?
>
>Do you really want your users to modify your source code?
Not particularly, but wasn't that what you were suggesting would
be the "easiest course" -- to modify somebody else's code?
>Only library authors would worry about distributing maintainable source
>code, and a library author would not have this problem in the first case.
Gee, I guess I don't have to worry anymore about maintaining
the half-million lines of code I have written for various clients
over the past 15 years. Whotta relief! Good thing none of them
were libraries.
>The aim here is to use more than 1 library to create an application,
>not to create another library. (or am I missing something?)
>> 2. The modified file will "break" most if not all previous programs
>> written to include it. (Guaranteed to upset folks.)
>
>So have more than 1 copy.
More than 1 copy with the same name? Possible, but is it a
good idea? I'm not so sure. Maybe each copy could include
a list of programs it is designed to be compatible with.
>> 3. Sometimes names make sense. It is a shame to change
>> them to something less intuitive, simply because you have
>> already used that name for something else.
>>
>
>Unless you're in the business of making libraries from other
>libraries, identifiers are not important.
They aren't?
> At the end of the
>day what matters is that your spreadsheet (or whatever
>application) worked out your tax correctly and displayed it
>in a warm and satisfying shade of pink.
Better if it works until the check clears the bank.
If you want to eat next year as well, you'll develop a
keen interest in maintainability.
Irv
----------------------------------------------------------
--Visit my Euphoria programming web site:--
--http://www.mindspring.com/~mountains --
----------------------------------------------------------
6. Re: namespace-nonproblem
>> 2. The modified file will "break" most if not all previous programs
>> written to include it. (Guaranteed to upset folks.)
>
>So have more than 1 copy.
Huh? You're thinking as a single-user.
>> 3. Sometimes names make sense. It is a shame to change
>> them to something less intuitive, simply because you have
>> already used that name for something else.
>>
>
>Unless you're in the business of making libraries from other
>libraries, identifiers are not important. At the end of the
>day what matters is that your spreadsheet (or whatever
>application) worked out your tax correctly and displayed it
>in a warm and satisfying shade of pink.
Same as above, lack of future vision. What if you develop a neat library
that enables spreadsheet pop-up windows? Would you like to share it with
others (comercially or not)? Even if that isn't the case, will you be in the
mood of "patching" your code after several months?
A more complex namespace mechanism is required by Euphoria, that's no doubt.
How will it work is a matter Rob and Junko must resolve... and soon.
A simple example:
When I started coding my database engine I wanted to have separte libraries
(.e) for diferent tasks (index, import, maintanance,...), so it would be
easy to update, i.e, the indexing engine by simply replacing the proper
file. My implementation relies on global variable for holding diferent
workspaces.
Is there currently a (simple) way of having all this modules access the same
global variable(s), without getting into the "user" namespace? The answer is
no. I just have options, tell the user to don't use some name-identifier my
library uses, or have each function of my library passing each other an
extra parameter with the desired information (more error-prone). Wouldn't it
be useful we can declare a variable as global to a defined set of modules
(currently your identifiers are either local or completly global)?
Regards,
Daniel Berstein.
