Re: Multiple includes (was: Rob's going to hate me... (Remainder bug))
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: <EUforum at topica.com>
Subject: Re: Multiple includes (was: Rob's going to hate me... (Remainder bug))
>
>
> On Sunday 09 November 2003 01:34 pm, you wrote:
> >
> >
> > Al Getz wrote:
> >
> >
> > Hello again,
> >
> > I forgot to mention that i favor a new keyword also for what
> > i have been calling "new include" all this time.
> > The 'include' keyword certainly cant be touched now or it
> > would break code beyond belief 
>
> Why does there need to be any new keyword?
> It seems to me that if you type:
> include mylib.e as a
> include mylib.e as b
> then you should have two instances of everything that is exported by mylib.e.
> a:x
> b:x
> a:foo()
> b:foo()
> where a:x and b:x can contain different values, and so on.
> Your intentions were clear: include that stuff under two different names.
>
> The present setup, where a:x and b:x both point to the same instance, seems
> illogical. Making (b) just an alias for (a) seems only useful if you want to
> make your code obfuscated. What possible valid reason could there be for
> NOT allowing the programmer to achieve what s/he very obviously intended to
> do?
>
> PS: any excuses about "it might cause errors" will be cheerfully ignored. I'm
> using Aku's workaround to do multiple includes, and I've had no problems.
> But we really shouldn't have to jury-rig our code just so we can do something
> useful.
I agree that the current 'alias' feature is a useless and clueless facility.
However, it does exist. Therefore, to allow backward compatability a new key word
is required. If backward compatability is not an issue, then we do NOT need a new
key word.
But more importantly, I think that multiple instances of the same include file
is against RDS's programming philosophy and thus its not going to happen (in
Euphoria anyway).
> 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.
>
Agreed. But it took ages, and many people hammering RDS for a namespace
solution. It seems that RDS deliberately chose the smallest subset that would be
easy to implement and solve most issues people were concerned about. I agree that
this compromise gave us a crippled product. My point is though, I don't think
that RDS is not going to radically change it again. In 2.5 we are told that there
will be a small improvement, but that's all I would expect in the namespace
functionality from RDS.
I hope I'm very, very wrong.
--
Derek
|
Not Categorized, Please Help
|
|
