Re: Namespace (Is that your final answer?)
On Wednesday 27 June 2001 13:10, Derek Parnell wrote:
> Its getting a little confusing for me. I was thinking that you were talking
> about a v2.3 that would allow duplicate global definitions and thus would
> NOT be warning you. Of course v2.2 searches the global list so it can warn
> you of this situation.
If Euphoria were to allow duplicate (global) identifiers without warning,
that would no doubt be a disaster. My point was only that, rather than
giving you a warning of the name and location of the SECOND identifier,
it might just as well give you the name and location of BOTH conflicting
identifiers - seems more useful, somehow.
<snip a bunch to save space>
> > If you don't know which "pi" to USE, how on
> > earth are we to trust you to CHANGE the SOURCE of the file
> > where "pi" is declared - thus breaking not only your own program,
> > but everyone else's as well?
>
> I hope you are not alluding to my ability (or lack thereof) in maintaining
> Win32Lib.ew. I would be very hurt and offended if you were.
Worded more tactfully:
The basic principle remains, however, that it must be
the responsibility of the author of a package to insure that it is
bug-free. It cannot be the author's responsibility to ensure it will work
under a limitless number of conditions that are impossible to forsee.
The person who implements a system using the author's code at
least has a limited scope of problems to deal with. Firstly,
the problem of making her code work with the authors' code,
and secondly, assuring that her action - that of combining two items
that were never guaranteed to work together - hasn't caused complications.
That's why control must be given to the implementor, so that problems
arising from that specific implementation can be resolved -for that
implementation- without affecting past, current or future implementations
which also happen to use the package in question.
> But the discussion, I thought, was (hypothetically) from the point of view
> of a person writing a program that included file.c (eg win32lib.ew) which
> in turn included file.a (eg machine.e) and file.b (eg dll.e). If so, that
> person would NOT be changing anything in file.c (ie win32lib.ew) .
One would hope not, and my whole intent was to avoid the necessity
of having the user change win32lib or any other code which is beyond
his control.
Suppose that win32lib calls a function in tk_math - global function abs() for
example. Which it does.
Now, I also need package x in my program. Package x also contains
a function abs(). It makes no difference whether I include package x
before, or after I include win32lib - there are still conflicts.
My options, as of now, are:
1. Forget using package x, and write my own. (beyond my abilities?)
2. Modify package x (with all the problems that entails)
3. Modify tk_math (ditto - with the added problem that then I would have to
also modify win32lib, since it calls functions in tk_math which I would
have just renamed)
None of these are good options. The most sensible thing to do is to
be able to make temporary changes to any file I like, changes that do not
affect the original files, changes that can continue to be applied against
all new versions of win32lib, tk_math, package x, etc... as they are
released (provided the new version still has the same global names)
<snip some more>
> > > wants. Call it defensive coding if you like.
> >
> > Here, I agree with you. That was what prompted my comment that
> > library files should be required to use the extended "include ... as"
> > syntax. The current alternative is to use names so obscure that
> > no one else would ever dream of using them. We're finding that
> > that's not a practical alternative.
>
> Thanks. In my case with win32lib.ew , when namespaces come out in v2.3,
> I'll be upgrading win32lib.ew et al with fully qualified references to
> symbols that are defined in any included files, in an attempt to alleviate
> problems for people using win32lib.ew. Unfortunately, it means that I will
> have to maintain and publish a v2.2 and a v2.3+ version of the library. I'm
> thinking of keeping the master source with embedded #define type of
> directives and using a utility to generate the v2.2 and v2.3+ source codes.
> Not a pleasant thought.
No, it isn't. And I'm afraid I can't think of any easier way to work around
that problem, which will exist as long as a large number of people continue
to use 2.2. The solution (daydreaming here) is for Rob to incorporate so
many great frequently-asked-for improvements that everyone will jump
at the chance to upgrade (and send RDS gobs of money, btw).
> > include file.c using pi from file.a -- simple, no?
>
> Simple, yes. Provided that there is only ONE such exception to deal with.
> Should we have something like ...
>
> include file.c using pi,delta,theta from file.a
> and using alpha,epsilon from file.b
> and using zeta,omega,gamma from file.f
> and ... (you get the picture)
Point well taken. How about
include file.c using * from file.a,
alpha from file.b -- overrides alpha from file.a
etc....
I have the feeling that this will not be a major issue, since in practice
the number of globals tend to be limited, hence the number of conflicting
names would also be limited.
> > There's no other place where you can expect to control
> > the names of globals, except AT THE TIME EUPHORIA LOADS THEM.
> > And that's the appropriate place to do so, since you are the only
> > one who is using that exact combination of files. You have,
> > by electing to use a set of include files, created a unique situation.
> > It's up to you to make that situation work, not by having others
> > change their code, nor by you changing their code, but by
> > YOU changing YOUR code. Euphoria should make this
> > easy. I think the method described above is straightforward
> > and simple. Best of all, it can't BREAK anything, AFAIK.
>
> You're correct in that it won't break anything. I guess my only really
> hesitancy is around the idea that it puts a burden on the wrong person. I
> means that the person using file.c has to resolve the problem, where as I'd
> have wanted the author of file.c to have the burden of making there product
> bullet proof in the first place. But of course, that just isn't always
> possible with legacy library files.
Bullet-proof can only last until someone comes along with a bigger bullet...
The problem here is that the author of the library is going to find it very
difficult to live long enough to test his / her library with each and every
combination of the other 800+ possible includes that a third party might
decide to use.
Example:
You write a program.
It uses Jiri's fine fonts package.
You also find a need for Kat & Gabriel's neat strtok.
Now, both of these packages are wonderfully written and dependable,
written by fine programmers. However, that doesn't mean that Kat, Jiri,
Gabriel, have tested their programs together to make sure there are no
conflicts. Maybe they have, I don't know, but have they tested against
all 800 that you might just happen to pick for your project? Is this even
possible?
> In short, I think that your suggestion should be considered by RDS, in
> addition to Euphoria also enabling library authors to reduce the chance of
> name clashes happening in future.
>
> In fact, I just had a thought. In another message I suggested an "insert"
> feature. If something like this was available, it means that I, as
> maintainer of win32lib.ew, could create a file that contained the fully
> expanded list of "using" phrases and you as a user of win32lib, could
> insert that file. This would make it my responsiblity to keep win32lib
> correct rather than its users.
>
> eg. In your program you could code...
>
> include win32lib.ew @"win32lib.us" as w32
>
> where the file called "win32lib.us" would look like ...
>
> using open_dll, ... from dll.e
> and using message_box from msgbox.e
> and using (... etc...)
This is a fine idea. In fact, Win32Lib might just contain a single "include"
line which includes the aforementioned list. You could change a lot of
things without everyone having to download a new Win32Lib version,
just the new list.
If Rob would incorporate an error handler along the
lines of :
---------
Hey - Win32Lib needs the function message_box from msgbox.e!
---------
That would make it easy for people to determine if they had the right
setup. If you could add a version number somehow, that would further
ensure a workable system.
--------
Win32Lib needs msgbox.e version 1.2 or above - but yours is version 1.0
Please upgrade the file msgbox.e
--------
Regards,
Irv
|
Not Categorized, Please Help
|
|
