1. Re: Multiple includes (was: Rob's going to hate me... (Remainder bug))
On Monday 10 November 2003 12:59 pm, Matt wrote:
> I agree that multiple aliases in a single file is unlikely/silly, but
> how would you handle the case of different files including the file?
> For instance, you might be writing a win32lib app, and using some
> library, say, EuGrid, which also includes the library (or an analog
> using EuGTK).
>
> Q: What would happen if both used a [different] namespace for win32lib?
> A: "It *will* cause errors." [so please don't ignore] :)
Since the so-called "global" variables/routines in Win32Lib are invisible
to my program which uses EuGrid, then the only copy I could access
would be the copy I included in my own code. No errors, just doubling up
on the amount of code loaded (a severe problem, I admit, but not a source
of errors).
> I think it's pretty obvious that I DON'T want to have multiple instances
> of win32lib. To do this correctly, it seems to me that you would need
> 1) an additional keyword, plus 2) the ability to see and use namespaces
> from other files.
True. I think #2 is absolutely necessary, even without the ability to do
multiple includes. The current namespacing scheme is nice enough to
warn you if you have a variable or routine "x" declared in two or three files,
and asks you to qualify them.
This is ok for writing simple programs, but it is absolutely useless when
writing a library to be used by others (win32lib, eugtk, etc.) because all
that hard work of setting up namespaces disappears as soon as someone
includes your library. There has to be a way to pass these namespaces on
thru more than one level of code.
I think if that can be solved satisfactorily, then the problem of including
large files like win32lib will also be solved in a similar way.
I have no problem with a new keyword, if that helps.
"import stuff.e as foo" (with the as ... clause being mandatory) for example.
This would always be a private copy, used by the importing module only.
Then globals should either be really global (visible to anything down the
line), or we should be able to specifically "export funcA as foo" to make
them visible by name.
The whole namespacing "just ain't right".
> Without either one large projects become difficult to impossible
> (something, IIRC, about which you [Irv] and others have noted Euphoria's
> shortcomings in the past), since your method clearly doesn't qualify for
> the "if you don't need it, then just don't use it" category.
As opposed to the current "If we don't use it, you don't need it" philosophy ?
:)
<snip>
> > A quote from the Euphoria reference manual:
> > "Euphoria is not an "object oriented" language, yet it achieves
> > many of the benefits of these languages in a much simpler way."
> >
> > When RDS was implementing namespacing, they had an opportunity
> > to make that statement true. Unfortunately, they chose instead to
> > implement a marginally useful patch for a subset of the namespacing
> > problem.
>
> Well, it is true IMHO, just not in the way that you would like.
I disagree, and the number of OOP libraries contributed seems to disagree.
I don't think the writers of those libraries would say that Euphoria made it
possible to implement those features "in a much simpler way", either.
Regards,
Irv
