OpenEuphoria

RE: Multiple includes (was: Rob's going to hate me... (Remainder bug))

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Nov 11, 2003
• 516 views

Irv Mullins wrote:
> 
> 
> On Monday 10 November 2003 12:59 pm, Matt wrote:
> 
> > 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).  

Not true.  Consider that when you create a control, you get back an id.  
So when you call EuGrid to create a new grid, there's no way to tell it 
who it's parent should be, since the id in your instance of win32lib 
will be meaningless to EuGrid's win32lib.


> 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 ?  :)

Yep. :)


> > > 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."

<snip>

> > 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.

I suppose we'd have to get Rob to declare exactly which benefits he 
meant.  I'm sure he didn't mean "implement Java/C++/whatever-style OOP 
easily in Euphoria."  And 'easy' is always in the eye of the beholder.

Matt Lewis