1. RE: Multiple includes (was: Rob's going to hate me... (Remainder bug))
Irv Mullins wrote:
>
> On Sunday 09 November 2003 01:34 pm, you wrote:
> >
> >
> > Al Getz wrote:
> >
> > 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.
<snip>
> 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 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] :)
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.
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. Probably,
the 'instantiated' namespaces would have to be unique and global, but
I'm not sure exactly what's needed to maintain order. I just not
convinced that all the implications of this have been thought out.
My opinion (in keeping with my earlier posts) is that your link method
is equivalent to copying the file to a new name each time you want to
instantiate it. I think that this behavior should be left alone [by
Rob], but documented better as Linux only (unless MS shortcuts work?).
> 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.
Matt Lewis
2. RE: Multiple includes (was: Rob's going to hate me... (Remainder bug))
Pete Lomax wrote:
>
>
> On Mon, 10 Nov 2003 11:01:33 -0500, Irv Mullins <irvm at ellijay.com>
> wrote:
>
> >Why does there need to be any new keyword?
> Try this trick on say win32lib or your EuGTK and see how far you get.
>
> BTW, your web page crashes IE6.0
If you are referring to http://ellijay.com/users/irvm/
it doesn't crash my IE... (Version: 6.0.2800.1106.xpsp2.030422-1633
running on XP)
-- Brian
3. RE: Multiple includes (was: Rob's going to hate me... (Remainder bug))
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
4. RE: Multiple includes (was: Rob's going to hate me... (Remainder bug))
Irv Mullins wrote:
> This has nothing to do with what those namespaces are called in
> other files, There's no reason you should have to edit other files
> or third party source. You know this is true, because namespaces
> are never passed on.
This is exactly my point. How could another file refer to a specific
instance of a file?
Matt Lewis
5. RE: Multiple includes (was: Rob's going to hate me... (Remainder bug))
On 11 Nov 2003, at 11:45, Matt Lewis wrote:
>
>
> Irv Mullins wrote:
>
> > This has nothing to do with what those namespaces are called in
> > other files, There's no reason you should have to edit other files
> > or third party source. You know this is true, because namespaces
> > are never passed on.
>
> This is exactly my point. How could another file refer to a specific
> instance of a file?
What about Bach's "import as......." ?
Kat
6. RE: Multiple includes (was: Rob's going to hate me... (Remainder bug))
- Posted by kbochert at copper.net
Nov 11, 2003
On 11 Nov 2003 at 16:58, Al Getz wrote:
>
>
> Matt Lewis wrote:
> >
> >
> > Irv Mullins wrote:
> >
> > > This has nothing to do with what those namespaces are called in
> > > other files, There's no reason you should have to edit other files
> > > or third party source. You know this is true, because namespaces
> > > are never passed on.
> >
> > This is exactly my point. How could another file refer to a specific
> > instance of a file?
> >
> > Matt Lewis
> >
>
> As it stands, the 'new include' technique would refer to a
> *local* instance only. This means the included file acts
> as a local resource similar to the way local variables work.
> This should make it pretty easy to implement too.
>
> As noted before:
>
> --rect.ew
> atom x1,y1,x2,y2
> x1=0
> y1=0
> x2=0
> y2=0
>
>
> --file.exw
> include new rect.ew as r1
> include new rect.ew as r2
> r1:x1=10
> r1:y1=10
> r2:x1=20
> r2:y1=20
>
>
> Here, each rect refers to a different set of x and y variables
> even though only one include file was needed. In other words,
> we were able to use two different objects (rects in this case)
> of the same type that needed to be described only once in
> rect.ew . This is also a powerful technique, considering the
> original file can be extremely complex in itself but used
> more then once for more then one object by simply declaring
> it a second or more times taking up only one more line of code.
>
> Take care,
> Al
Is this not just a subset of what even simple objects supply?
--rect.ew
class Rect
atom x1,y1,x2,y2
x1=0
y1=0
x2=0
y2=0
end class
--file.exw
include rect.exw
Rect r1, r2
r1.x1=10
r1.y1=10
r2.x1=20
r2.y1=20
Karl Bochert
7. RE: Multiple includes (was: Rob's going to hate me... (Remainder bug))
- Posted by kbochert at copper.net
Nov 11, 2003
On 11 Nov 2003 at 20:43, Al Getz wrote:
>
> Hi Karl,
>
> Not sure what you mean here since Eu doesnt handle
> dots (.) for classes, nor classes directly. Could you
> explain a little more please?
>
> Take care,
> Al
>
Neither does Eu handle 'incude new'.
OO is a much cleaner (and more powerful) way of adding
that kind of functionality.
Neither 'include new' nor OO will be implemented in Euphoria.
At least OO can be added on as a library.
Karl Bochert
