1. . or : for namespace?
yuku wrote:
>
> My 1e-2 cents:
>
> I hate looking at ":" for the namespace specifier.
> It looks unclean (not easily distinguisable from a letter),
> hard to type, and not common. "_" is much cleaner...
>
> Any reason why didn't we use . instead of : ?
For the fun of it, I looked at parser.e and after adding 12 characters to the
code, . now works in addition to :...
include math.e as m
printf(1, "%.5f\n", {m.round_prec(10.2039212, 100)})
I am not committing this change, though, as it needs much discussion. I was just
playing. If, however, . is adopted, we could support both and give a warning that
: is deprecated.
Just thinking aloud.
--
Jeremy Cowgar
http://jeremy.cowgar.com
2. Re: . or : for namespace?
Jeremy Cowgar wrote:
>
> yuku wrote:
> >
> > My 1e-2 cents:
> >
> > I hate looking at ":" for the namespace specifier.
> > It looks unclean (not easily distinguisable from a letter),
> > hard to type, and not common. "_" is much cleaner...
> >
> > Any reason why didn't we use . instead of : ?
>
> For the fun of it, I looked at parser.e and after adding 12 characters to the
> code, . now works in addition to :...
>
> }}}
<eucode>
> include math.e as m
> printf(1, "%.5f\n", {m.round_prec(10.2039212, 100)})
> </eucode>
{{{
>
> I am not committing this change, though, as it needs much discussion. I was
> just playing. If, however, . is adopted, we could support both and give a
> warning
> that : is deprecated.
>
> Just thinking aloud.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
I'm okay with this. I was thinking why not to change from ":" to "." and the
main one was compatibility. Then the thought of using both came to mind.
I wonder how it would affect any future OO extensions to the language, though.
I need to look at the ooeu docs again to see how Matt handled it.
--
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.
3. Re: . or : for namespace?
- Posted by Greg Haberek <ghaberek at gmail?co?>
Apr 25, 2008
-
Last edited Apr 26, 2008
> For the fun of it, I looked at parser.e and after adding 12 characters to the
> code, . now works in addition to :...
>
> I am not committing this change, though, as it needs much discussion. I was
> just playing. If, however, . is adopted, we could support both and give a
> warning
> that : is deprecated.
>
> Just thinking aloud.
Honestly, I think . is a horrible idea. It's been consumed by the masses of
object-oriented programming. I personally would be confused as hell if . had a
different meaning in Euphoria as it did in a bunch of other languages.
-Greg
4. Re: . or : for namespace?
- Posted by c.k.lester <euphoric at ?kles?er.com>
Apr 25, 2008
-
Last edited Apr 26, 2008
Greg Haberek wrote:
>
> Honestly, I think . is a horrible idea. It's been consumed by the masses of
> object-oriented programming. I personally would be confused as hell if . had
> a different meaning in Euphoria as it did in a bunch of other languages.
Technically, it's not "a different meaning."
The dot means, "access the method of the parent." It's hierarchy-specific,
regardless of object orientation.
A datetime function namespaced and called like dt.now() is the exact same
interface result as a call to an object like dt.now(). The only thing that's
different is the behind-the-scenes processing.
5. Re: . or : for namespace?
c.k.lester wrote:
>
> Greg Haberek wrote:
> >
> > Honestly, I think . is a horrible idea. It's been consumed by the masses of
> > object-oriented programming. I personally would be confused as hell if . had
> > a different meaning in Euphoria as it did in a bunch of other languages.
>
> Technically, it's not "a different meaning."
>
> The dot means, "access the method of the parent." It's hierarchy-specific,
> regardless of object orientation.
>
> A datetime function namespaced and called like dt.now() is the exact same
> interface result as a call to an object like dt.now(). The only thing that's
> different is the behind-the-scenes processing.
Yes, but considering the existing uses of . it would be confusing. We'd
have to go through the whole thing of people trying to use individual include
files as classes.
Matt
6. Re: . or : for namespace?
7. Re: . or : for namespace?
I meant : not .
8. Re: . or : for namespace?
- Posted by Jeremy Cowgar <jeremy at c?wg?r.com>
Apr 29, 2008
-
Last edited Apr 30, 2008
I don't think we ever came to a decision on to use : or . as a namespace
delimiter.
It seems that the major of those not in favor of it are not in favor because of
it's use in an OO world. However, in an OO world, it is used also as a namespace
delimiter. i.e. java.lang.String and myString.trim().
Another argument against it is that we already use : and thus would break code.
From the code I've seen, I've rarely seen : being used. If it is used, it's easy
to search/replace that character. On top of that, we can not all of a sudden
cease to support : but we can support them both for a time, marking : as
deprecated.
The next argument against it is that if we use . for a namespace delimiter, then
we cannot use it for a future structured sequence? that we cannot seem to agree
what it should look like. However, again, . is used in other languages as the
namespace delimiter, object delimiter and structure delimiter as well w/o
problem, I see no reason why we cannot do the same:
include greeter.e as greet
-- greeting is a named/structure sequence in the greet namespace
greet.greeting.name = "World"
greet.greeting.message = "Hello"
-- call a function in the greet namespace
greet.greet()
I do not think this is confusing, and I believe most would also say it is not.
In fact, I think it's much easier to read than the alternative:
include greeter.e as greet
-- greeting is a named/structure sequence in the greet namespace
greet:greeting.name = "World"
greet:greeting.message = "Hello"
-- call a function in the greet namespace
greet:greet()
I already have the code to make this work. It was a very simple change (added 12
characters, that's all). What do we have to do to make a decision on : or . ? One
way or the other?
--
Jeremy Cowgar
http://jeremy.cowgar.com
9. Re: . or : for namespace?
- Posted by c.k.lester <euphoric at ckleste?.co?>
Apr 29, 2008
-
Last edited Apr 30, 2008
Jeremy Cowgar wrote:
>
> I don't think we ever came to a decision on to use : or .
I like the dot for everything. It's a single-finger keystroke and looks nice.
It can be used for structures, objects, etc... wherever there is a structure
of hierarchical data (like in your examples).
Caveat: I've never even used the ':' for namespacing, and the only place I've
seen it used extensively is Matt's code. Does Win32Lib use it? So, given this,
I really don't care if the dot is adopted for namespacing or not. I'm voting
my preference so that should I ever need it, I can use the friendly neighborhood
dot.
10. Re: . or : for namespace?
- Posted by Jeremy Cowgar <jeremy at ?owgar.?om>
Apr 29, 2008
-
Last edited Apr 30, 2008
c.k.lester wrote:
>
> I really don't care if the dot is adopted for namespacing or not. I'm voting
> my preference so that should I ever need it, I can use the friendly
> neighborhood
> dot.
You will start to use it in the new standard library, for instance:
include datetime.e as dt
include map.e as map
datetime dt1
dt1 = dt.now()
? dt.dow(dt1)
dt1 = dt.add(dt1, 55, DAYS)
map.map m
m = map.new()
m = map.put(m, "name", "C.K. Lester")
m = map.put(m, "favorite", ". namespace delimiter")
? map.get(m, "name")
--
Jeremy Cowgar
http://jeremy.cowgar.com
11. Re: . or : for namespace?
- Posted by c.k.lester <euphoric at ckl??ter.com>
Apr 29, 2008
-
Last edited Apr 30, 2008
Jeremy Cowgar wrote:
> c.k.lester wrote:
> > I really don't care if the dot is adopted for namespacing or not. I'm voting
> > my preference so that should I ever need it, I can use the friendly
> > neighborhood
> > dot.
> You will start to use it in the new standard library...
Yeah, you're probably right.
12. Re: . or : for namespace?
Jeremy Cowgar wrote:
>
> I don't think we ever came to a decision on to use : or . as a namespace
> delimiter.
>
> It seems that the major of those not in favor of it are not in favor because
> of it's use in an OO world. However, in an OO world, it is used also as a
> namespace
> delimiter. i.e. java.lang.String and myString.trim().
Meaning? That we should follow the Pied Piper of OO in this respect?
> Another argument against it is that we already use : and thus would break
> code.
> From the code I've seen, I've rarely seen : being used. If it is used, it's
> easy to search/replace that character. On top of that, we can not all of a
> sudden
> cease to support : but we can support them both for a time, marking : as
> deprecated.
If namespaces are rarely used then there is little point in making such a change
as only a few places will be affected. Besides, the system we now have works.
It's not broken so why try and fix it?
OTOH, perhaps you think namespaces will be used a lot more in the future. If
that's so perhaps it would be good for everyone to know that future coding will
require much more typing and be less readable.
> The next argument against it is that if we use . for a namespace delimiter,
> then we cannot use it for a future structured sequence? that we cannot seem
> to agree what it should look like. However, again, . is used in other
> languages
> as the namespace delimiter, object delimiter and structure delimiter as well
> w/o problem,
I think dot-notation for sequence access is a good thing and that the majority
of users would agree, in fact, expect it to happen. However, this will produce
a semantic anomaly if . is used as the namespace delimiter, eg:
a.b.c
What does this mean? If I have just written the code, I know exactly. If I had
to read 3rd party code or my own code 6 months later, I don't know without
further
investigation. Is it simply a sequence access or is it a namespaced sequence
access?
Why not leave the status quo as is and preserve the semantic distinctions?
> However, again, . is used in other languages
> as the namespace delimiter, object delimiter and structure delimiter as well
> w/o problem, I see no reason why we cannot do the same:
>
> }}}
<eucode>
> include greeter.e as greet
>
> -- greeting is a named/structure sequence in the greet namespace
> greet.greeting.name = "World"
> greet.greeting.message = "Hello"
>
> -- call a function in the greet namespace
> greet.greet()
> </eucode>
{{{
>
> I do not think this is confusing, and I believe most would also say it is not.
> In fact, I think it's much easier to read than the alternative:
>
> }}}
<eucode>
> include greeter.e as greet
>
> -- greeting is a named/structure sequence in the greet namespace
> greet:greeting.name = "World"
> greet:greeting.message = "Hello"
>
> -- call a function in the greet namespace
> greet:greet()
> </eucode>
{{{
I have to agree that it is easier to read. However, as demostrated above,
it's also less understandable. If reading it is a problem why not just
make your editor display the colon in a different colour? Or put a space after
the colon?
> I already have the code to make this work. It was a very simple change (added
> 12 characters, that's all). What do we have to do to make a decision on : or
> . ? One way or the other?
>
> Jeremy Cowgar
It might have been a simple change but only because it's a low-hanging fruit.
It is just a cosmetic change whose programming merits are debateable. You are
obviously a good programmer, but let's face it, this question was only raised
mere days ago. Why not tackle more fundamental problems that have plagued
Euphoria for years which noone will challenge you on when you solve them?
Like what?
Dot Notation for sequences
Foreach construct
Optional routine parameters
Shorthands for integer, sequence, object (int, seq, obj)
Conditional compilation
genuine 32 bits for integers
Incidentally, all these (bar last one) and more have already been incorporated
into Orac.
regards,
Mike (creator of Orac)
13. Re: . or : for namespace?
Mike wrote:
>
> Jeremy Cowgar wrote:
> >
> > The next argument against it is that if we use . for a namespace delimiter,
> > then we cannot use it for a future structured sequence? that we cannot seem
> > to agree what it should look like. However, again, . is used in other
> > languages as the namespace delimiter, object delimiter and structure
> > delimiter as well w/o problem,
>
> I think dot-notation for sequence access is a good thing and that the majority
> of users would agree, in fact, expect it to happen. However, this will produce
> a semantic anomaly if . is used as the namespace delimiter, eg:
>
> a.b.c
>
> What does this mean? If I have just written the code, I know exactly. If I
> had to read 3rd party code or my own code 6 months later, I don't know
> without further investigation. Is it simply a sequence access or is it a
> namespaced sequence access?
Yes, I still think that this is the strongest argument against changing to
the dot. Other languages may do this, but that doesn't mean that it's a
good idea for euphoria. There are other things that some languages allow,
which also promote errors, such as:
if( x = foo()) -- assignment x = foo(), and test the value of x
-- vs
if( x == foo()) -- test value of x against return value of foo()
Structured data access (with whatever extra OO flavors) is probably the next
evolutionary stage of euphoria.
Matt
14. Re: . or : for namespace?
c.k.lester wrote:
>
> Jeremy Cowgar wrote:
> >
> > I don't think we ever came to a decision on to use : or .
>
> I like the dot for everything. It's a single-finger keystroke and looks nice.
> It can be used for structures, objects, etc... wherever there is a structure
> of hierarchical data (like in your examples).
>
> Caveat: I've never even used the ':' for namespacing, and the only place I've
> seen it used extensively is Matt's code. Does Win32Lib use it? So, given this,
> I really don't care if the dot is adopted for namespacing or not. I'm voting
> my preference so that should I ever need it, I can use the friendly
> neighborhood
> dot.
Some include files in win32lib use the include...as form, notably series.e.
There is no internal reason to do that, just the name clash protection issue, so
I left it in as harmless.
As for whether to use . or :, I'll abstain. . is more commonplace, but : is easy
(perhaps 10% easier) to type, so it hardly matters.
CChris
15. Re: . or : for namespace?
Jeremy Cowgar wrote:
>
> I don't think we ever came to a decision on to use : or . as a namespace
> delimiter.
Please keep ":" as the namespace delimiter. By using this it reduces visual
ambiguity and should make parsing the source easier too. A namespace is quite
different from a 'struct' name, and so they ought to be visually seen as
different too.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
16. Re: . or : for namespace?
I hate to bring this topic back up, I removed my code from SVN (it committed as
a comment) that supports the . namespace prefix in addition to :. However, when I
did so, multiple people now have asked me why? I was not the originator of this
idea, I just posted it here.
So, the comments are from my changelog message stating the "debate of : and . is
dead, removing . support comment" Question was, why is it dead? Now another
comment about : vs. . was brought up to me stating, no one against the dot had a
good reason, did they?
So, I am going to answer that here and with comments that follow I hope to bring
the discussion to a close.
Previous arguments were summarized in my post:
http://www.openeuphoria.org/EUforum/m20221.html
Now, following up with that there was another, new complaint, against the . idea
and that was by Mike and Matt agreed. I somewhat agree but would still be in
favor of the . but, this is just something we need to work through until a final
decision has been made.
Their comment was that when the see a : in code that they wrote 6 months or 2
years ago that they will know it's a namespace and therefore the function is in
another location. That they will be able to tell that right away. However, maybe
in 2 years we will have dot'ed sequence access (whatever that will look like) and
then you will not know without research if greeter.greeting = "Hello" is
assigning a variable name greeting inside of the greeter namespace or if greeter
is possibly a sequence.
So, please read my prior post about the complaints against . and then the above
and let's have another round of discussion please. If you are in favor or against
it, please post your comments.
Let me also point out that we are focusing a lot on the negatives and people who
bring about points that are negative. There are many who want the . and think
it's much clearer. Now, in the end we are all working together to make Euphoria
better for us all. That's the goal, let's keep that in mind.
--
Jeremy Cowgar
http://jeremy.cowgar.com
17. Re: . or : for namespace?
Jeremy Cowgar wrote:
>
> Their comment was that when the see a : in code that they wrote 6 months or
> 2 years ago that they will know it's a namespace and therefore the function
> is in another location. That they will be able to tell that right away.
> However,
> maybe in 2 years we will have dot'ed sequence access (whatever that will look
> like) and then you will not know without research if greeter.greeting =
> "Hello"
> is assigning a variable name greeting inside of the greeter namespace or if
> greeter is possibly a sequence.
This is a reasonable argument, but made moot when Matt finishes wxIDE (soon?),
because when you hover over a variable or dotted identifier, it gives a
tooltip telling you what exactly it is (namespace var, object, etc.) and
where it is defined (my_lib.e, your_lib.e). Well, that was on the roadmap
last time I looked. :D
The argument FOR a dot is that it takes one simple keystroke with one finger,
while the colon takes two fingers- that just sounded wrong. Plus, the dot
looks nicer and doesn't disrupt code scanning.
If the use of ':' was going to be significant, then I would say drop it and
use the dot. But, since I suspect it won't be- or can somebody show different-
keep the colon. Why not let the dot be a synonym? In the future, if it is
ever to be used for structures/sequences, the interpreter only need do this:
if find dot then
if is namespace thingie then
do namespace processing
else
do structure/sequence processing
end if
end if
As you can see, I remain somewhat ambivalent.
18. Re: . or : for namespace?
c.k.lester wrote:
>
> If the use of ':' was going to be significant, then I would say drop it and
> use the dot. But, since I suspect it won't be- or can somebody show different-
> keep the colon.
>
The use of : is going to ***greatly*** increase w/4.0 release, and it should.
include map.e as map
include datetime.e as dt
include stack.e as sk
map:map m
dt:datetime dt1
sk:stack s
m = map:new()
dt1 = dt:new(2008, ...)
s = sk:new(sk:FIFO)
s = sk:push(s, 10)
dt1 = dt:add(dt1, 10, dt:DAYS)
m = map:put(m, "name", "John")
puts(1, map:get(m, "name"))
vs
include map.e as map
include datetime.e as dt
include stack.e as sk
map.map m
dt.datetime dt1
sk.stack s
m = map.new()
dt1 = dt.new(2008, ...)
s = sk.new(sk.FIFO)
s = sk.push(s, 10)
dt1 = dt.add(dt1, 10, dt.DAYS)
m = map.put(m, "name", "John")
puts(1, map.get(m, "name"))
Other places you will use it also and once people start to see it's use and
benefit in the standard library, their libraries will begin to use it as well,
for instance a new DBI I am working on (PgSQL already working).
--
Jeremy Cowgar
http://jeremy.cowgar.com
19. Re: . or : for namespace?
Jeremy Cowgar wrote:
> c.k.lester wrote:
> > If the use of ':' was going to be significant, then I would say drop it and
> > use the dot. But, since I suspect it won't be- or can somebody show
> > different-
> > keep the colon.
> The use of : is going to ***greatly*** increase w/4.0 release, and it should.
So, when typing out all that code, didn't you like using the dot better
than the colon? ;)
> for instance a new DBI I am working on (PgSQL already working).
That is awesome. I will definitely try some of that. :)
20. Re: . or : for namespace?
c.k.lester wrote:
>
> Jeremy Cowgar wrote:
> > c.k.lester wrote:
> > > If the use of ':' was going to be significant, then I would say drop it
> > > and
> > > use the dot. But, since I suspect it won't be- or can somebody show
> > > different-
> > > keep the colon.
> > The use of : is going to ***greatly*** increase w/4.0 release, and it
> > should.
>
> So, when typing out all that code, didn't you like using the dot better
> than the colon? ;)
I am in favor of . ... Yes, typing that little amount of code out using : is
cumbersome. I've had problems with my hands in the past and it was linked mainly
to using the shift keys with my pinkies. I have foot pedals now for Control,
Alternate and Shift but do not use them most of the time as even after much
practice, they are not as fast. Just too much travel.
--
Jeremy Cowgar
http://jeremy.cowgar.com
21. Re: . or : for namespace?
- Posted by Derek Parnell <ddparnell at big?ond.co?>
May 05, 2008
-
Last edited May 06, 2008
Jeremy Cowgar wrote:
> Now, following up with that there was another, new complaint, against the .
> idea and that was by Mike and Matt agreed.
My original obection was much the same too, by the way.
> Their comment was that when the see a : in code that they wrote 6 months or
> 2 years ago that they will know it's a namespace and therefore the function
> is in another location. That they will be able to tell that right away.
> However,
> maybe in 2 years we will have dot'ed sequence access (whatever that will look
> like) and then you will not know without research if greeter.greeting =
> "Hello"
> is assigning a variable name greeting inside of the greeter namespace or if
> greeter is possibly a sequence.
The main purpose of a programming language is to help people read programs. The
two important words are "read" and "people".
> So, please read my prior post about the complaints against . and then the
> above
> and let's have another round of discussion please. If you are in favor or
> against
> it, please post your comments.
Please retain ":" as the namespace delimiter.
The colon provides an unambiguous visual clue for people reading source as to
how they should understand the identifier preceding it. Remember that an
intelligent editor is not the only way that source code will be presented to a
person, so tooltips and colorization assists must not be assumed to be always
present.
Without knowledge gained from other arts of a source code file, the following
statement is visually ambiguous...
if foo.bar = 1
What is 'foo'?
if foo:bar = 1
Now it is obvious that 'bar' is declared in another source file.
The argument with respect to ease of typing can also be applied to other often
used Euphoria syntax elements, such as the double-quote, tilde, dollar and
brace-pair, not to mention the widely used '<', '>', '(', ')', and '%'
characters. But that argument isn't actively used against these characters so why
use it against ':'?
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
22. Re: . or : for namespace?
- Posted by Mike <vulcan at wi??co.nz>
May 05, 2008
-
Last edited May 06, 2008
Hey Jeremy,
Jeremy Cowgar wrote:
-- snip
> Previous arguments were summarized in my post:
>
> <a
> href="http://www.openeuphoria.org/EUforum/m20221.html">http://www.openeuphoria.org/EUforum/m20221.html</a>
>
> Now, following up with that there was another, new complaint, against the .
> idea and that was by Mike and Matt agreed. I somewhat agree but would still
> be in favor of the . but, this is just something we need to work through until
> a final decision has been made.
>
> Their comment was that when the see a : in code that they wrote 6 months or
> 2 years ago that they will know it's a namespace and therefore the function
> is in another location. That they will be able to tell that right away.
> However,
> maybe in 2 years we will have dot'ed sequence access (whatever that will look
> like) and then you will not know without research if greeter.greeting =
> "Hello"
> is assigning a variable name greeting inside of the greeter namespace or if
> greeter is possibly a sequence.
>
> So, please read my prior post about the complaints against . and then the
> above
> and let's have another round of discussion please. If you are in favor or
> against
> it, please post your comments.
>
> Let me also point out that we are focusing a lot on the negatives and people
> who bring about points that are negative. There are many who want the . and
> think it's much clearer. Now, in the end we are all working together to make
> Euphoria better for us all. That's the goal, let's keep that in mind.
That's true.
I personally think that . is clearer, that is, until dot notation becomes
available
for sequence access (or even, *structure* access, yeah..) and then we introduce
ambiguities. Forget 2 years, or even 6 months, problems with one's own code will
surface
in mere weeks.
Now, here is an example of how silly it can get:
include file.x as b
sequence a
..
a.b.c
What does this mean? it really means <drum roll> a . b:c
!GASP!
If the dot is used for namespaces, sequence access, also using dots, will be
fraught
with such perils.
If there is to be *any* hope of using dot notation generally, I would really
love to
see someone try and explain away the above example.
I am sure there will be people who would prefer to use . as namespace but they
would also
like to use . for sequence access. Insisting on the former will jeopardize the
latter.
or am I mistaken about this?
regards,
Mike
23. Re: . or : for namespace?
- Posted by "Euler German" <eulerg at gmail.com>
May 05, 2008
-
Last edited May 06, 2008
> On 5 May 2008 at 15:07, Derek Parnell wrote (maybe snipped):
> Without knowledge gained from other arts of a source code file, the
> following statement is visually ambiguous...
>
> if foo.bar = 1
>
> What is 'foo'?
>
> if foo:bar = 1
>
> Now it is obvious that 'bar' is declared in another source file.
>
> The argument with respect to ease of typing can also be applied to
> other often used Euphoria syntax elements, such as the double-quote,
> tilde, dollar and brace-pair, not to mention the widely used '<', '>',
> '(', ')', and '%' characters. But that argument isn't actively used
> against these characters so why use it against ':'?
>
Derek's "disambiguation" made a point here. So, I'm about to change
my vote for the dot. It was a conditional vote, anyway. ;)
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
24. Re: . or : for namespace?
- Posted by c.k.lester <euphoric at cklester?c?m>
May 05, 2008
-
Last edited May 06, 2008
Euler German wrote:
>
>
> Derek's "disambiguation" made a point here. So, I'm about to change
> my vote for the dot. It was a conditional vote, anyway. ;)
What about cases that give us this:
a.b:c:d.e.f:g.h = "WTF?"
25. Re: . or : for namespace?
- Posted by ChrisBurch3 <crylex at ?mai?.com>
May 05, 2008
-
Last edited May 06, 2008
Derek Parnell wrote:
>
> Jeremy Cowgar wrote:
>
> > Now, following up with that there was another, new complaint, against the .
> > idea and that was by Mike and Matt agreed.
>
> My original obection was much the same too, by the way.
>
> > Their comment was that when the see a : in code that they wrote 6 months or
> > 2 years ago that they will know it's a namespace and therefore the function
> > is in another location. That they will be able to tell that right away.
> > However,
> > maybe in 2 years we will have dot'ed sequence access (whatever that will
> > look
> > like) and then you will not know without research if greeter.greeting =
> > "Hello"
> > is assigning a variable name greeting inside of the greeter namespace or if
> > greeter is possibly a sequence.
>
>
> The main purpose of a programming language is to help people read programs.
> The two important words are "read" and "people".
>
> > So, please read my prior post about the complaints against . and then the
> > above
> > and let's have another round of discussion please. If you are in favor or
> > against
> > it, please post your comments.
>
>
> Please retain ":" as the namespace delimiter.
>
>
> The colon provides an unambiguous visual clue for people reading source as to
> how they should understand the identifier preceding it. Remember that an
> intelligent
> editor is not the only way that source code will be presented to a person, so
> tooltips and colorization assists must not be assumed to be always present.
>
> Without knowledge gained from other arts of a source code file, the following
> statement is visually ambiguous...
>
> if foo.bar = 1
>
> What is 'foo'?
>
> if foo:bar = 1
>
> Now it is obvious that 'bar' is declared in another source file.
>
> The argument with respect to ease of typing can also be applied to other often
> used Euphoria syntax elements, such as the double-quote, tilde, dollar and
> brace-pair,
> not to mention the widely used '<', '>', '(', ')', and '%' characters.
> But that argument isn't actively used against these characters so why use it
> against ':'?
>
I agree with this - keep : for namespace signalling
Chris
26. Re: . or : for namespace?
- Posted by Bernie Ryan <xotron at bluefrog.?o?>
May 05, 2008
-
Last edited May 06, 2008
ChrisBurch3 wrote:
>
> Derek Parnell wrote:
> >
> > Jeremy Cowgar wrote:
> >
> > > Now, following up with that there was another, new complaint, against the
> > > .
> > > idea and that was by Mike and Matt agreed.
> >
> > My original obection was much the same too, by the way.
> >
> > > Their comment was that when the see a : in code that they wrote 6 months
> > > or
> > > 2 years ago that they will know it's a namespace and therefore the
> > > function
> > > is in another location. That they will be able to tell that right away.
> > > However,
> > > maybe in 2 years we will have dot'ed sequence access (whatever that will
> > > look
> > > like) and then you will not know without research if greeter.greeting =
> > > "Hello"
> > > is assigning a variable name greeting inside of the greeter namespace or
> > > if
> > > greeter is possibly a sequence.
> >
> >
> > The main purpose of a programming language is to help people read programs.
> > The two important words are "read" and "people".
> >
> > > So, please read my prior post about the complaints against . and then the
> > > above
> > > and let's have another round of discussion please. If you are in favor or
> > > against
> > > it, please post your comments.
> >
> >
> > Please retain ":" as the namespace delimiter.
> >
> >
> > The colon provides an unambiguous visual clue for people reading source as
> > to
> > how they should understand the identifier preceding it. Remember that an
> > intelligent
> > editor is not the only way that source code will be presented to a person,
> > so
> > tooltips and colorization assists must not be assumed to be always present.
> >
> > Without knowledge gained from other arts of a source code file, the
> > following
> > statement is visually ambiguous...
> >
> > if foo.bar = 1
> >
> > What is 'foo'?
> >
> > if foo:bar = 1
> >
> > Now it is obvious that 'bar' is declared in another source file.
> >
> > The argument with respect to ease of typing can also be applied to other
> > often
> > used Euphoria syntax elements, such as the double-quote, tilde, dollar and
> > brace-pair,
> > not to mention the widely used '<', '>', '(', ')', and '%' characters.
> > But that argument isn't actively used against these characters so why use it
> > against ':'?
> >
>
> I agree with this - keep : for namespace signalling
>
I agree with this - keep : for namespace signalling
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
27. Re: . or : for namespace?
> On 5 May 2008 at 15:59, c.k.lester wrote (maybe snipped):
> Euler German wrote:
> >
> >
> > Derek's "disambiguation" made a point here. So, I'm about to change
> > my vote for the dot. It was a conditional vote, anyway. ;)
>
> What about cases that give us this:
>
> a.b:c:d.e.f:g.h = "WTF?"
>
Lousy coding? ;)
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
28. Re: . or : for namespace?
Hi CK,
c.k.lester wrote:
>
> Euler German wrote:
> >
> >
> > Derek's "disambiguation" made a point here. So, I'm about to change
> > my vote for the dot. It was a conditional vote, anyway. ;)
>
> What about cases that give us this:
>
> a.b:c:d.e.f:g.h = "WTF?"
Are you joking here..? No, that would never be, so...
I think you made a mistake with "b:c:d" I'll assume it would have been "b:c.d"
: binds more closely than . and is always only ever paired, never stacked,
so, it's completely unambiguous as:
a . b:c . d . e . f:g . h
the alternatives using dotted namespace would be either :
a [ b.c ] [ d ] [ e ] [ f.g ] [ h ]
or :
int tmp = b.c
int tmp2 = f.g
a . tmp . d . e . tmp2 . h
regards,
Mike
29. Re: . or : for namespace?
Mike wrote:
> Now, here is an example of how silly it can get:
>
> include file.x as b
> sequence a
> ..
>
> a.b.c
>
> What does this mean? it really means <drum roll> a . b:c
But what can that really mean? Does it mean that c is a constant in namespace b
and a.b:c means the same as a[b:c] ?
30. Re: . or : for namespace?
yuku wrote:
>
> Mike wrote:
> > Now, here is an example of how silly it can get:
> >
> > include file.x as b
> > sequence a
> > ..
> >
> > a.b.c
> >
> > What does this mean? it really means <drum roll> a . b:c
>
> But what can that really mean? Does it mean that c is a constant in namespace
> b
It could be a constant or variable
> and a.b:c means the same as a[b:c] ?
Yes.
The point was that it *could* (without further investigation) also be
a:b [ c ]
which is the whole point - nobody knows what's going on.
Mike
31. Re: . or : for namespace?
> > > What does this mean? it really means <drum roll> a . b:c
> >
> > But what can that really mean? Does it mean that c is a constant in
> > namespace
> > b
>
> It could be a constant or variable
>
> > and a.b:c means the same as a[b:c] ?
>
> Yes.
So what you mean is maybe sometime in the future, . can be used
as a shorthand for [] ?
So we will be able to do
a = {10,20,30}
a.2 = 50
print(a.3)
?
32. Re: . or : for namespace?
Mike wrote:
>
>
> Hey Jeremy,
>
> Jeremy Cowgar wrote:
>
> -- snip
>
> > Previous arguments were summarized in my post:
> >
> > <a
> > href="http://www.openeuphoria.org/EUforum/m20221.html">http://www.openeuphoria.org/EUforum/m20221.html</a>
> >
> > Now, following up with that there was another, new complaint, against the .
> > idea and that was by Mike and Matt agreed. I somewhat agree but would still
> > be in favor of the . but, this is just something we need to work through
> > until
> > a final decision has been made.
> >
> > Their comment was that when the see a : in code that they wrote 6 months or
> > 2 years ago that they will know it's a namespace and therefore the function
> > is in another location. That they will be able to tell that right away.
> > However,
> > maybe in 2 years we will have dot'ed sequence access (whatever that will
> > look
> > like) and then you will not know without research if greeter.greeting =
> > "Hello"
> > is assigning a variable name greeting inside of the greeter namespace or if
> > greeter is possibly a sequence.
> >
> > So, please read my prior post about the complaints against . and then the
> > above
> > and let's have another round of discussion please. If you are in favor or
> > against
> > it, please post your comments.
> >
> > Let me also point out that we are focusing a lot on the negatives and people
> > who bring about points that are negative. There are many who want the . and
> > think it's much clearer. Now, in the end we are all working together to make
> > Euphoria better for us all. That's the goal, let's keep that in mind.
>
> That's true.
>
> I personally think that . is clearer, that is, until dot notation becomes
> available
> for sequence access (or even, *structure* access, yeah..) and then we
> introduce
> ambiguities. Forget 2 years, or even 6 months, problems with one's own code
> will surface
> in mere weeks.
>
> Now, here is an example of how silly it can get:
>
> include file.x as b
> sequence a
> ..
>
> a.b.c
>
> What does this mean? it really means <drum roll> a . b:c
>
> !GASP!
>
> If the dot is used for namespaces, sequence access, also using dots, will be
> fraught
> with such perils.
>
> If there is to be *any* hope of using dot notation generally, I would really
> love to
> see someone try and explain away the above example.
>
> I am sure there will be people who would prefer to use . as namespace but they
> would also
> like to use . for sequence access. Insisting on the former will jeopardize the
> latter.
>
> or am I mistaken about this?
>
>
> regards,
> Mike
I'm not getting your point.
A namespace delineates a chunk of code (currently, that must be an entire file
(sigh)) in which some identifiers are.
In structured access for sequence, the structure type delineates a chunk of code
(the field list declaration) in which some identifiers are.
Why does the difference matter?
CChris
33. Re: . or : for namespace?
CChris wrote:
>
> Mike wrote:
> >
-- snip
> > Now, here is an example of how silly it can get:
> >
> > include file.x as b
> > sequence a
> > ..
> >
> > a.b.c
> >
> > What does this mean? it really means <drum roll> a . b:c
> >
> > !GASP!
> >
> > If the dot is used for namespaces, sequence access, also using dots, will be
> > fraught
> > with such perils.
> >
> > If there is to be *any* hope of using dot notation generally, I would really
> > love to
> > see someone try and explain away the above example.
> >
> > I am sure there will be people who would prefer to use . as namespace but
> > they
> > would also
> > like to use . for sequence access. Insisting on the former will jeopardize
> > the
> > latter.
> >
> > or am I mistaken about this?
> >
> >
> > regards,
> > Mike
>
> I'm not getting your point.
>
> A namespace delineates a chunk of code (currently, that must be an entire file
> (sigh)) in which some identifiers are.
> In structured access for sequence, the structure type delineates a chunk of
> code (the field list declaration) in which some identifiers are.
>
> Why does the difference matter?
>
> CChris
It potentially attracts major obsfucation, eg:
a.b.c.d could mean..
a[b][c][d] or a:b[c][d] or a[b:c][d] or a[b][c:d] or a:b[c:d]
It is true that, technically, such a system could work because the compiler has
enough info to figure it all out. But, we're not machines.
This example assumes that we are accessing Euphoria sequences and that we really
want to have the freedom to put namespace references anywhere in the dot-chain,
not just a single one right at the head of the dot-chain. And even then,
ambiguity
remains, eg..
a.b.c.d could mean..
a[b][c][d] or a:b[c][d]
However, things appear less problematic for future genuine (C) structures,
because,
as you point out, the field declarations are specified. Nevertheless, there may
be
instances where it would be useful to mix structure fields and normal variables
(which may include namespaced references) along the same dot-chain. Some
structures
contain arrays. Wouldn't it great to be able to iterate over such a thing using
a
for loop? Eg:
struct complex
double real
double img
end struct
struct any
list complex[256]
end struct
any ptr = address()
for i = 1 to 256 do
ptr.i.real = whatever_real()
ptr.i.img = 0.0
end for
So, basically we have :
obsfucation OR lack of freedom + nice looking
vs
clarity + freedom - looks
(the freedom referred to is a future freedom affected by design decisions being
made now)
regards,
Mike
PS: I hope my examples are clear enough
34. Re: . or : for namespace?
Mike wrote:
>
> CChris wrote:
> >
> > Mike wrote:
> > >
> -- snip
> > > Now, here is an example of how silly it can get:
> > >
> > > include file.x as b
> > > sequence a
> > > ..
> > >
> > > a.b.c
> > >
> > > What does this mean? it really means <drum roll> a . b:c
> > >
> > > !GASP!
> > >
> > > If the dot is used for namespaces, sequence access, also using dots, will
> > > be
> > > fraught
> > > with such perils.
> > >
> > > If there is to be *any* hope of using dot notation generally, I would
> > > really
> > > love to
> > > see someone try and explain away the above example.
> > >
> > > I am sure there will be people who would prefer to use . as namespace but
> > > they
> > > would also
> > > like to use . for sequence access. Insisting on the former will jeopardize
> > > the
> > > latter.
> > >
> > > or am I mistaken about this?
> > >
> > >
> > > regards,
> > > Mike
> >
> > I'm not getting your point.
> >
> > A namespace delineates a chunk of code (currently, that must be an entire
> > file
> > (sigh)) in which some identifiers are.
> > In structured access for sequence, the structure type delineates a chunk of
> > code (the field list declaration) in which some identifiers are.
> >
> > Why does the difference matter?
> >
> > CChris
>
> It potentially attracts major obsfucation, eg:
>
> a.b.c.d could mean..
>
> a[b][c][d] or a:b[c][d] or a[b:c][d] or a[b][c:d] or a:b[c:d]
>
> It is true that, technically, such a system could work because the compiler
> has
> enough info to figure it all out. But, we're not machines.
>
> This example assumes that we are accessing Euphoria sequences and that we
> really
> want to have the freedom to put namespace references anywhere in the
> dot-chain,
> not just a single one right at the head of the dot-chain. And even then,
> ambiguity
> remains, eg..
>
> a.b.c.d could mean..
>
> a[b][c][d] or a:b[c][d]
>
>
> However, things appear less problematic for future genuine (C) structures,
> because,
> as you point out, the field declarations are specified. Nevertheless, there
> may be
> instances where it would be useful to mix structure fields and normal
> variables
> (which may include namespaced references) along the same dot-chain. Some
> structures
> contain arrays. Wouldn't it great to be able to iterate over such a thing
> using
> a
> for loop? Eg:
>
> struct complex
> double real
> double img
> end struct
>
> struct any
> list complex[256]
> end struct
>
> any ptr = address()
>
> for i = 1 to 256 do
> ptr.i.real = whatever_real()
> ptr.i.img = 0.0
> end for
>
>
> So, basically we have :
>
> obsfucation OR lack of freedom + nice looking
>
Where?
Namespaces are not that many. Do you mean you don't know which identifier is a
namespace? Really?
CChris
> vs
>
> clarity + freedom - looks
>
>
> (the freedom referred to is a future freedom affected by design decisions
> being
> made now)
>
> regards,
> Mike
>
> PS: I hope my examples are clear enough
35. Re: . or : for namespace?
CChris wrote:
>
>
> Where?
> Namespaces are not that many. Do you mean you don't know which identifier is
> a namespace? Really?
This is a very good point. Who is going to make a structure that looks like:
a.b.c.d.e = "John"
If you do, you deserve to be confused when you go back and look at your code.
Here's a realistic example:
include datetime.e as dt
struct emp
emp.name.last = "Doe"
emp.name.first = "John"
emp.age = 35
emp.dob = dt.new(1965, 10, 5, 0, 0, 0)
Anyone can create a convoluted example such as:
a.b.c:d.o.z.a.z.x.i.o:g = 12
but who's going to do that? Fact of the matter is your going to use the same
namespaces all the time. For instance:
include stack.e as sk
include map.e as map
include datetime.e as dt
include set.e as set
This all seems pretty easy to me.
--
Jeremy Cowgar
http://jeremy.cowgar.com
36. Re: . or : for namespace?
CChris wrote:
>
> Mike wrote:
> >
> > So, basically we have :
> >
> > obsfucation OR lack of freedom + nice looking
> >
>
> Where?
> Namespaces are not that many. Do you mean you don't know which identifier is
> a namespace? Really?
And 640K should be enough for anyone. Seriously, you can't imagine a case
where there might be a namespace and a variable whose names collide?
While we're at it, why don't we get rid of parentheses and just use square
brackets everywhere?
puts[1, "Hello, world!\n"]
Matt
37. Re: . or : for namespace?
Matt Lewis wrote:
>
> And 640K should be enough for anyone. Seriously, you can't imagine a case
> where there might be a namespace and a variable whose names collide?
>
That should err out, right?
include misc.e as m
sequence m
m = 10
a name is expected here
sequence m
--
Jeremy Cowgar
http://jeremy.cowgar.com
38. Re: . or : for namespace?
Jeremy Cowgar wrote:
>
> Matt Lewis wrote:
> >
> > And 640K should be enough for anyone. Seriously, you can't imagine a case
> > where there might be a namespace and a variable whose names collide?
> >
>
> That should err out, right?
>
> }}}
<eucode>
> include misc.e as m
>
> sequence m
> m = 10
> </eucode>
{{{
>
> a name is expected here
> sequence m
No, because this doesn't look like a namespace. But if we assume that
we can use a dot for sequence access:
include foo.e as m
integer m, n
m = 1
n = 3
sequence s
s = { {1,2,3,4}, {5,6,7,8}, {9,10,11,12} }
? s.m -- {1,2,3,4}
? s.m:n -- {5,6,7,8}
? s.m.n -- either {5,6,7,8} *or* 3
-- foo.e
global integer n
n = 2
So, what does s.m.n mean? It could mean either s[1][3] or s[2]. I
suppose that we could disallow using a fully qualified reference with the
dot notation. Frankly, I'm not big on this sort of dot notation, either.
I don't see anything wrong with using square brackets.
I think the dot notation would be best reserved for implementing some sort
of structured access/OO.
Matt
39. Re: . or : for namespace?
- Posted by Jeremy Cowgar <jeremy at cow?ar?com>
May 06, 2008
-
Last edited May 07, 2008
Matt Lewis wrote:
>
> > That should err out, right?
> >
> > }}}
<eucode>
> > include misc.e as m
> >
> > sequence m
> > m = 10
> > </eucode>
{{{
> >
> > a name is expected here
> > sequence m
>
> No, because this doesn't look like a namespace.
Matt,
The above *does* err out. That error message is pasted from the actual output of
that program.
> But if we assume that we can use a dot for sequence access:
> }}}
<eucode>
> include foo.e as m
>
> integer m, n
> m = 1
> n = 3
> sequence s
> s = { {1,2,3,4}, {5,6,7,8}, {9,10,11,12} }
>
> ? s.m -- {1,2,3,4}
> ? s.m:n -- {5,6,7,8}
> ? s.m.n -- either {5,6,7,8} *or* 3
>
> -- foo.e
> global integer n
> n = 2
> </eucode>
{{{
This will not work. m is a namespace, you cannot have integer m, and that's
current code.
Now, also, please see my post:
http://www.openeuphoria.org/EUforum/m20548.html
That will address the above example a little more.
> So, what does s.m.n mean? It could mean either s[1][3] or s[2]. I
> suppose that we could disallow using a fully qualified reference with the
> dot notation. Frankly, I'm not big on this sort of dot notation, either.
> I don't see anything wrong with using square brackets.
>
> I think the dot notation would be best reserved for implementing some sort
> of structured access/OO.
>
Let's dive into the example. Let's say we do have dotted structure access. What
is it going to access? In your example above:
? s.m:n -- {5,6,7,8}
When reading this with . for structure and : for namespace.
"s" is a variable of some sort. Now, a variable can contain a namespace? That
doesn't make sense. You are accessing a variable, so inside the structure, there
can be multiple "n" variables that you have to prefix them with a namespace? That
would mean:
? s.m:n -- {5,6,7,8}
? s.n:n -- {6,7,8,9}
? s.l:n -- {7,8,9,10}
How will that actually work? I'm not certain it makes sense to even allow that
to work. How you you define the structure s?
struct s
s = { namespace m { n, o, p },
namespace n { n, o, p },
namespace o { n, o, p } }
And if you could do that, I think it's a terrible thing. What purpose could it
possibly solve? I may be totally wrong. If so, please give me an example.
--
Jeremy Cowgar
http://jeremy.cowgar.com
40. Re: . or : for namespace?
- Posted by Matt Lewis <matthewwalkerlewis at g?ai?.com>
May 06, 2008
-
Last edited May 07, 2008
Jeremy Cowgar wrote:
>
> The above *does* err out. That error message is pasted from the actual output
> of that program.
That's what I get for not testing. Thinking about it, though, it does make
sense, because the namespace is a symbol in the same scope as m.
> Now, also, please see my post:
>
> http://www.openeuphoria.org/EUforum/m20548.html
>
> That will address the above example a little more.
I think you meant m20546? Unless you've changed your name...
>
> > So, what does s.m.n mean? It could mean either s[1][3] or s[2]. I
> > suppose that we could disallow using a fully qualified reference with the
> > dot notation. Frankly, I'm not big on this sort of dot notation, either.
> > I don't see anything wrong with using square brackets.
> >
> > I think the dot notation would be best reserved for implementing some sort
> > of structured access/OO.
> >
>
> Let's dive into the example. Let's say we do have dotted structure access.
> What
> is it going to access? In your example above:
>
> }}}
<eucode>
> ? s.m:n -- {5,6,7,8}
> </eucode>
{{{
>
> When reading this with . for structure and : for namespace.
>
> "s" is a variable of some sort. Now, a variable can contain a namespace? That
> doesn't make sense. You are accessing a variable, so inside the structure,
> there
> can be multiple "n" variables that you have to prefix them with a namespace?
> That would mean:
There's a lot to hash out about what dotted access might mean. Some have
used a dot as syntactic sugar for enclosing something within square
brackets. I don't think that's a good idea. I was just using namespaces
to qualify the subscripts.
So, I retract the error argument, since it's already an error. But I
still think the distinctiveness of : vs . is enough to keep the : for
namespaces.
Matt
41. Re: . or : for namespace?
- Posted by don cole <doncole at pacbell??et>
May 06, 2008
-
Last edited May 07, 2008
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Mike wrote:
> > >
> > > So, basically we have :
> > >
> > > obsfucation OR lack of freedom + nice looking
> > >
> >
> > Where?
> > Namespaces are not that many. Do you mean you don't know which identifier is
> > a namespace? Really?
>
> And 640K should be enough for anyone. Seriously, you can't imagine a case
> where there might be a namespace and a variable whose names collide?
>
> While we're at it, why don't we get rid of parentheses and just use square
> brackets everywhere?
> }}}
<eucode>
> puts[1, "Hello, world!\n"]
> </eucode>
{{{
> Matt
s="[hello world]\n"
puts[1,s[1..$-1]]
Seems this would cause some confusion somewhere. Maybe in the interpeter.
Don Cole
42. Re: . or : for namespace?
- Posted by Jeremy Cowgar <jeremy at cowgar.?o?>
May 06, 2008
-
Last edited May 07, 2008
Matt Lewis wrote:
>
>
> I think you meant m20546? Unless you've changed your name...
>
Ops, your right. Didn't mean to take credit for Kat's post 
http://www.openeuphoria.org/EUforum/m20546.html
What do you think?
--
Jeremy Cowgar
http://jeremy.cowgar.com
43. Re: . or : for namespace?
- Posted by Mike <vulcan at wi?.?o.nz>
May 06, 2008
-
Last edited May 07, 2008
CChris wrote:
>
> Mike wrote:
> >
> > CChris wrote:
> > >
> > > Mike wrote:
> > > >
-- snip
> > So, basically we have :
> >
> > obsfucation OR lack of freedom + nice looking
> >
>
> Where?
> Namespaces are not that many. Do you mean you don't know which identifier is
> a namespace? Really?
>
> CChris
Yes. And you don't either. Noone does. That's the point.
I know that you're smart enough to _quickly_ figure out what's going on but not
all of us are so gifted. And I don't think we should have to be. I read
somewhere
that about 70% of programming is maintenance rather than just coding. So, it is
important to easily comprehend program texts.
Jeremy (correctly) predicts that namespaces will become much more common.
Defining
the . instead of : as the namespace operator now, will make it impossible to
later avoid confusing references if the . is then used for sequence access.
It should be pointed out that by having different operators, we can preserve
the unwritten assumption that the number of nesting levels should correspond
to the number of nesting operators.
There are good semantic benefits to keeping : as namespace operator. The only
advantage for using . is that it is nicer looking. I have yet to see advocates
of . present an argument stronger than that.
Think I'm full of horse droppings? Well, you're welcome to prove me wrong.
regards,
Mike
44. Re: . or : for namespace?
- Posted by Jeremy Cowgar <jeremy at cowgar?co?>
May 06, 2008
-
Last edited May 07, 2008
Mike wrote:
>
>
> Yes. And you don't either. Noone does. That's the point.
>
Please comment on my post:
http://www.openeuphoria.org/EUforum/m20546.html
> There are good semantic benefits to keeping : as namespace operator. The only
> advantage for using . is that it is nicer looking. I have yet to see advocates
> of . present an argument stronger than that.
>
> Think I'm full of horse droppings? Well, you're welcome to prove me wrong.
: blends right in with text, that's why others have not adopted it. lik:this.
lik.this does not.
Why do other languages that have the . as the namespace, class, struct delimiter
not have problems? We can look at history and tell this is not going to be a
problem. No sense in trying to predict the future. Preiod is more natural, easier
to read for scanning and easier for typing.
But please, comment on my post that I referred to above.
--
Jeremy Cowgar
http://jeremy.cowgar.com
45. Re: . or : for namespace?
Jeremy Cowgar wrote:
> Please comment on my post:
>
> <a
> href="http://www.openeuphoria.org/EUforum/m20546.html">http://www.openeuphoria.org/EUforum/m20546.html</a>
> : blends right in with text, that's why others have not adopted it. lik:this.
> lik.this does not.
Your examples have demonstrated to me that the selection between '.' and ':' is
somewhat governed by one's opinion of what is aesethically pleasing.
You feel that '.' stands out more in text. I feel that ':' stands out more. Who
is right and does it really matter?
> Why do other languages that have the . as the namespace, class,
> struct delimiter not have problems? We can look at history and
> tell this is not going to be a problem. No sense in trying to
> predict the future.
Your assertion that these languages do not have problems with using '.' instead
of something else may not be so cut and dried. I use the D programming language
and it uses '.' to delimit the use of 'namespace' identifiers. This overloading
of the '.' does cause problems. It places restrictions on the compiler about how
to interpret identifier references and adds a bit of mental overhead for readers
of the code to work out am I looking at a 'package' reference or a class/struct
reference or a property reference. Without knowing the details of other parts of
the source (which may be in other files) it can be difficult, and in some cases
impossible, to be sure.
For example:
foo.bar.qwe(somevalue);
Does 'foo' refer to a module, class, struct, or property?
Does 'foo.bar' refer to a package, class, struct, or property?
If we could write
foo.bar:qwe(somevalue);
we would know *immediately* that 'qwe' is a function defined in the package
'foo.bar' (which means it is in the file called "foo/bar.d").
> Preiod is more natural, easier
> to read for scanning and easier for typing.
In your opinion, unless you have some empirical results of appropriate studies
to show otherwise.
> But please, comment on my post that I referred to above.
Sure ...
include datetime.e as dt
struct emp
emp.name.last = "Doe"
emp.name.first = "John"
emp.age = 35
emp.dob = dt:new(1965, 10, 5, 0, 0, 0)
is so much nicer to read now 
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
46. Re: . or : for namespace?
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Mike wrote:
> > >
> > > So, basically we have :
> > >
> > > obsfucation OR lack of freedom + nice looking
> > >
> >
> > Where?
> > Namespaces are not that many. Do you mean you don't know which identifier is
> > a namespace? Really?
>
> And 640K should be enough for anyone. Seriously, you can't imagine a case
> where there might be a namespace and a variable whose names collide?
>
I can. I'd suggest removing the possibility for a variable, a routine and a
namespace to bear the same name. Would this actually break stuff? It can, but
does it?
> While we're at it, why don't we get rid of parentheses and just use square
> brackets everywhere?
> }}}
<eucode>
> puts[1, "Hello, world!\n"]
> </eucode>
{{{
> Matt
Because we should be able, some day, to ask for value(the_string)[2].
CChris
