1. Do you currently use namespaces?
Please respond with a yes or no. We are simply curious how widely used the
feature is as this point.
--
Jeremy Cowgar
http://jeremy.cowgar.com
2. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> Please respond with a yes or no. We are simply curious how widely used the
> feature
> is as this point.
Yes. Even when not required to.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
3. Re: Do you currently use namespaces?
no
Ken Rhodes
Folding at Home: http://folding.stanford.edu/
100% MicroSoft Free
SuSE Linux 10.3
No AdWare, SpyWare, or Viruses!
Life is Good, 
4. Re: Do you currently use namespaces?
No
CChris
5. Re: Do you currently use namespaces?
no
6. Re: Do you currently use namespaces?
No
7. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> Please respond with a yes or no. We are simply curious how widely used the
> feature
> is as this point.
Yes.
Minimally, to resolve conflicts.
Matt
8. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> Please respond with a yes or no. We are simply curious how widely used the
> feature
> is as this point.
>
No.
Salix
9. Re: Do you currently use namespaces?
Yes.
10. Re: Do you currently use namespaces?
no.
11. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> Please respond with a yes or no. We are simply curious how widely used the
> feature
> is as this point.
Yes.
12. Re: Do you currently use namespaces?
No.
13. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> Please respond with a yes or no. We are simply curious how widely used the
> feature
> is as this point.
> ...
no
Arthur Crump
14. Re: Do you currently use namespaces?
yes
15. Re: Do you currently use namespaces?
No
16. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> Please respond with a yes or no. We are simply curious how widely used the
> feature
> is as this point.
I've never needed to, but only because I haven't done any large projects.
So, no.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
17. Re: Do you currently use namespaces?
No, because it never really worked that well.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
18. Re: Do you currently use namespaces?
Yes, I use namespaces, as like Derek even when not required, for clarities sake.
--
Jeremy Cowgar
http://jeremy.cowgar.com
19. Re: Do you currently use namespaces?
No, except when forced to resolve conflicts
20. Re: Do you currently use namespaces?
> On 22 May 2008 at 9:53, Pete Stoner wrote (maybe snipped):
>
> No, except when forced to resolve conflicts
>
Same here.
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
21. Re: Do you currently use namespaces?
- Posted by Matt Lewis <matthewwalkerlewis at gm?il.co?>
May 22, 2008
-
Last edited May 23, 2008
Bernie Ryan wrote:
>
>
> No, because it never really worked that well.
I hear this complaint a fair amount. Bernie, could you elaborate on what
didn't work well for you?
Thanks,
Matt
22. Re: Do you currently use namespaces?
- Posted by Bernie Ryan <xotron at blue?ro?.com>
May 22, 2008
-
Last edited May 23, 2008
Matt Lewis wrote:
>
> Bernie Ryan wrote:
> >
> >
> > No, because it never really worked that well.
>
> I hear this complaint a fair amount. Bernie, could you elaborate on what
> didn't work well for you?
>
Matt:
When ever I tried to use it was because I ran into a conflict with
a function name so I would assign some qualifier to the include file.
Then when I added that include file some function would conflict with
some other file. In larger programs it just cascaded into having to
add too many function qualifiers. I became very frustrated, so I quit
using other user's libraries and just started writing my own functions
and using only libraries that come with the Euphoria install.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
23. Re: Do you currently use namespaces?
- Posted by gshingles <gshingles at g?ail.?om>
May 22, 2008
-
Last edited May 23, 2008
Jeremy Cowgar wrote:
>
> Please respond with a yes or no. We are simply curious how widely used the
> feature
> is as this point.
No. But I would a lot more if they provided a greater degree of OO. For example
if the namespace was declared in the include file rather than by the end user,
and if the namespace was taken from the relative path name and folders, like
-- math/matrix.e
package math:matrix
constant VERSION = 1.2.3
type matrix ...
function identity()
..etc
export matrix,identity(),mult(),add(),VERSION
-- program
include math:matrix.e
matrix bob
bob = identity()
if isa(bob,math:matrix.e) then
puts(1, "It's from the matrix include")
end if
Like Perl :)
But that's a large thorny topic so I'm happy with the current system as it is
until around version 6...
Gary
24. Re: Do you currently use namespaces?
- Posted by Matt Lewis <matthewwalkerlewis at gmai??com>
May 22, 2008
-
Last edited May 23, 2008
Bernie Ryan wrote:
>
> Matt Lewis wrote:
> >
> > Bernie Ryan wrote:
> > >
> > >
> > > No, because it never really worked that well.
> >
> > I hear this complaint a fair amount. Bernie, could you elaborate on what
> > didn't work well for you?
> >
>
> Matt:
>
> When ever I tried to use it was because I ran into a conflict with
> a function name so I would assign some qualifier to the include file.
> Then when I added that include file some function would conflict with
> some other file. In larger programs it just cascaded into having to
> add too many function qualifiers. I became very frustrated, so I quit
> using other user's libraries and just started writing my own functions
> and using only libraries that come with the Euphoria install.
Is this an accurate example of what you were seeing?
-- libfoo.e
global procedure baz(...)
...
baz(...)
-- libbar.e
global procedure baz(...)
...
baz(...)
-- app.ex
include libfoo.e
include libbaz.e
....
In other words, there were conflicts not just in your code, but within
the libraries themselves? This was a problem. It's fixed now.
Otherwise, it sounds like they were doing exactly what they were designed
to do. How else would you have solved the problem?
Matt
25. Re: Do you currently use namespaces?
No.
Dan M.
26. Re: Do you currently use namespaces?
rarely, only to resolve conflict.
jacques d.
27. Re: Do you currently use namespaces?
Matt Lewis wrote:
>
> Bernie Ryan wrote:
> >
> > Matt Lewis wrote:
> > >
> > > Bernie Ryan wrote:
> > > >
> > > >
> > > > No, because it never really worked that well.
> > >
> > > I hear this complaint a fair amount. Bernie, could you elaborate on what
> > > didn't work well for you?
> > >
> >
> > Matt:
> >
> > When ever I tried to use it was because I ran into a conflict with
> > a function name so I would assign some qualifier to the include file.
> > Then when I added that include file some function would conflict with
> > some other file. In larger programs it just cascaded into having to
> > add too many function qualifiers. I became very frustrated, so I quit
> > using other user's libraries and just started writing my own functions
> > and using only libraries that come with the Euphoria install.
>
> Is this an accurate example of what you were seeing?
> }}}
<eucode>
> -- libfoo.e
> global procedure baz(...)
>
> ...
> baz(...)
>
> -- libbar.e
> global procedure baz(...)
>
> ...
> baz(...)
>
> -- app.ex
> include libfoo.e
> include libbaz.e
>
> ....
> </eucode>
{{{
>
> In other words, there were conflicts not just in your code, but within
> the libraries themselves? This was a problem. It's fixed now.
>
> Otherwise, it sounds like they were doing exactly what they were designed
> to do. How else would you have solved the problem?
>
Matt:
I can't remember a good example of why I stopped using it off hand.
The next time I run into the problem I will give you an example of
the problem. I know one way to get around some problems was to use
machine_func() calls which everyone was using to get around some problems.
I noticed on the list I was among the majority of users NOT using
namespaces why don't you ask the other users maybe that would help you.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
28. Re: Do you currently use namespaces?
Yes, all the time.
But that's because I use a language where namespaces are implemented correctly,
I think. Sorry if this is a bit long, but I don't know any way to show what I
mean without examples.
Examples:
...File foo...
sub one
return "foo one"
;;
sub two
return "foo two"
;;
var three = 3.1
var four = [4,"foo Four"]
...File bar...
sub one
return "bar one"
;;
sub two
return "bar two"
;;
var three = 3.2
var four = [4,"bar Four"]
Using the included files:
...Main file (first method)...
use foo
use bar
println(foo.one) # must use prefix, otherwise 'undeclared symbol' err
println(foo.two)
println(bar.three)
println(bar.four)
...Results...
foo one
foo two
3.2
[4, 'bar Four']
...(second method)...
use foo (*) # import all as default
use bar
println(one) # no namespace needed, uses foo
println(foo.two) # uses foo
println(bar.three) # overrides default, uses bar
println(four)
...(third method)...
use foo (one) # only import function 'one' from foo
use bar (two,three,four) # import these funks & vars from bar
println(one)
println(two)
println(foo.two)
println(bar.three)
println(four)
...results...
foo one
bar two
foo two
3.2
[4, 'bar Four']
...(fourth method)...
use foo as a
use bar as b
println(a.one) # must use correct prefix for all
println(b.one)
println(a.two)
println(b.three)
println(b.four)
# println(two) # undeclared symbol err - can't accidentally get access
...(final example)...
use foo as a
use irv.testing.bar as b
# includes the file bar which is located in
# my testing directory, ignoring the local bar file.
29. Re: Do you currently use namespaces?
Bernie:
The question as posed is similar to "Have you stopped beating your wife?"
Perhaps what should have been asked is: "If namespaces worked properly, would
you be using them?" But that is still not 100%.
Some people would say no, because the type of programs they write can be written
without resorting to namespaces, for whatever reason. Perhaps they write short
utility programs where everything can easily be put in one file. Perhaps they
are
incredibly organized and can manage huge monolithic files without a problem.
Some people would say no because they don't realize how useful namespaces can
be, they're used to muddling along with euphoria as it is.
Neither of those "noes" should be taken as a rational reason to avoid
implementing
real namespacing. That would only hurt those of us who do not fall into one
of the above categories.
So, perhaps if it were asked again, the answers should be less terse.
1. No, I don't see the need, and I don't think anyone else should either.
2. No, I don't see the need, wouldn't use 'em, but it's OK if others do.
3. Yes, I would use them if they worked.
4. Yes, I use them even though they are incomplete and awkward sometimes.
5. Yes, they work exactly the way I like them to work.Don't change a thing.
Maybe a couple more?
30. Re: Do you currently use namespaces?
>
> The question as posed is similar to "Have you stopped beating your wife?"
>
The intent of the question was not to determine it's usefulness, correctness, or
people's opinion of it. It was to determine if we change the way namespaces work
how many people would it affect?
So, the original question was stated correctly for it's purpose.
Irv, I enjoyed your post on namespaces. It is helpful. On the dev list we have
exchanged over 200 messages within a very short time frame (3 days?). Discussions
were just the same thing we discussed here on EUforum a few weeks ago, however,
it went more into what would break, what would not break, how to implement,
etc...
--
Jeremy Cowgar
http://jeremy.cowgar.com
31. Re: Do you currently use namespaces?
Never.
Matt Lewis wrote:
>How else would you have solved the problem?
1) An instance of a class does not have this problem.
2) DLL's may have functions with the same name which is resolved in
the function call declaration by assigning an alias.
Euphoria is not inherently modular because it uses the INCLUDE paradigm.
Other languages use a project file paradigm.
Most functions and variables should not be public and their scope should
be limited to the file they are declared in.
Explicitly public functions and variables should have descriptive names
which are less likely to conflict (but since even then they could, using
classes would still be the solution.)
32. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Never.
>
> Matt Lewis wrote:
> >How else would you have solved the problem?
>
> 1) An instance of a class does not have this problem.
>
> 2) DLL's may have functions with the same name which is resolved in
> the function call declaration by assigning an alias.
>
> Euphoria is not inherently modular because it uses the INCLUDE paradigm.
> Other languages use a project file paradigm.
I'm coming in late on this discussion, but how does include make it not modular?
For instance here is some of my code:
include user.e as user
include note.e as note
sequence notes
user:user current
current = user:get(1)
notes = note:get_all_for(current)
user.e is included in many different command line utilities/gui apps. It can be
used independent of any other. That's modular and using include?
>
> Most functions and variables should not be public and their scope should
> be limited to the file they are declared in.
>
Yes, that's just good practice and that's what I do above.
> Explicitly public functions and variables should have descriptive names
> which are less likely to conflict (but since even then they could, using
> classes would still be the solution.)
Yes, again, that's just good practice. I do not see how what you said is making
Euphoria not modular? Can you expand a bit?
--
Jeremy Cowgar
http://jeremy.cowgar.com
33. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>how does include make it not modular?
>I do not see how what you said is making Euphoria not modular?
>Can you expand a bit?
Absolutely,
Keep in mind that a programmer can write code in a modular language that
isn't modular and another could write good modules in a language that isn't
supportive of that.
Good modules should have certain features.
Decoupling is an important principle as well as the principle of
information hiding. They don't expose their internal structure but
do expose an interface.
What happens when you include a file? Everything becomes exposed!
This, needless to say, does not promote information hiding!
Let me give you a real example. I make it a matter of pride that if you
get a function from me it is complete, works and you will have no problem
adding it to your code. I was writing a utility and needed a function
that a guy I worked with had written. He insisted I use his function.
Being my nominal boss at the time it was difficult to refuse. Anyway, I
added his code to my tiny little utility and there was a problem. It had
ties that were dependant on other parts of his project. So I had to include
those (couldn't amputate because that was the nature of his code.) This
continued until finally my tiny little utility was the size of his major
project. At that point I got my boss involved and let him share some of
my frustration (I'm generous that way.) In the end, I wrote what I needed
without the help of his function. The guy was a really smart guy, but didn't
really understand the concept or why it was important. I find that very
few programmers I've worked with really do. This was not an isolated
incident.
34. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Jeremy Cowgar wrote:
> >how does include make it not modular?
> >I do not see how what you said is making Euphoria not modular?
> >Can you expand a bit?
>
> Absolutely,
>
> Keep in mind that a programmer can write code in a modular language that
> isn't modular and another could write good modules in a language that isn't
> supportive of that.
>
> Good modules should have certain features.
>
> Decoupling is an important principle as well as the principle of
> information hiding. They don't expose their internal structure but
> do expose an interface.
>
> What happens when you include a file? Everything becomes exposed!
> This, needless to say, does not promote information hiding!
>
That's not true at all.
-- greeter.e
constant greeting = "Hello"
procedure say_greeting()
puts(1, greeting)
end procedure
procedure say_who(sequence who)
puts(1, who)
end procedure
global procedure greet(sequence who)
say_greeting()
puts(1, ", ")
say_who(who)
puts(1, "!\n")
end procedure
-- myprog.ex
include greeter.e
greet("John Doe")
puts(greeting)
say_who("Jim")
say_greeting()
The above code is just an example showing
hello.e:4
greeting has not been declared
puts(greeting) -- parse error, greeting is undefined.
say_who and say_greeting are also invalid. The are not global.
> Let me give you a real example. I make it a matter of pride that if you
> get a function from me it is complete, works and you will have no problem
> adding it to your code. I was writing a utility and needed a function
> that a guy I worked with had written. He insisted I use his function.
> Being my nominal boss at the time it was difficult to refuse. Anyway, I
> added his code to my tiny little utility and there was a problem. It had
> ties that were dependant on other parts of his project. So I had to include
> those (couldn't amputate because that was the nature of his code.) This
> continued until finally my tiny little utility was the size of his major
> project. At that point I got my boss involved and let him share some of
> my frustration (I'm generous that way.) In the end, I wrote what I needed
> without the help of his function. The guy was a really smart guy, but didn't
> really understand the concept or why it was important. I find that very
> few programmers I've worked with really do. This was not an isolated
> incident.
Hm, that happens anywhere, even in languages that you would consider modular.
That has nothing to do with include or with Euphoria.
--
Jeremy Cowgar
http://jeremy.cowgar.com
35. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Jeremy Cowgar wrote:
> >how does include make it not modular?
> >I do not see how what you said is making Euphoria not modular?
> >Can you expand a bit?
> ... Good modules should have certain features.
>
> Decoupling is an important principle as well as the principle of
> information hiding. They don't expose their internal structure but
> do expose an interface.
>
> What happens when you include a file? Everything becomes exposed!
> This, needless to say, does not promote information hiding!
Ummm ... actually this happens *not* to be the case... The ONLY things that are
exposed are the symbols explicitly marked as 'global' within the file being
included. For example ...
If I have a file, exam.e, that contains the following lines ...
procedure foo()
end procedure
global procedure bar()
end procedure
And another file that includes this ...
include exem.e
foo() -- Fails because it can't be seen
bar() -- Succeeds because 'exam.e' declared it global.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
36. Re: Do you currently use namespaces?
Derek Parnell wrote:
>
> ken mortenson wrote:
> > What happens when you include a file? Everything becomes exposed!
> > This, needless to say, does not promote information hiding!
>
> Ummm ... actually this happens *not* to be the case... The ONLY things that
> are exposed are the symbols explicitly marked as 'global' within the file
> being
> included. For example ...
I'm sorry guys. I wasn't being clear.
fileA.e includes fileB.e; fileB.e includes fileC.e
Everything global in fileC is now exposed to fileA.
This continues for every include. The end result is one big file, not a
group of modules.
This may be a problem. It is a problem when names collide.
37. Re: Do you currently use namespaces?
ken mortenson wrote:
>
>
> I'm sorry guys. I wasn't being clear.
>
> fileA.e includes fileB.e; fileB.e includes fileC.e
>
> Everything global in fileC is now exposed to fileA.
>
> This continues for every include. The end result is one big file, not a
> group of modules.
>
> This may be a problem. It is a problem when names collide.
>
Ok. That is not a problem anymore when you use namespaces. In addition, we may
have other changes in 4.0 that solve your issue totally, even w/o namespaces.
i.e. global propagation of globals not being the case. But the later is just
under very, very, very initial discussion. Once we have an idea of the impact,
some possible solutions, we will undoubtedly bring it up on EUforum for
discussion.
However, your given example above is still invalid if you use namespaces as
currently defined in 4.0, and for the most part 3.1 as well.
--
Jeremy Cowgar
http://jeremy.cowgar.com
38. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> ken mortenson wrote:
> > I'm sorry guys. I wasn't being clear.
> > fileA.e includes fileB.e; fileB.e includes fileC.e
> > Everything global in fileC is now exposed to fileA.
>
> Ok. That is not a problem anymore when you use namespaces.
> However, your given example above is still invalid if you use namespaces as
> currently defined in 4.0, and for the most part 3.1 as well.
How do you avoid fileC.e's globals not being exposed to fileA.e? Is it
automatic? Just curious...
39. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> ken mortenson wrote:
> > Keep in mind that a programmer can write code in a modular language that
> > isn't modular and another could write good modules in a language that isn't
> > supportive of that.
> >
> > Good modules should have certain features.
> >
> > Decoupling is an important principle as well as the principle of
> > information hiding. They don't expose their internal structure but
> > do expose an interface.
> > [SNIP... story about decoupling]
> Hm, that happens anywhere, even in languages that you would consider modular.
You are right. However, some features encourage modular programming and
some feature work against it.
> That has nothing to do with include or with Euphoria.
Well, it does. What is a module? It's a black box that does something.
Include is a back door to that black box. Can you write modular programs
using include? Of course you can. Does include encourage you to think
in a modular way? No, I'll give you another example.
Sequence is one type of coupling. Remember that a module should be
decoupled. Each module is separate and distinct and has it's own
(chiselled in stone) interface. Order doesn't matter in calling modules.
Order does matter using include.
40. Re: Do you currently use namespaces?
ken mortenson wrote:
<snip>
> Remember that a module should be
> decoupled. Each module is separate and distinct and has it's own
> (chiselled in stone) interface. Order doesn't matter in calling modules.
>
> Order does matter using include.
Order is everything in Eu, even calling it a bug that routine_id() once worked
out of order. I asked for an export keyword to make an interface in namespace,
and i asked for restricting "global" to at least files it included (which
wouldn't have solved your example, but gotta start somewhere). My suggestions
were shot down right away, and haven't been discussed. Some of this stuff was
asked for 5 to 8 years ago, Ken, and it isn't here yet.
Kat
41. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Sequence is one type of coupling. Remember that a module should be
> decoupled. Each module is separate and distinct and has it's own
> (chiselled in stone) interface. Order doesn't matter in calling modules.
>
> Order does matter using include.
In what way? Given my example of the user and note module. One is not depending
on another, order could care less. I've never had to order any of my includes. I
am unsure of any situation you would have to, can you give me an example?
--
Jeremy Cowgar
http://jeremy.cowgar.com
42. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> ken mortenson wrote:
> >
> > Sequence is one type of coupling. Remember that a module should be
> > decoupled. Each module is separate and distinct and has it's own
> > (chiselled in stone) interface. Order doesn't matter in calling modules.
> >
> > Order does matter using include.
>
> In what way? Given my example of the user and note module. One is not
> depending
> on another, order could care less. I've never had to order any of my includes.
> I am unsure of any situation you would have to, can you give me an example?
CK gave an example a few days ago in which he could solve the include order only
thru massive use of routine_id().
Kat
43. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Jeremy Cowgar wrote:
> >how does include make it not modular?
> >I do not see how what you said is making Euphoria not modular?
> >Can you expand a bit?
>
> Absolutely,
>
> Keep in mind that a programmer can write code in a modular language that
> isn't modular and another could write good modules in a language that isn't
> supportive of that.
>
> Good modules should have certain features.
>
> Decoupling is an important principle as well as the principle of
> information hiding. They don't expose their internal structure but
> do expose an interface.
>
> What happens when you include a file? Everything becomes exposed!
> This, needless to say, does not promote information hiding!
>
> Let me give you a real example. I make it a matter of pride that if you
> get a function from me it is complete, works and you will have no problem
> adding it to your code. I was writing a utility and needed a function
> that a guy I worked with had written. He insisted I use his function.
> Being my nominal boss at the time it was difficult to refuse. Anyway, I
> added his code to my tiny little utility and there was a problem. It had
> ties that were dependant on other parts of his project. So I had to include
> those (couldn't amputate because that was the nature of his code.) This
> continued until finally my tiny little utility was the size of his major
> project. At that point I got my boss involved and let him share some of
> my frustration (I'm generous that way.) In the end, I wrote what I needed
> without the help of his function. The guy was a really smart guy, but didn't
> really understand the concept or why it was important. I find that very
> few programmers I've worked with really do. This was not an isolated
> incident.
From my admittedly inexperienced vantage point, you are describing something
which would be expected to reside in a dll, as self contained and fully
functional to the extent ever intended.
Includes, on the other hand, are intended to be not only included, but extended,
if need be.
In my view, there is a world of difference and, yes, I understand that things
which might be better placed within dlls are instead left within includes for no
good reason other than it is easier to do so. Much easier because it allows that
completeness you champion to be given short shrift. I mean, why worry about
completeness if the code is exposed for anybody to improve as they see fit?
But people rarely can predict what portions of their workproduct requires
extending. So to put virtually anything into a dll loses flexibility.
I'm not sure what this means other than to say that I'm not sure I agree with
your definition of complete.
Mike
44. Re: Do you currently use namespaces?
Kat,
These topics have been written about for 30 years. It surprizes me that
we are always reinventing the wheel. What surprises me more is how
resistant people are to understanding decoupling, information hiding,
and true modules. Supermen make bad programmers.
I'll keep pounding my head against the wall. Eventually I'll make a dent.
ken.
45. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> ken mortenson wrote:
> > Order does matter using include.
>
> In what way? Given my example of the user and note module. One is not
> depending
> on another, order could care less. I've never had to order any of my includes.
> I am unsure of any situation you would have to, can you give me an example?
Am I up to the challenge? It seems strange to me that you've never had
issues with ordering when that's the first thing that became a difficulty
for me when learning Euphoria. I was constantly having to move functions
and includes to earlier places in my code because of dependancies. The
fact that routine ID's are employed is another example.
If you accept that, can you accept that ordering is a kind of coupling
that means it is less than modular? Smarter people than me have written
books on the subject.
The fact that you write good modules does not make Euphoria a modular
language. Euphoria is more modular than some languages, but it is not
naturally modular or make modular code the norm.
I'm not quite sure how to explain that purple is purple? I've tried to
explain this to really smart guys before and they didn't seem to get it
either. Someone better than I will have to do it, probably.
BTW, even Delphi has this problem so you are not the only one to be
confused by the concept.
46. Re: Do you currently use namespaces?
Mike777 wrote:
> From my admittedly inexperienced vantage point, you are describing something
> which would be expected to reside in a dll, as self contained and fully
> functional
> to the extent ever intended.
>
> Includes, on the other hand, are intended to be not only included, but
> extended,
> if need be.
Good comments Mike, well deserving of a reply.
Modular programming really has nothing to do with DLL's per se. The concept
applies whether it's your code or someone elses, whether you are calling
into a DLL or a module you wrote. Modules can be loose or tight. You may
have a bunch of loosely related functions you wrote on a day and made a
module out of them, or you could be defining a very precise API to solve
a very specific problem. Someone should probably post a good reading list
on the subject. My library, isn't what it was or I'd do it.
47. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Am I up to the challenge?
If you write code like this you have problems:
FileA.e
global function do_a() ....
global function hello_a() ...
FileB.e
global function do_b() ...
global function hello_b() ...
FileC.e
do_a()
hello_b()
MyProg.ex
include FileA.e
include FileB.e
include FileC.e --- this has to be included last because it
------------------- it depends on FileA and FileB
-------------------
------------------- This is *horrible* coding.
In the above program, FileC.e should be rewritten as:
FileC.e
include FileA.e
include FileB.e
do_a()
hello_b()
MyProg.ex
include FileC.e
include FileA.e
include FileB.e
---- Notice... Order has zero affect on anything.
----
---- This is proper coding.
--
Jeremy Cowgar
http://jeremy.cowgar.com
48. Re: Do you currently use namespaces?
I hope everyone realizes that I'm not bashing Euphoria when I say
it has features that make it less than ideal for modular programming.
I love what Euphoria is and have a vision of what it could become.
I've been looking for a language that gives me the pure joy I sometimes
experience when coding and Euphoria is one of the few that has such
potential.
Sadly, I've seen potential fail too often in my half century.
49. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> I hope everyone realizes that I'm not bashing Euphoria when I say
> it has features that make it less than ideal for modular programming.
>
No way. In order to make a programming language more useful you have to point
out it's weak spots. If you fail to find, talk about or suggest different methods
on it's weak spots, you might as well give up and trash what ever you are working
on.
> I love what Euphoria is and have a vision of what it could become.
Me too! You may be very interested in some of the discussion that will be coming
up on the exact topic you are addressing on the dev list. On the dev list we are
going to try to define the problem and come up with a few solutions, then present
the information we have found to EUforum.
From your work here on EUforum already, I think you would be a great help there
in the initial stages... Again, to everyone, the dev list is not for the elite,
it's for anyone to join... we are driven by the community but sometimes, in cases
like this, we don't even understand the problem fully so we try to talk about it
and figure out the problem before trying to post a message here solving a problem
we do not know about
>
> I've been looking for a language that gives me the pure joy I sometimes
> experience when coding and Euphoria is one of the few that has such
> potential.
>
> Sadly, I've seen potential fail too often in my half century.
>
Good times are ahead for Euphoria. We are nearing completion on many fronts and
an alpha is not far away. After that, beta's and final 4.0 release.
--
Jeremy Cowgar
http://jeremy.cowgar.com
50. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> [SNIP include example]
> ---- This is proper coding.
Ah, Jeremy, this is a grand statement. Especially when demonstrating the
'include everything' school of programming. I see this same problem in
Microsoft programmers which is why they have a zillion constants for the
definition of true and false (all with very precise names) in their code.
Including fileA and fileB twice is only a little bit of nails on the
chalkboard for me, but I can get past that because the language allows it.
Ordering is just one aspect regarding the issue of modularity. Programmers
are very good puzzle solvers. I'm sure that no matter what issue I bring
up you'd be able to come up with an example of a solution. I respect you
for that.
None of that makes Euphoria a modular language.
51. Re: Do you currently use namespaces?
ken mortenson wrote:
By the way, ken, and please don't take this the wrong way because I'm guilty of
this, but your posts are starting to look a little condescending. I'm putting
this effect down to the limitations of this particular communication medium,
however it might be an idea to de-emphasize the language that seems to suggest
that you know the "right thing" and no one else gets it.
> Jeremy Cowgar wrote:
> > ken mortenson wrote:
> > > Order does matter using include.
> >
> > In what way?
With Euphoria, order does matter. This has nothing intrinsicly to do with
include files though. For better or worse, Euphoria has the deliberate
restriction that one can only directly refer to symbols that are lexically
declared (and exposed) earlier than their reference. So yes, order does matter.
> Given my example of the user and note module. One is not depending
> > on another, order could care less. I've never had to order any of my
> > includes.
> > I am unsure of any situation you would have to, can you give me an example?
I can Jeremy. When writing the win32lib, I often had to reorder symbol
declarations when a new bit of code needed to refer to something further on down
(either in an included file or in the same file). This became so frustrating that
I started (ab)using the routine_id() method just so I didn't have to reorganize
the source code yet again.
This has nothing to do with modular programming though. It is just a feature of
Euphoria's design philosophy.
> If you accept that, can you accept that ordering is a kind of coupling
> that means it is less than modular? Smarter people than me have written
> books on the subject.
Yes, dependancies on the physical layout of code is a sort of coupling. However
Euphoria, being a procedural language rather than a functional language, we will
always be beholden to some aspects of the way code is organised. For example, we
expect that the next statment to be executed will be the one after the current
one (in most cases).
> BTW, even Delphi has this problem so you are not the only one to be
> confused by the concept.
I am not confused by the concept of modules or modularity. There are many types
of module systems, each with strengthes and weaknesses. Euphoria has a system of
modules. The module is embodied in a single file. The module exposes its API via
the 'global' keyword. It exposes this API to every line of code that follows the
'include' directive for the file, and conversely hides its API to code preceding
the 'include' directive. That's about it for Euphoria.
Can it be better? Sure it can! But define "better" first.
You seem to be saying at least two things can be improved. Firstly that the
forward referencing restriction be removed or amended. Secondly, that a module's
API can have a mechanism that only exposes it (or selected parts of it) to the
file that directly includes the module. Have I got that right?
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
52. Re: Do you currently use namespaces?
Derek Parnell wrote:
> ken mortenson wrote:
>
> By the way, ken, and please don't take this the wrong way because I'm guilty
> of this, but your posts are starting to look a little condescending. I'm
> putting
> this effect down to the limitations of this particular communication medium,
> however it might be an idea to de-emphasize the language that seems to suggest
> that you know the "right thing" and no one else gets it.
Thank you Derek, I do appreciate it. But no it's me, I have no social grace.
I'm an INTJ (google it) and many things that are self evident to me are not
to others. The truth is I in no way look down on people (except for real
evil bastidges!) and actually have a high regard and warm feeling toward
almost everybody I communicate with (or I don't bother to) but it always
seems to come across that way. It's an old problem for me and I don't
really know what to do about it. An INTJ knows what they know, but are
quick to acknowledge when shown to be wrong. Sometimes when I'm trying
to be funny it comes across as condescencian(sp?).
Being a 50 year old unemployed programming bum that just finalized his
divorce this April... I could really use being part of a community of
people that share my interests. I may have no social grace, but being
human (contrary to that nasty rumor that's been going around) I do
enjoy social contact with people.
> I often had to reorder...
> This has nothing to do with modular programming though.
Respectfully, I wish I could provide you with a citation because this
is a classic issue regarding modularity.
> Euphoria, being a procedural language rather than a functional language
Give me procedural or give me death! Don't even go to functional languages.
That was funny, right? ;)
> we will always be beholden to some aspects of the way code is organised.
A truth, self evident.
> I am not confused by the concept of modules or modularity.
Please forgive me if I implied that. I'll take twelve lashes with a wet noodle.
> There are many types
> of module systems, each with strengthes and weaknesses. Euphoria has a system
> of modules. The module is embodied in a single file. The module exposes its
> API via the 'global' keyword. It exposes this API to every line of code that
> follows the 'include' directive for the file, and conversely hides its API to
> code preceding the 'include' directive. That's about it for Euphoria.
One thing about experiencing different languages, especially if in a working
environment, is that you start to get a feel for best and better. At least
I see it that way. What makes me productive? What can I trust?
...about myself? ...my tools?
If I got a contract today to produce a product, what language would I choose?
I wish I could say Euphoria, but I can't. I can very clearly see what
would have to change for me to say yes. I can also cleary see why I want
to be able to say yes. Euphoria is the most expressive language I've
ever seen (Rebol might complain, but this is my opinion.) You could argue
the extent of how modular Euphoria is, but I don't see how a productive
working programmer could not understand (and I do beg forgiveness if this
sounds condesending) that it lags behind others in producing modular code.
Probably will not change. My vision will probably require a clean sheet.
I will say this. My vision would top the charts in no time at all because
I see it filling a need that no other language is addressing. I'd pay a
couple hundred dollars for such a tool and I wouldn't be alone.
> Can it be better? Sure it can! But define "better" first.
Actually, I've been working more intensely on that since discovering Euphoria
a few years ago, but this has been a goal of mine since the mid 70's.
I'm always out of sync with time. I was talking about massive online
communities when the internet was just a gleam (in ALGORE'S EYE, right?)
> You seem to be saying at least two things can be improved. Firstly that the
> forward referencing restriction be removed or amended.
I do think that routine ID's have better uses than forward refs. Not having
to worry about which function comes first physically in the code encourages
productivity as well as making modular code easier to implement. I don't
believe I can be argued out of this position (but I will always accept the
possibility. Part of the INTJ nature.)
Optimizing for compiler speed at the expense of programmer productivity is
a huge mistake in my, oh so humble but unable to convey my humility, opinion.
Hey, that really was funny. Admit it. Now. Or be destroy by my invasion
fleet!
> Secondly, that a module's
> API can have a mechanism that only exposes it (or selected parts of it) to the
> file that directly includes the module. Have I got that right?
Yes, and maybe no. I can't emphasize enough how overhyped OOP is. But one
thing they have right is instances of classes. I've programmed C years ago,
and the language has some features I really like, but I can't stand C++,
or it's evil stepchild C#, My experience is with VB classes. While VB is
certainly not fully OOP (I see this as a good thing!) it does have a few
best in class features (the basic language is not one of them.)
Absolutely, Best. In. Class.
Even though the debugger could be improved, it is B.I.C. because it never
gets in the way of coding and provides what I need. Intellisense (B.I.C.)
even M$ couldn't get that right outside of VB. Drill down (B.I.C.) Two
clicks and I've found the declaration, no search required.
One file per class allows me to organize my code well.
There is much more, but the last thing I should mention is direct compile.
Yes, VB has a runtime that I rather it didn't. My ideal language would
create a static compile that I could just hand to the user.
That's enough for now. I got wackier ideas, but I think I need to be
a bit reserved. Plus me fingers is gett'n tired. I think I'll just post
then proofread. Good idea, right?
53. Re: Do you currently use namespaces?
Derek Parnell wrote:
>
> ken mortenson wrote:
> >
> > Jeremy Cowgar wrote:
> > >how does include make it not modular?
> > >I do not see how what you said is making Euphoria not modular?
> > >Can you expand a bit?
>
>
> > ... Good modules should have certain features.
> >
> > Decoupling is an important principle as well as the principle of
> > information hiding. They don't expose their internal structure but
> > do expose an interface.
> >
> > What happens when you include a file? Everything becomes exposed!
> > This, needless to say, does not promote information hiding!
>
> Ummm ... actually this happens *not* to be the case... The ONLY things that
> are exposed are the symbols explicitly marked as 'global' within the file
> being
> included. For example ...
>
> If I have a file, exam.e, that contains the following lines ...
> }}}
<eucode>
> procedure foo()
> end procedure
>
> global procedure bar()
> end procedure
> </eucode>
{{{
>
> And another file that includes this ...
>
> }}}
<eucode>
> include exem.e
> foo() -- Fails because it can't be seen
> bar() -- Succeeds because 'exam.e' declared it global.
> </eucode>
{{{
>
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
This means that multiple files have to exchange information through interface
identifiers, since an identifier that is visible in several files is promoted to
interface symbol. This makes it unsafe to break a large body of code into
smaller, more maintainable files, because all exchanges are not supposed to
involve "public" data or routines. And because making public these symbols may
interfere with any application that uses the library.
There ae workarounds as always, but they are neither practical nor 100% safe.
CChris
54. Re: Do you currently use namespaces?
Kat wrote:
>
> Jeremy Cowgar wrote:
> >
> > ken mortenson wrote:
> > >
> > > Sequence is one type of coupling. Remember that a module should be
> > > decoupled. Each module is separate and distinct and has it's own
> > > (chiselled in stone) interface. Order doesn't matter in calling modules.
> > >
> > > Order does matter using include.
> >
> > In what way? Given my example of the user and note module. One is not
> > depending
> > on another, order could care less. I've never had to order any of my
> > includes.
> > I am unsure of any situation you would have to, can you give me an example?
>
> CK gave an example a few days ago in which he could solve the include order
> only thru massive use of routine_id().
>
> Kat
Open win32lib.ew and go through the code. Inclusion ordeer and placement in the
file are crucial, and sometimes a headache to figure out.
CChris
55. Re: Do you currently use namespaces?
CChris wrote:
> This means that multiple files have to exchange
> information through interface identifiers, since
> an identifier that is visible in several files
> is promoted to interface symbol. This makes it
> unsafe to break a large body of code into
> smaller, more maintainable files, because all
> exchanges are not supposed to involve "public"
> data or routines. And because making public these
> symbols may interfere with any application that
> uses the library.
By "public" I assume you mean "able to be directly referred to by code that is
outside the declaring file". However, it has to be done that way if you want to
directly refer to an entity by name - the name must be visible for your code to
'see' it. If you prefer indirect references, you can get away with not knowing
the entity's real name but at a performance overhead or via an alias symbol. An
alias is not a solution because its still a visible name.
Also, the "public" access to data and not routines is the major problem with
module coupling. With routines, one publishes the API and (try to) keep the API
unchanged. Meaning you should be able to move the routine to a new module and not
break the code using it.
I assume that when you say "interfere with any application" you are referring to
naming conflicts. This, as you well know, is what is being addressed in v4.0.
Of course, one further way to restrict naming conflicts is to reduce the
visibility of symbols. 'global' makes it seen by all including levels, even if
they don't need to see it. One suggestion being kicked around is to allow
'global' items to only be seen by the file directly including it. Discussion
continues on this front.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
56. Re: Do you currently use namespaces?
CChris wrote:
> This means that multiple files have to exchange information through interface
> identifiers, since an identifier that is visible in several files is promoted
> to interface symbol. This makes it unsafe to break a large body of code into
> smaller, more maintainable files, because all exchanges are not supposed to
> involve "public" data or routines. And because making public these symbols may
> interfere with any application that uses the library.
>
> There ae workarounds as always, but they are neither practical nor 100% safe.
>
> CChris
When I see a VB programmer using lots of globals it's a sign of their
inexperience to me. Inexperience can also mean someone who goes from
job to job for years and is never actually around to maintain any of
the code they wrote.
The fact that Euphoria depends so heavily on globals is just another
indicator to me that it is not inherently modular.
I believe you are exactly right here Chris.
Again, I must emphasize that modularity is something the programmer
does, not the language.
57. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Jeremy Cowgar wrote:
> > [SNIP include example]
> > ---- This is proper coding.
>
> Ah, Jeremy, this is a grand statement. Especially when demonstrating the
> 'include everything' school of programming. I see this same problem in
> Microsoft programmers which is why they have a zillion constants for the
> definition of true and false (all with very precise names) in their code.
>
> Including fileA and fileB twice is only a little bit of nails on the
> chalkboard for me, but I can get past that because the language allows it.
It's not a matter of including it twice. His point was that your code should
include what it needs. Your statement is actually the antithesis of modular
programming, IMHO. Each module should explicitly declare its dependencies.
Euphoria has never required this, though it will at least generate a
warning in 4.0.
Matt
58. Re: Do you currently use namespaces?
CChris wrote:
>
>
> Open win32lib.ew and go through the code. Inclusion ordeer and placement in
> the file are crucial, and sometimes a headache to figure out.
>
I thought the reference was in regards to include statements about order. It
certainly does matter in source and I don't really think that's a bad thing.
Sometimes it would be nice to have forward references as well as backwards
with-in a file, but for the most part, I think most issues are easily resolved.
Quite a few languages have this "limitation". Modular and non-modular languages
alike, that's why I thought the reference was in regards to include statements.
--
Jeremy Cowgar
http://jeremy.cowgar.com
59. Re: Do you currently use namespaces?
Matt Lewis wrote:
>
> ken mortenson wrote:
> >
> > Jeremy Cowgar wrote:
> > > [SNIP include example]
> > > ---- This is proper coding.
> >
> > Ah, Jeremy, this is a grand statement. Especially when demonstrating the
> > 'include everything' school of programming. I see this same problem in
> > Microsoft programmers which is why they have a zillion constants for the
> > definition of true and false (all with very precise names) in their code.
> >
> > Including fileA and fileB twice is only a little bit of nails on the
> > chalkboard for me, but I can get past that because the language allows it.
>
> It's not a matter of including it twice. His point was that your code should
> include what it needs. Your statement is actually the antithesis of modular
> programming, IMHO. Each module should explicitly declare its dependencies.
> Euphoria has never required this, though it will at least generate a
> warning in 4.0.
>
In addition, if you use namespaces, you can forget the fact 100% that anything
is global throughout the entire program. For instance:
FileA.e. FileB.e, FileC.e, FileD.e, ...., FileAA.e, ...., FileZZZZZZZ.e
global function hello()
MyProg.ex
include FileA.e as a
include FileB.e as b
...
include FileZZZZZZZ.e as zzzzzzz
a:hello()
b:hello()
aaa:hello()
zzzzzzzzzz:hello()
In side of the namespace, the *only* functions/procedures/variables are those
within the file defining the namespace. It does not matter if there are 1,000
hello() functions. In side your declared namespace there is only 1. That's the
same as a module:
-- Fake Language FileA.fake
module FileA
export sub hello() { ... }
sub goodbye() { ... }
-- Fake Language FileB.fake
module FileB
export sub hello() { ... }
sub goodbye() { ... }
-- Fake Language MyProg.fake
use FileA
use FileB
FileA.hello()
FileB.hello()
--
Jeremy Cowgar
http://jeremy.cowgar.com
60. Re: Do you currently use namespaces?
Matt Lewis wrote:
> ken mortenson wrote:
> > Including fileA and fileB twice is only a little bit of nails on the
> > chalkboard for me, but I can get past that because the language allows it.
>
> It's not a matter of including it twice. His point was that your code should
> include what it needs. Your statement is actually the antithesis of modular
> programming, IMHO. Each module should explicitly declare its dependencies.
> Euphoria has never required this, though it will at least generate a
> warning in 4.0.
I was being a bit too flip here. I think I was getting a bit punchy from
responding to everybody. I really didn't expect it to be so controversial
when I say that includes don't encourage modular programming.
To me this is self evident. Apparently not to others. I did see his point.
61. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> In addition, if you use namespaces, you can forget the fact 100% that anything
> is global throughout the entire program. For instance:
> include FileA.e as a
> include FileB.e as b
> a:hello()
> b:hello()
I see the point you make regarding the similarity in the following. However,
what happens if FileA.e above includes FileC.e and FileB.e includes FileD.e
which both have hello(). Does your main file have to know to declare a
namespace for the includes withing files A & B? This violates the
principle of information hiding.
> In side of the namespace, the *only* functions/procedures/variables are those
> within the file defining the namespace. It does not matter if there are 1,000
> hello() functions. In side your declared namespace there is only 1. That's the
> same as a module:
> -- Fake Language MyProg.fake
> use FileA
> use FileB
>
> FileA.hello()
> FileB.hello()
62. Re: Do you currently use namespaces?
-- filea.e
global procedure hello()
puts(1, "filea: hello\n")
end procedure
-- fileb.e
include filea.e as a
global procedure hello()
puts(1, "fileb: hello\n")
end procedure
-- myprog.ex
include fileb.e as b
b:hello() -- prints "fileb: hello"
myprog.ex cannot access a:hello() in any way. It would have to directly include
filea.e to access filea.e's hello()
--
Jeremy Cowgar
http://jeremy.cowgar.com
63. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> I was being a bit too flip here. I think I was getting a bit punchy from
> responding to everybody. I really didn't expect it to be so controversial
> when I say that includes don't encourage modular programming.
>
> To me this is self evident. Apparently not to others. I did see his point.
>
We are adding new features to Euphoria and I am just trying to understand where
you think it is lacking so that it can be improved. I have been doing that
through examples relying on your feedback. I am unsure of how else to figure this
out.
--
Jeremy Cowgar
http://jeremy.cowgar.com
64. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Jeremy Cowgar wrote:
> > In addition, if you use namespaces, you can forget the fact 100% that
> > anything
> > is global throughout the entire program. For instance:
>
> > include FileA.e as a
> > include FileB.e as b
> > a:hello()
> > b:hello()
>
> I see the point you make regarding the similarity in the following. However,
>
> what happens if FileA.e above includes FileC.e and FileB.e includes FileD.e
> which both have hello(). Does your main file have to know to declare a
> namespace for the includes withing files A & B? This violates the
> principle of information hiding.
I am getting punchy. See if you can figure out what I actually meant to
say, because what I said makes no sense. Or does it? I need sleep.
65. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> -- filea.e
> global procedure hello()
> -- fileb.e
> include filea.e as a
> global procedure hello()
> -- myprog.ex
> include fileb.e as b
> b:hello() -- prints "fileb: hello"
>
> myprog.ex cannot access a:hello() in any way. It would have to directly
> include
> filea.e to access filea.e's hello()
Amazing, you figured out what I was trying to say even when I couldn't!!!
Let me look at this...
You say myprog.ex can't access a:hello() in any way. Got that. But again,
a include c, b include d. If I understand correctly, then myprog.ex could
call c:hello() or d:hello() even though they are not declared in myprog?
If so, this is not a good module. However, I get the impression this is
still an issue under discussion. I'd like to see how the result encourages
modular thinking.
66. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Jeremy Cowgar wrote:
>
> > -- filea.e
> > global procedure hello()
>
> > -- fileb.e
> > include filea.e as a
> > global procedure hello()
>
> > -- myprog.ex
> > include fileb.e as b
> > b:hello() -- prints "fileb: hello"
> >
> > myprog.ex cannot access a:hello() in any way. It would have to directly
> > include
> > filea.e to access filea.e's hello()
>
> Amazing, you figured out what I was trying to say even when I couldn't!!!
>
> Let me look at this...
>
> You say myprog.ex can't access a:hello() in any way. Got that. But again,
> a include c, b include d. If I understand correctly, then myprog.ex could
> call c:hello() or d:hello() even though they are not declared in myprog?
>
No, that's incorrect. if myprog.ex never includes directly c, or d then myprog
could not call c:hello() nor d:hello().
> If so, this is not a good module. However, I get the impression this is
> still an issue under discussion. I'd like to see how the result encourages
> modular thinking.
Yes, but we need to fully understand the problems, if just perceived. Please
keep this thread going. I know it's getting a bit long, but it's good discussion.
--
Jeremy Cowgar
http://jeremy.cowgar.com
67. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> We are adding new features to Euphoria and I am just trying to understand
> where
> you think it is lacking so that it can be improved. I have been doing that
> through
> examples relying on your feedback. I am unsure of how else to figure this out.
That's a good reminder. I can often be found drifting into the weeds when
it's a good time to focus. There are practical matters to consider that
perhaps trump any philosophy discussions. I do tend to get caught up in
the abstract when it's time for the specific.
I hope I can be a positive influence to your endeavor. I am wishing you
and everyone taking part much success.
68. Re: Do you currently use namespaces?
ken mortenson wrote:
>
>
> You say myprog.ex can't access a:hello() in any way. Got that. But again,
> a include c, b include d. If I understand correctly, then myprog.ex could
> call c:hello() or d:hello() even though they are not declared in myprog?
>
> If so, this is not a good module. However, I get the impression this is
> still an issue under discussion. I'd like to see how the result encourages
> modular thinking.
Wait.. I think I misunderstood in my previous reply. Are you saying that if
include c defines a function for export and myprog.ex includes c directly that it
*shoulnd't* be able to access it? That that is bad modular programming?
--
Jeremy Cowgar
http://jeremy.cowgar.com
69. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> Matt Lewis wrote:
> >
> > It's not a matter of including it twice. His point was that your code
> > should
> > include what it needs. Your statement is actually the antithesis of modular
> > programming, IMHO. Each module should explicitly declare its dependencies.
> > Euphoria has never required this, though it will at least generate a
> > warning in 4.0.
> >
>
> In addition, if you use namespaces, you can forget the fact 100% that anything
> is global throughout the entire program. For instance:
Almost. Sort of. You can still get in trouble [theoretically] with
multi-file libraries. If, say win32lib (not picking on it, just that's
it's the most popular multi-file library out there) had naming conflicts
within other files that were part of the library (w32foo.ew and w32bar.ew),
you would have to include those and add a namespace in addition to including
win32lib. I doubt anyone has ever encountered this exact problem, but
someone on the internet was wrong again. :)
Matt
70. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> ken mortenson wrote:
> >
> > You say myprog.ex can't access a:hello() in any way. Got that. But again,
> > a include c, b include d. If I understand correctly, then myprog.ex could
> > call c:hello() or d:hello() even though they are not declared in myprog?
> >
> > If so, this is not a good module. However, I get the impression this is
> > still an issue under discussion. I'd like to see how the result encourages
> > modular thinking.
>
> Wait.. I think I misunderstood in my previous reply. Are you saying that if
> include c defines a function for export and myprog.ex includes c directly that
> it *shoulnd't* be able to access it? That that is bad modular programming?
No. My scenario only had fileA include fileC, etc. Which is if I now
understand correctly means that myprog can not call c:hello() If myprog
directly included fileC then I would expect it to be able to call c:hello()
as easily as a:hello() and b:hello()
Regarding modularity, I guess this could be considered a practical solution.
My intuition tells me there is more to this issue however. I'll have to
give it some more thought.
71. Re: Do you currently use namespaces?
Matt Lewis wrote:
> I doubt anyone has ever encountered this exact problem, but
> someone on the internet was wrong again. :)
>
Again? LOL!
--
Jeremy Cowgar
http://jeremy.cowgar.com
72. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Jeremy Cowgar wrote:
> > In addition, if you use namespaces, you can forget the fact 100% that
> > anything
> > is global throughout the entire program. For instance:
>
> > include FileA.e as a
> > include FileB.e as b
> > a:hello()
> > b:hello()
>
> I see the point you make regarding the similarity in the following. However,
>
> what happens if FileA.e above includes FileC.e and FileB.e includes FileD.e
> which both have hello(). Does your main file have to know to declare a
> namespace for the includes withing files A & B? This violates the
> principle of information hiding.
The namespace that you use for a and b is also used to deconflict down through
all of the includes of a and b, so a:hello() could refer to something in
FileC.e.
You are correct in that our ability to hide information needs some additional
power. The local/global that we currently have isn't fine enough.
Matt
73. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> ken mortenson wrote:
> >
> > Jeremy Cowgar wrote:
> >
> > > -- filea.e
> > > global procedure hello()
> >
> > > -- fileb.e
> > > include filea.e as a
> > > global procedure hello()
> >
> > > -- myprog.ex
> > > include fileb.e as b
> > > b:hello() -- prints "fileb: hello"
> > >
> > > myprog.ex cannot access a:hello() in any way. It would have to directly
> > > include
> > > filea.e to access filea.e's hello()
> >
> > Amazing, you figured out what I was trying to say even when I couldn't!!!
> >
> > Let me look at this...
> >
> > You say myprog.ex can't access a:hello() in any way. Got that. But
> > again, a include c, b include d. If I understand correctly, then
> > myprog.ex could call c:hello() or d:hello() even though they are not
> > declared in myprog?
> >
>
> No, that's incorrect. if myprog.ex never includes directly c, or d then myprog
> could not call c:hello() nor d:hello().
To clarify, the reason for this is that a:hello() is masked by b:hello(). If
there were no b:hello(), then b:hello() would really refer to the hello()
in filea.e.
Matt
74. Re: Do you currently use namespaces?
Matt Lewis wrote:
> > In addition, if you use namespaces, you can forget the fact 100% that
> > anything
> > is global throughout the entire program. For instance:
>
> Almost. Sort of. You can still get in trouble [theoretically] with
> multi-file libraries. If, say win32lib (not picking on it, just that's
> it's the most popular multi-file library out there) had naming conflicts
> within other files that were part of the library (w32foo.ew and w32bar.ew),
> you would have to include those and add a namespace in addition to including
> win32lib. I doubt anyone has ever encountered this exact problem, but
> someone on the internet was wrong again. :)
It's rather pleasant to have my intuition confirmed so quickly.
With regard to usage. Are we looking at the use of namespaces being
sort of all or nothing? I'm not saying it would be a requirement, but once
you start leaning on namespaces to solve collisions, you would tend to
have every include be given a name?
Will there be instances where you didn't give an include a namespace and
find that later you must? Like adding a new lib to your project? This may
not be a top level include, requiring a hunt through who knows how many
files (depending on project size.)
While the usage may be consistant, you might have an issue with consistant
usage? I suspect I'm not being clear.
75. Re: Do you currently use namespaces?
Matt Lewis wrote:
> To clarify, the reason for this is that a:hello() is masked by b:hello(). If
> there were no b:hello(), then b:hello() would really refer to the hello()
> in filea.e.
>
> Matt
I'm not following, but others probably do.
76. Re: Do you currently use namespaces?
Matt Lewis wrote:
> You are correct in that our ability to hide information needs some additional
> power. The local/global that we currently have isn't fine enough.
It's just my gut, but this paradigm may not be resolvable regardless of
the fineness. I believe there is a fundamental flaw in the concept of
trying to fix the issues inherent with using includes as the application
gets more complex. I know that classes resolves the issue. The problem
of course is implementing classes when you are on track to use includes.
I need to be more specific of course, but I need to think for awhile.
77. Re: Do you currently use namespaces?
Derek Parnell wrote:
>
> CChris wrote:
>
> > This means that multiple files have to exchange
> > information through interface identifiers, since
> > an identifier that is visible in several files
> > is promoted to interface symbol. This makes it
> > unsafe to break a large body of code into
> > smaller, more maintainable files, because all
> > exchanges are not supposed to involve "public"
> > data or routines. And because making public these
> > symbols may interfere with any application that
> > uses the library.
>
> By "public" I assume you mean "able to be directly referred to by code that
> is outside the declaring file".
Not exactly. By "public", I meant: available _everywhere_ outside the defining
file, including an application including the lib. The issue is that they
currently need to be as much public as that.
> However, it has to be done that way if you want
> to directly refer to an entity by name - the name must be visible for your
> code
> to 'see' it. If you prefer indirect references, you can get away with not
> knowing
> the entity's real name but at a performance overhead or via an alias symbol.
> An alias is not a solution because its still a visible name.
>
You can inded replace a global routine by a global routine_id of a local
routine, or a global variable by a global setter/getter. There is still a
promiscuous symbol, and an extra performance penalty.
> Also, the "public" access to data and not routines is the major problem with
> module coupling. With routines, one publishes the API and (try to) keep the
> API unchanged. Meaning you should be able to move the routine to a new module
> and not break the code using it.
>
> I assume that when you say "interfere with any application" you are referring
> to naming conflicts. This, as you well know, is what is being addressed in
> v4.0.
There are several kinds of naming conflicts.
If an application file, ie a file not supposed to be freely included anywhere,
defines a symbol that exists in the lib the application as a whole includes, then
the name should be changed in the applcation file. So these conflicts should
never happen.
The problem is the conflict between an application level identifier and an
internal symbol from the library. The lib is assumed to be a black box, so it
shouldn't matter whether it is split across several files. Also, these
undocumented symbols may appear, change name or disappear at will, since they are
not in the documented API of the lib. These conflicts haven't been discussed so
far.
Conflicts between several co-included libraries are a potential issue only, as
far as I am aware of. It's the projected design of the new stdlib which is going
to make them actual. They need to be addressed, but this is currently shadowing
actual problems with potential problems.
CChris
>
> Of course, one further way to restrict naming conflicts is to reduce the
> visibility
> of symbols. 'global' makes it seen by all including levels, even if they don't
> need to see it. One suggestion being kicked around is to allow 'global' items
> to only be seen by the file directly including it. Discussion continues on
> this
> front.
>
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
78. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> CChris wrote:
> >
> >
> > Open win32lib.ew and go through the code. Inclusion ordeer and placement in
> > the file are crucial, and sometimes a headache to figure out.
> >
>
> I thought the reference was in regards to include statements about order. It
> certainly does matter in source and I don't really think that's a bad thing.
> Sometimes it would be nice to have forward references as well as backwards
> with-in
> a file, but for the most part, I think most issues are easily resolved.
>
> Quite a few languages have this "limitation". Modular and non-modular
> languages
> alike, that's why I thought the reference was in regards to include
> statements.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Both forward referencing and include placement and order.
If you want to break a set of functionality in a logical order, one should be
able to do that. Currently, the conjunction of syntax rules about the positions
of dclaring and using a symbol make that very difficult at best.
CChris
79. Re: Do you currently use namespaces?
In BBCMF, I've got a long list of includes. The includes at the bottom
depend on includes at the top. Is there a better/preferred way? Here's
an analogy:
-- bbcmf.e
include a.e
include b.e
include c.e
include d.e -- relies on a, b
include f.e -- relies on c, d
include g.e -- relies on d, f
-- index.esp -- the main program
include bbcmf.e
80. Re: Do you currently use namespaces?
c.k.lester wrote:
>
> In BBCMF, I've got a long list of includes. The includes at the bottom
> depend on includes at the top. Is there a better/preferred way? Here's
> an analogy:
>
> -- bbcmf.e
> include a.e
> include b.e
> include c.e
> include d.e -- relies on a, b
> include f.e -- relies on c, d
> include g.e -- relies on d, f
>
> -- index.esp -- the main program
> include bbcmf.e
d,f and g should make certain to include any file they need. Then, even if
your main file doesn't use one of the dependencies, you'll still have
working code.
Matt
81. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> With regard to usage. Are we looking at the use of namespaces being
> sort of all or nothing? I'm not saying it would be a requirement, but once
> you start leaning on namespaces to solve collisions, you would tend to
> have every include be given a name?
It's not a requirement, though some people already code this way. Namespaces
are the way in which you can resolve a collision. There's also going to
be the ability to specify a default namespace for your library, which users
could use.
> Will there be instances where you didn't give an include a namespace and
> find that later you must? Like adding a new lib to your project? This may
> not be a top level include, requiring a hunt through who knows how many
> files (depending on project size.)
Yes. If you didn't specify a namespace, it's very possible that a later
addition to your application could conflict with some other symbol that
didn't need any qualifier previously.
> While the usage may be consistant, you might have an issue with consistant
> usage? I suspect I'm not being clear.
Yeah, I'm not even trying to parse that one. :)
> It's just my gut, but this paradigm may not be resolvable regardless of
> the fineness. I believe there is a fundamental flaw in the concept of
> trying to fix the issues inherent with using includes as the application
> gets more complex. I know that classes resolves the issue. The problem
> of course is implementing classes when you are on track to use includes.
>
> I need to be more specific of course, but I need to think for awhile.
Classes only resolve the issue until you have multiple classes with the
same name. I disagree with the main assertion, however. I believe that
at this point it is totally possible to resolve any conflict with the
tools that we have. By this, I mean that it should be possible to combine
any [working!] third party code into a single application without having to
modify any of the third party code.
The information hiding is actually not *required* for this, though it could
make the job easier by reducing the amount of symbols available to any
particular scope.
Matt
82. Re: Do you currently use namespaces?
Matt Lewis wrote:
> c.k.lester wrote:
> > -- bbcmf.e
> > include a.e
> > include b.e
> > include c.e
> > include d.e -- relies on a, b
> > include f.e -- relies on c, d
> > include g.e -- relies on d, f
> >
> > -- index.esp -- the main program
> > include bbcmf.e
>
> d,f and g should make certain to include any file they need. Then, even if
> your main file doesn't use one of the dependencies, you'll still have
> working code.
That seems to violate DRY... Or doesn't it?
But, I can see the case for including dependencies. How much more memory
does this require, or does the interpreter see that I've included something
earlier and it can just use that copy?
83. Re: Do you currently use namespaces?
Matt Lewis wrote:
> Classes only resolve the issue until you have multiple classes with the
> same name.
Perhaps in theory, but I've never actually seen a real world example (not
that it couldn't happen.) Any class would normally have many properties
and methods which would have no collision issues. For the class name
itself, most classes are those the programmer defines so those aren't a
problem. So 3rd party libraries are the only issue. What about them?
If in the form of two DLL's with the same name, you just put them into
two different folders. So that leaves a third party source library. Again,
you could simply have the library in a separate folder. So I just don't
see any possible problem with class name collisions. Devil's advocate, how
could I intentionally create a class name conflict? Of course, in VB, class
names and file names are the same and there is one class per file. That may
not be the case if the classes are implemented in some different way.
> I disagree with the main assertion, however.
Time will answer that question as it invariably does.
> I believe that
> at this point it is totally possible to resolve any conflict with the
> tools that we have. By this, I mean that it should be possible to combine
> any [working!] third party code into a single application without having to
> modify any of the third party code.
I completely agree with this as a goal.
> The information hiding is actually not *required* for this, though it could
> make the job easier by reducing the amount of symbols available to any
> particular scope.
>
> Matt
Just as a principle, all symbols should have scope as limited as possible.
84. Re: Do you currently use namespaces?
Matt Lewis wrote:
> d,f and g should make certain to include any file they need. Then, even if
> your main file doesn't use one of the dependencies, you'll still have
> working code.
I can see the rationale here; I guess I just hate the idea of doing this:
-- a.e
shared_code()
-- b.e
include a.e
-- c.e
include a.e
...
-- z.e
include a.e
-- myapp.exw
include b.e
include c.e
when I could be doing this:
-- a.e
shared_code()
-- myapp.exw
include a.e -- here included ONCE, for everybody to use
include b.e -- depends on a.e
include c.e -- depends on a.e
...
include z.e -- depends on a.e
But, really, if you're going to depend on a lib, I guess you really should
include it explicitly. :/
85. Re: Do you currently use namespaces?
ken mortenson wrote:
>
> Matt Lewis wrote:
>
> > Classes only resolve the issue until you have multiple classes with the
> > same name.
>
> Perhaps in theory, but I've never actually seen a real world example (not
> that it couldn't happen.) Any class would normally have many properties
> and methods which would have no collision issues.
I see them all the time in, for instance, Java. Different libraries often
have similar class names. One common one that comes to mind is 'Query.'
> For the class name
> itself, most classes are those the programmer defines so those aren't a
> problem.
Only if you always roll your own. I think most people use at least some
third party code, even if it's only from the standard library. You have
no control over how those things are named.
> So 3rd party libraries are the only issue. What about them?
> If in the form of two DLL's with the same name, you just put them into
> two different folders. So that leaves a third party source library. Again,
> you could simply have the library in a separate folder.
This is one way to disambiguate. I assume you're thinking of something like
Java or perl, where file structure has meaning within the code.
> So I just don't see any possible problem with class name collisions.
> Devil's advocate, how could I intentionally create a class name conflict?
> Of course, in VB, class names and file names are the same and there is one
> class per file. That may not be the case if the classes are implemented
> in some different way.
It could still be a problem. What if you're using two different libraries,
each of which define a class with the same name? For example, what if you
have one library for using a database, and another for doing xslt stuff.
It's pretty easy to imagine that both might have a Query class, for instance.
The bottom line is that you need some sort of container which is in the
control of the end user (at least, if you want *any* combination of 3rd
party code to be usable together). You can use file structure. Euphoria
doesn't use this. It uses namespaces.
> > The information hiding is actually not *required* for this, though it could
> > make the job easier by reducing the amount of symbols available to any
> > particular scope.
>
> Just as a principle, all symbols should have scope as limited as possible.
Yes, I think we all agree on this.
Matt
86. Re: Do you currently use namespaces?
c.k.lester wrote:
>
> Matt Lewis wrote:
> >
> > d,f and g should make certain to include any file they need. Then, even if
> > your main file doesn't use one of the dependencies, you'll still have
> > working code.
>
> That seems to violate DRY... Or doesn't it?
I would argue that it doesn't, or that it's at least a reasonable exception.
Since both files need depend upon the code, it's just being more explicit
about things.
> But, I can see the case for including dependencies. How much more memory
> does this require, or does the interpreter see that I've included something
> earlier and it can just use that copy?
The additional memory is trivial (basically, euphoria remembers who included
whom, so it's an extra integer in a sequence). The file is only read once.
But this information is used later to determine symbol resolution.
Suppose that someone were using bbcmf and some other library. Now suppose
that this other library exposed a global symbol that had the same name as
something in one of your files (let's say filed.e). Under 3.1, if the
other library were included before bbcmf, you'd get an error when that
symbol was used in bbcmf, because there would be two globals with that name.
Under 4.0, the parser will see that while there are two symbols, bbcmf actually
included filed.e, but not the other library, so it obviously meant to use
the symbol in filed.e.
Matt
87. Re: Do you currently use namespaces?
c.k.lester wrote:
>
> Matt Lewis wrote:
> > d,f and g should make certain to include any file they need. Then, even if
> > your main file doesn't use one of the dependencies, you'll still have
> > working code.
>
> I can see the rationale here; I guess I just hate the idea of doing this:
<snip>
> But, really, if you're going to depend on a lib, I guess you really should
> include it explicitly. :/
Yes. It has several benefits. Some are to you, the original coder:
* It makes it easier to see what the dependencies really are.
* It helps resolve some of the 'order of include' issues you've run into.
Some are for your downstream users:
* If they want to use one of your modules apart from your library, it's
easy to see the dependencies, and ensure they are correct. See the
history of win32lib's memory management code for an example.
* It prevents conflicts that could only be resolved by having an end user
edit 3rd party code.
BTW, in 4.0, not including the files (directly or indirectly) will result in a
warning.
Matt
88. Re: Do you currently use namespaces?
Matt Lewis wrote:
> Different libraries often have [some duplicate] class names.
Sure. I've never found that to be a problem because of the way VB
implements classes. Never.
> The bottom line is that you need some sort of container which is in the
> control of the end user (at least, if you want *any* combination of 3rd
> party code to be usable together). You can use file structure. Euphoria
> doesn't use this.
But it could. It's just a question of implementation. The great advantage
of using file structure is it's a natural way to organize code (not to be
dismissed lightly.)
89. Re: Do you currently use namespaces?
Matt Lewis wrote:
>
> c.k.lester wrote:
> >
> > Matt Lewis wrote:
> > >
> > > d,f and g should make certain to include any file they need. Then, even
> > > if
> > > your main file doesn't use one of the dependencies, you'll still have
> > > working code.
> >
> > That seems to violate DRY... Or doesn't it?
>
> I would argue that it doesn't, or that it's at least a reasonable exception.
>
> Since both files need depend upon the code, it's just being more explicit
> about things.
>
This is completely against modular programming.
If fileB.e depends on any file that provide something, but is meant to be
included by them, you'll have fileA1.e and fileA2.e which will include fileB.e.
Fine.
But now, what to code in fileB.e?
include fileA1.e -- but fileA2.e might do as well
or
include fileA2.e -- then what about the possibiity for fileA1.e?
True, you may use the new ifdef statement to choose which one. But this misses
the core point.
The core point is that you need to know the name of a file to include it. But
you don't know the name of all the third party files that might benefit from
including fileB.e, since what is needed is only some properties of the including
file. This goes against reusability of fileB.e.
CChris
> > But, I can see the case for including dependencies. How much more memory
> > does this require, or does the interpreter see that I've included something
> > earlier and it can just use that copy?
>
> The additional memory is trivial (basically, euphoria remembers who included
> whom, so it's an extra integer in a sequence). The file is only read once.
> But this information is used later to determine symbol resolution.
>
> Suppose that someone were using bbcmf and some other library. Now suppose
> that this other library exposed a global symbol that had the same name as
> something in one of your files (let's say filed.e). Under 3.1, if the
> other library were included before bbcmf, you'd get an error when that
> symbol was used in bbcmf, because there would be two globals with that name.
>
> Under 4.0, the parser will see that while there are two symbols, bbcmf
> actually
> included filed.e, but not the other library, so it obviously meant to use
> the symbol in filed.e.
>
> Matt
90. Re: Do you currently use namespaces?
CChris wrote:
>
> Matt Lewis wrote:
> >
> > Since both files need depend upon the code, it's just being more explicit
> > about things.
> >
>
> This is completely against modular programming.
Wrong.
> If fileB.e depends on any file that provide something, but is meant to be
> included by them, you'll have fileA1.e and fileA2.e which will include
> fileB.e. Fine.
Your pattern is broken. This would be equivalent to win32lib (old days)
relying on the application to define the handler sequences, like onClick.
Instead, we have a procedure in win32lib, setHandler, that the program
calls to set the variables.
Most languages (OK, that's an unproven assertion, but I can think of at
least C/C++, java, perl and python) wouldn't even let you get away with
this.
> But now, what to code in fileB.e?
>
> include fileA1.e -- but fileA2.e might do as well
> or
> include fileA2.e -- then what about the possibiity for fileA1.e?
>
> True, you may use the new ifdef statement to choose which one. But this
> misses the core point.
>
> The core point is that you need to know the name of a file to include it.
> But you don't know the name of all the third party files that might benefit
> from including fileB.e, since what is needed is only some properties of
> the including file. This goes against reusability of fileB.e.
Again, your pattern is broken. You should expose an API for those that use
your library to supply whatever initialization stuff you need. You also
get the free bonus that you don't require that more symbols be global.
Matt
91. Re: Do you currently use namespaces?
- Posted by CChris <christian.cuvier at a?riculture?gouv.fr>
May 26, 2008
-
Last edited May 27, 2008
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Matt Lewis wrote:
> > >
> > > Since both files need depend upon the code, it's just being more explicit
> > > about things.
> > >
> >
> > This is completely against modular programming.
>
> Wrong.
>
> > If fileB.e depends on any file that provide something, but is meant to be
> > included by them, you'll have fileA1.e and fileA2.e which will include
> > fileB.e. Fine.
>
> Your pattern is broken. This would be equivalent to win32lib (old days)
> relying on the application to define the handler sequences, like onClick.
> Instead, we have a procedure in win32lib, setHandler, that the program
> calls to set the variables.
>
> Most languages (OK, that's an unproven assertion, but I can think of at
> least C/C++, java, perl and python) wouldn't even let you get away with
> this.
>
> > But now, what to code in fileB.e?
> >
> > include fileA1.e -- but fileA2.e might do as well
> > or
> > include fileA2.e -- then what about the possibiity for fileA1.e?
> >
> > True, you may use the new ifdef statement to choose which one. But this
> > misses the core point.
> >
> > The core point is that you need to know the name of a file to include it.
> > But you don't know the name of all the third party files that might benefit
> > from including fileB.e, since what is needed is only some properties of
> > the including file. This goes against reusability of fileB.e.
>
> Again, your pattern is broken. You should expose an API for those that use
> your library to supply whatever initialization stuff you need. You also
> get the free bonus that you don't require that more symbols be global.
>
> Matt
The construct is perfectly valid in 3.1, and would serve a definite purpose, ie
implementing plugin file schemes. Perhaps removing this ability will not actually
break code. But I see no benefit to offset the loss.
CChris
92. Re: Do you currently use namespaces?
- Posted by Matt Lewis <matthewwalkerlewis at gmai?.?om>
May 26, 2008
-
Last edited May 27, 2008
CChris wrote:
>
> Matt Lewis wrote:
> >
> > CChris wrote:
> > >
> > > The core point is that you need to know the name of a file to include it.
> > > But you don't know the name of all the third party files that might
> > > benefit
> > > from including fileB.e, since what is needed is only some properties of
> > > the including file. This goes against reusability of fileB.e.
> >
> > Again, your pattern is broken. You should expose an API for those that use
> > your library to supply whatever initialization stuff you need. You also
> > get the free bonus that you don't require that more symbols be global.
>
> The construct is perfectly valid in 3.1, and would serve a definite
> purpose, ie implementing plugin file schemes. Perhaps removing this
> ability will not actually break code. But I see no benefit to offset
> the loss.
There is no loss. You can still implement this. It's still a bad idea, and
that's why the warning is there. So in reality, there is no loss, and only
benefit.
Consider the case when some other library that your user uses happens to have
some global that has the same name as one that you require the user to
implement? Now your library will break if it isn't included first, or if the
user modifies your code.
I'll say it again. Using this pattern makes it so that your code will play
nice with other code. If you're just writing the final application, then
you can be assured that your poorly structured code will not mess up anyone
else. After all, you can always edit your code. If you're going to release
your code for others to use, however, you're creating potential problems
if you continue to use this pattern.
You don't need to do that for plugins. In fact, this would seem to limit
the number of plugins you could use, since you rely on calling discrete
things. It would be like hardcoding Window in win32lib as an atom, and
having users create their window and store it in that variable. But what
if I want two windows in my app?
Or, if you still coded it with sequences, and had users append their stuff
to some global that you used, you're now doing the opposite of modular
coding, since you've coupled the library and the application so closely.
Matt
93. Re: Do you currently use namespaces?
- Posted by Derek Parnell <ddparnell at bigpond.??m>
May 26, 2008
-
Last edited May 27, 2008
The D programming language has the addition concept of a package. I believe that
Java has too. A package is essentially a named collection of modules. Anyhow, the
thing is you can declare a symbol has being exposed only to its module, or only
to its package, or to everything.
Maybe this can be used in Euphoria too somehow.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
94. Re: Do you currently use namespaces?
- Posted by Jeremy Cowgar <jeremy at cow?ar?com>
May 26, 2008
-
Last edited May 27, 2008
Derek Parnell wrote:
>
> The D programming language has the addition concept of a package. I believe
> that Java has too. A package is essentially a named collection of modules.
> Anyhow,
> the thing is you can declare a symbol has being exposed only to its module,
> or only to its package, or to everything.
>
> Maybe this can be used in Euphoria too somehow.
>
Derek,
We currently have the ability for a file to declare it's namespace, what do you
think about building from it:
-- pack_a.e
namespace pack
friend integer abc
-- pack_b.e
namespace pack
include pack_a.e
? abc
I have no idea if friend is a good word or not, but it's not global and not
local. It says you can share this item with other files in the same namespace.
--
Jeremy Cowgar
http://jeremy.cowgar.com
95. Re: Do you currently use namespaces?
Matt Lewis wrote:
>
> This is one way to disambiguate. I assume you're thinking of something like
> Java or perl, where file structure has meaning within the code.
> It could still be a problem. What if you're using two different libraries,
> each of which define a class with the same name? For example, what if you
> have one library for using a database, and another for doing xslt stuff.
> It's pretty easy to imagine that both might have a Query class, for instance.
>
> The bottom line is that you need some sort of container which is in the
> control of the end user (at least, if you want *any* combination of 3rd
> party code to be usable together). You can use file structure. Euphoria
> doesn't use this. It uses namespaces.
I think that's where Euphoria leaves the beaten track a bit. Java and Perl are
good examples for your example above with having names like (for example)
MySQL::Query() or com.xxyyzz.xslt.Query(). No problem, except for the extra
typing involved, which personally I don't mind and each language provides means
to import those function names directly into your main namespace if you know
you'll rely heavily on them.
Even Python (from my all of two months experience with it) seems to 'namespace'
through levels of, shall we say, containment: os.path.join(...), string.join(...)
where they both behave differently.
The aim with Euphoria seems to be to bring everything up to the level of the
main program with the least amount of namespacing required, but to have the
facility available in case of conflicts. This is fine by me, but I think this is
an opportunity to bring some level of modularity to the language that is
currently a bit 'loose', and I don't think it would break too much to implement
something at this stage (but that is obviously the target of your discussions on
the dev list which I haven't caught up on).
I saw mention of a default namespace being created by the coder of the include.
Well why not make the default namespace the name of the file, without .e[??] at
the end? Even better, why not work out its path relative to the EUINC folder it
is in and make that the default namespace? Even even better (all IMHO of course)
provide a function that returns the name (or numeric id) of that default
namespace?
From the one minute of thought I just gave to that scenario you'd have the
start of a basic roll-your-own OO system, without inheritance and all that guff,
since you could store instantiated data mapped to that namespace and pass around
an instance id to your 'class' methods (ie global routines in the include)
designed to use it.
I don't see how that would break anything since you could still use the
include..as mechanism, and any library taking advantage of the OOness would be
coded specifically to use that system (and be appropriately documented so).
Euphoria's type checking would even make it possible to do both, like Perl, a
procedural and an OO interface, it can even just be used as a default namespace
mechanism.
I'm happy to provide a comprehensive example of what I mean by all that if it is
seen as a good idea or needs clarification. If it's not a good idea, I'd like to
know why? :)
Gary
96. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
> We currently have the ability for a file to declare it's namespace, what do
> you think about building from it:
>
> I have no idea if friend is a good word or not, but it's not global and not
> local. It says you can share this item with other files in the same namespace.
To recap, in v3 a namespace is a local symbol. That is, the namespace name
itself is only visible in the file that declares it, and that name lives in the
file's scope so namespace name in a file must be unique.
This means that ...
include foo.e as foo
include bar.e as foo
would fail.
Jeremy,
if I read you correctly, you are suggesting that in v4 we expand the namespace
concept to become more like a package, such that all files with the same
namespace name form a logical collection of modules, and that we should then be
able to nominate which symbols in a file can be seen at the 'package'/'namespace'
level but not outside that level. Ths would be a different scope from both
private (to the module/file) and global.
Have I got your thinking correct?
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
97. Re: Do you currently use namespaces?
Derek Parnell wrote:
>
> Jeremy,
> if I read you correctly, you are suggesting that in v4 we expand the namespace
> concept to become more like a package, such that all files with the same
> namespace
> name form a logical collection of modules, and that we should then be able to
> nominate which symbols in a file can be seen at the 'package'/'namespace'
> level
> but not outside that level. Ths would be a different scope from both private
> (to the module/file) and global.
>
> Have I got your thinking correct?
>
Yes, however, as said on dev-list, it really is just one of many existing
suggestions already and I do not yet fully understand the problem, let alone the
perfect solution. So I am simply tossing out a slightly (I do understand the
problem a bit) uneducated thought for comment to promote pro/con and other
suggestion ideas.
--
Jeremy Cowgar
http://jeremy.cowgar.com
98. Re: Do you currently use namespaces?
Derek Parnell wrote:
>
> The D programming language has the addition concept of a package. I
> believe that Java has too. A package is essentially a named collection of
> modules. Anyhow, the thing is you can declare a symbol has being exposed
> only to its module, or only to its package, or to everything.
>
> Maybe this can be used in Euphoria too somehow.
CChris has a pretty detailed proposal on how to do this. In java, anything
in the same package does not need an import, but there is still the issue
of public/private/protected.
Java relies heavily on using the filesystem for packages, and is how you
end up with things that are fully qualified as org.rds.regex.search. Perl
is somewhat similar. I think C++ is closer to what CChris proposed.
My feelings about introducing something like this is that I don't think it's
needed. It would be another concept similar, but different from namespaces.
Perhaps if we'd started there...but we didn't.
I think that the missing piece is one additional scope (named something like
"export") that allows files that include a file to see symbols in that scope,
but not any further. In other words:
-- app.ex
include foo.e
? BAR -- BAR not defined here
-- foo.e
include bar.e
? BAR -- ok
-- bar.e
export constant BAR = 1
And then we declare that export is the new global. All of the standard
libraries should use this by default. For compatibility's sake, we probably
shouldn't go back and change existing stuff.
For a multi-file library like win32lib, files could still be logically
organized, but it would be possible to keep internals from leaking out.
One reason I prefer this approach over packaging (over CChris', at least,
other packaging proposals might differ) is that individual files don't
rely on some external resource to define the package. They simply define
their own dependencies and expose an interface with two types of scope.
Part of this comes from the fact that it's sometimes useful to take bits
from a library like win32lib. I might not need or want everything, but
I might want to use its memory management/structure modules. To me,
this is a more modular approach than to define a static set of things as
a package. Looking at a file, I can know all about it by reading it, and
following its include statements, rather than referring to a parent file
that defines its package.
YMMV
Matt
99. Re: Do you currently use namespaces?
Hi CK,
I had a look at BBCMF to see if I could mebbe help or something. Where is the
zip
file? All I see are lots of indiviudal source files...
Mike
PS: I couldn't see any obvious email address to send this message directly to
you..
c.k.lester wrote:
>
> In BBCMF, I've got a long list of includes. The includes at the bottom
> depend on includes at the top. Is there a better/preferred way? Here's
> an analogy:
>
> -- bbcmf.e
> include a.e
> include b.e
> include c.e
> include d.e -- relies on a, b
> include f.e -- relies on c, d
> include g.e -- relies on d, f
>
> -- index.esp -- the main program
> include bbcmf.e
100. Re: Do you currently use namespaces?
Mike wrote:
>
> I had a look at BBCMF to see if I could mebbe help or something. Where is the
> zip file? All I see are lots of indiviudal source files...
Hey, Mike! Thanks for taking a look... or wanting to. :)
The download page is here:
http://bbcmf.com/?page=1&content=download_page
The whole system is available via SVN.
I stopped posting the ZIP files because things change so quickly. I'd be
happy to zip them up, though, and email them to you (or make them otherwise
available via my site).
Let me know what you want to do.
101. Re: Do you currently use namespaces?
c.k.lester wrote:
> Mike wrote:
> > I had a look at BBCMF to see if I could mebbe help or something. Where is
> > the
> > zip file? All I see are lots of indiviudal source files...
> Hey, Mike! Thanks for taking a look... or wanting to. :)
Mike, here's how to set it all up:
http://bbcmf.com/documentation/index.html#install
102. Re: Do you currently use namespaces?
I've been following this thread and I think some things are kinda... weird.
I think I understand Ken's concerns, and I find some of CChris' styles much like
goto-spaghetti-code.
I think I also understand that massive libraries such as Win32lib have special
requirements.
Maybe I'm just short-sighted because I've only written programs with a few
hundred lines of code instead of a few thousand.
To me, a .e file has both state and interface. Much like an object. I include
files that my program depends upon at the top of the program. Include files
should never look at information in the main program. The main program should
never rely upon the state or the interface of .e files that it does not
explicitly include.
If I was writing a library, which I have not done yet, I would try and make sure
that each individual file was almost completely decoupled from any other file,
except when building blocks. If two files needed to share some mutual state then
I guess that I would write a third file to interface in between them.
So maybe the only modules I'm really used to are in Java and C++ classes, and
the way that C handles include files.
Much like "goto", you can abuse the scope and include system of Euphoria. But
you don't have to do so.
Of course, you wouldn't know that from looking at the interpreter source code
.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
103. Re: Do you currently use namespaces?
Jason Gade wrote:
Good observations Jason, this post provides a lot to chew on.
> I've been following this thread and I think some things are kinda... weird.
If I may, I think the weirdness come from the fact that it overlaps a lot
of distinct issues. My feeling is that often we try to solve the wrong
problem. We lose sight of the goal in the battle over nitty-gritty
brain-twisters.
Is name collision the big issue? Maybe not. Is getting namespaces to
work the goal? Mayby not. Is the goal itself for some limited short
term objective (to get a new version out) or is it something greater?
> I think I understand Ken's concerns, and I find some of CChris' styles much
> like goto-spaghetti-code.
Sometimes I'm not sure I understand my own concerns. I do think that
some concepts are not well shared because of peoples different experience
and focus.
To better understand my concerns, you have to understand that I have a
clear and specific vision of what I want due to my years of work, but
my experience may not be the same as others with different experience.
I'm looking for a very specific tool that could be but isn't. Most
people seem to just want to 'improve' this language by fixing some
observed apparent issues. I'm very strongly in the school of thought
that often less is more. To me, namespaces add complexity (not perhaps
so much in usage as in other ways) without the sufficiently offsetting
benefit.
People will argue that namespaces provides a means of creating modular
code. They might be right. The whole idea of includes and namespaces
would, for me, preclude reaching the level of modularity I desire.
> I think I also understand that massive libraries such as Win32lib have special
> requirements.
>
> Maybe I'm just short-sighted because I've only written programs with a few
> hundred
> lines of code instead of a few thousand.
In the 1975, I thought ten thousand was a lot of lines of code (and a
complete project.) Now that's just one of many hundreds of modules.
> To me, a .e file has both state and interface. Much like an object. I include
> files that my program depends upon at the top of the program. Include files
> should never look at information in the main program. The main program should
> never rely upon the state or the interface of .e files that it does not
> explicitly
> include.
I would say that is an example of modular thinking. Like I say, programmers
write modules, languages don't.
> If I was writing a library, which I have not done yet, I would try and make
> sure that each individual file was almost completely decoupled from any other
> file, except when building blocks. If two files needed to share some mutual
> state then I guess that I would write a third file to interface in between
> them.
>
> So maybe the only modules I'm really used to are in Java and C++ classes, and
> the way that C handles include files.
>
> Much like "goto", you can abuse the scope and include system of Euphoria. But
> you don't have to do so.
>
> Of course, you wouldn't know that from looking at the interpreter source code
> .
System software is a different animal from applications in my book. Think
of machine language. If your high level language provides access to ML then
you already have GOTO in your language even if it's not a specific keyword.
My feeling however, is that a good HLL aught to be able to compile itself
which to me is a test of it's expressiveness. Euphoria scores very highly
in expressiveness. One of my comcerns is losing that expressiveness with
unneeded features (and missing needed features.)
Even having the addition of...
namespace:function() over just function() is the addition of impurity in
the language (admittedly a matter of taste) even though I am a big fan
of dot notation... Instance.method() which some may consider to be
similar. I do hate the blah.blah.blah.dosomething() version of dot
notation.
All I know is that with the right tools I can crank out a huge quantity
of rock solid code and have great joy in the process producing something
that in turn will please others.
I want that!!!
104. Re: Do you currently use namespaces?
Jeremy Cowgar wrote:
>
> Derek Parnell wrote:
> >
> > The D programming language has the addition concept of a package. I believe
> > that Java has too. A package is essentially a named collection of modules.
> > Anyhow,
> > the thing is you can declare a symbol has being exposed only to its module,
> > or only to its package, or to everything.
> >
> > Maybe this can be used in Euphoria too somehow.
> >
>
> Derek,
>
> We currently have the ability for a file to declare it's namespace, what do
> you think about building from it:
>
>
> }}}
<eucode>
> -- pack_a.e
> namespace pack
>
> friend integer abc
>
> -- pack_b.e
> namespace pack
>
> include pack_a.e
>
> ? abc
> </eucode>
{{{
>
> I have no idea if friend is a good word or not, but it's not global and not
> local. It says you can share this item with other files in the same namespace.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
"friend" is familiar for C++ coders;
I had suggested "internal" in my package package;
"protected" is used in other languages I think.
I don't know which looks best, but one is needed.
"private" has been suggested, but it collides with what we use to know as
private variables.
CChris
105. Re: Do you currently use namespaces?
gshingles wrote:
>
> Matt Lewis wrote:
> >
> > This is one way to disambiguate. I assume you're thinking of something like
> > Java or perl, where file structure has meaning within the code.
>
>
>
> > It could still be a problem. What if you're using two different libraries,
> > each of which define a class with the same name? For example, what if you
> > have one library for using a database, and another for doing xslt stuff.
> > It's pretty easy to imagine that both might have a Query class, for
> > instance.
> >
> > The bottom line is that you need some sort of container which is in the
> > control of the end user (at least, if you want *any* combination of 3rd
> > party code to be usable together). You can use file structure. Euphoria
> > doesn't use this. It uses namespaces.
>
> I think that's where Euphoria leaves the beaten track a bit. Java and Perl
> are good examples for your example above with having names like (for example)
> MySQL::Query() or com.xxyyzz.xslt.Query(). No problem, except for the extra
> typing involved, which personally I don't mind and each language provides
> means
> to import those function names directly into your main namespace if you know
> you'll rely heavily on them.
>
> Even Python (from my all of two months experience with it) seems to
> 'namespace'
> through levels of, shall we say, containment: os.path.join(...),
> string.join(...)
> where they both behave differently.
>
> The aim with Euphoria seems to be to bring everything up to the level of the
> main program with the least amount of namespacing required, but to have the
> facility available in case of conflicts. This is fine by me, but I think this
> is an opportunity to bring some level of modularity to the language that is
> currently a bit 'loose', and I don't think it would break too much to
> implement
> something at this stage (but that is obviously the target of your discussions
> on the dev list which I haven't caught up on).
>
> I saw mention of a default namespace being created by the coder of the
> include.
> Well why not make the default namespace the name of the file, without .e[??]
> at the end? Even better, why not work out its path relative to the EUINC
> folder
> it is in and make that the default namespace? Even even better (all IMHO of
> course) provide a function that returns the name (or numeric id) of that
> default
> namespace?
>
For several reasons:
* mylib_v1.e may become mylib_v2.e
* file names may contain invalid characters for an Euphoria identifier,
including, worst of all, spaces;
* What is the name of fileA.e under Windows? Its short 8.3 name? its lowercased
form? its uppercased form?
* Having all of the above in mind, copy your library from one platform to
another, and have fun.
CChris
> From the one minute of thought I just gave to that scenario you'd have the
> start of a basic roll-your-own OO system, without inheritance and all that
> guff,
> since you could store instantiated data mapped to that namespace and pass
> around
> an instance id to your 'class' methods (ie global routines in the include)
> designed
> to use it.
>
> I don't see how that would break anything since you could still use the
> include..as
> mechanism, and any library taking advantage of the OOness would be coded
> specifically
> to use that system (and be appropriately documented so). Euphoria's type
> checking
> would even make it possible to do both, like Perl, a procedural and an OO
> interface,
> it can even just be used as a default namespace mechanism.
>
> I'm happy to provide a comprehensive example of what I mean by all that if it
> is seen as a good idea or needs clarification. If it's not a good idea, I'd
> like to know why? :)
>
> Gary
106. Re: Do you currently use namespaces?
CChris wrote:
>> Well why not make the default namespace the name of the file,
>> without .e[??] at the end?
> For several reasons:
> * mylib_v1.e may become mylib_v2.e
> * file names may contain invalid characters for an Euphoria identifier,
> including,
> worst of all, spaces;
> * What is the name of fileA.e under Windows? Its short 8.3 name? its
> lowercased
> form? its uppercased form?
> * Having all of the above in mind, copy your library from one platform to
> another,
> and have fun.
OMG! These are problems that can never be solved in our lifetime. Let's all
panic and run away now.
... or ...
* Use the new v4.0 'namespace' directive to provide a default name for
"mylib_v1.e" and thus also "mylib_v2.e"
* Strip out illegal identifier characters
* Convert to lowercase
* As coded by the application author on the include statement
* Huh??? What's the problem with different platforms and file names?
Come on Chris, try to help solve the issues. Please, we need all the good ideas
we can get,
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
107. Re: Do you currently use namespaces?
Derek Parnell wrote:
>
> CChris wrote:
>
> >> Well why not make the default namespace the name of the file,
> >> without .e[??] at the end?
>
>
> > For several reasons:
> > * mylib_v1.e may become mylib_v2.e
> > * file names may contain invalid characters for an Euphoria identifier,
> > including,
> > worst of all, spaces;
> > * What is the name of fileA.e under Windows? Its short 8.3 name? its
> > lowercased
> > form? its uppercased form?
> > * Having all of the above in mind, copy your library from one platform to
> > another,
> > and have fun.
>
> OMG! These are problems that can never be solved in our lifetime. Let's all
> panic and run away now.
>
> ... or ...
>
> * Use the new v4.0 'namespace' directive to provide a default name for
> "mylib_v1.e"
> and thus also "mylib_v2.e"
> * Strip out illegal identifier characters
> * Convert to lowercase
> * As coded by the application author on the include statement
> * Huh??? What's the problem with different platforms and file names?
>
> Come on Chris, try to help solve the issues. Please, we need all the good
> ideas
> we can get,
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
That's why I don't think using a file name as default namespace is convenient,
and was stating it.
Actually, if we don't mind about existing code, using the new "internal" (or
whatnot) qualifier in conjunction with an explicit default namespace for files
that are part of the package is probably almost enough. With the addition of a
"restrict" directive like in "restrict gets from foobar to foobar", it would be
enough.
Now we have to ponder whether we want to keep in check pre 4.0 code with rogue
globals or not. That's why external exclude or include lists were designed for.
Also, the proposal I had made had provisions for being able to still use "global"
all around, and packaging directives like with package= would take care of
translating "global" to exported or internal. If converting to the new rules is a
light enough mental burden, then that component is not needed either. I actually
would feel relieved if the global (no pun) mindset has become such that we only
care for compatibiiity at a reasonable level. Good news.
What we may need is a clear statement on how transition is managed and whether
it ever will; this may be the tougher issue, but it wil impact what features or
changes 4.0 can take.
One thing though: can't logical packages be conntained in one another? There
would be missing a way to specify that a package belongs to another.
Perhaps
-- triangle.e
namespace geometry,math
is enough, the issue then being to enforce some consistency between the multiple
packages. Or we may not care anyway.
CChris
108. Re: Do you currently use namespaces?
CChris wrote:
>
> gshingles wrote:
> >
> > I saw mention of a default namespace being created by the coder of the
> > include.
> > Well why not make the default namespace the name of the file, without .e[??]
> > at the end? Even better, why not work out its path relative to the EUINC
> > folder
> > it is in and make that the default namespace? Even even better (all IMHO of
> > course) provide a function that returns the name (or numeric id) of that
> > default
> > namespace?
> >
>
> For several reasons:
> * mylib_v1.e may become mylib_v2.e
I would expect containerised modules to be named sensibly, and probably not
contain version information, so that you could say:
include database.e
include database/mysql.e as mysql
include net/http/useragent.e
... and not have to particularly worry about what version you are including (I
mean, that's what documentation is for).
> * file names may contain invalid characters for an Euphoria identifier,
> including,
> worst of all, spaces;
Fair enough comment, though fairly easily ruled out with a bit of checking by
the include system. eg crash with an error saying "you can't name it that".
In Perl you name your module inside the file and woe betide you if the filename
does not match.
> * What is the name of fileA.e under Windows? Its short 8.3 name? its
> lowercased
> form? its uppercased form?
That's the best objection from your list, in my opinion. Systems like Perl grew
up in strict filesystem environment so it wasn't an issue and I'm not sure how
they deal with that in the Windows or DOS environment.
> * Having all of the above in mind, copy your library from one platform to
> another,
> and have fun.
Yes, another flaw in the idea is the path separation, but that's why Perl uses
'::' in place of '/' or '\' or ':'.
Please note, I'm not suggesting making Euphoria into Perl, but I started using
Perl at the end of version 4 and saw the evolution of its OO system into
something that is really simple, yet very flexible.
Another thing I hadn't thought of is how to call a method via an object, that
may require a new notation, and might rule it out as a viable system anyway
(since I was just thinking at the parsing level).
Gary
Gary
