www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - '===' revisted?

reply no where.com writes:
From the D Doc:

=====================================
Note: Comparing a reference to a class object against null should be done
as:
if (a === null)
and not as:
if (a == null)
The latter is converted to:
if (a.opCmp (null))
which will fail if opCmp () is a virtual function.
=======================================

When people from C++/Java write 'if (a == null)', and get a core dump, they will
be easily confused: what's going wrong?  Because under the hood, it's a func
call with null passed as parameter!  You have to think twice to realized this.

Why should we introduce such a confusing feature which can mislead C++/Java
programmer easily?  In many other cases D *intentionally* work the same way
C++/Java works, so people familiar with C++/Java can move to D comfortably.  But
why make '===' a special case?

My suggestions:

1)  restore the old semantics of "==" as reference comparison; and

2a) convert the new '===' operator to 'opCmp ()'; or
2b) abadon '===' completely, let the programmer call 'opCmp()' explicitly; (just
as in Java, you call `equals()' explicitly)

So C++/Java programmers will make less mistakes.

I'd prefer 1) and 2b), what do you think?
Jan 10 2005
next sibling parent Andy Friesen <andy ikagames.com> writes:
no where.com wrote:

 
 When people from C++/Java write 'if (a == null)', and get a core dump, they
will
 be easily confused: what's going wrong?  Because under the hood, it's a func
 call with null passed as parameter!  You have to think twice to realized this.


This is an old, sore issue that has been discussed many, many times in 
the past, and has already been resolved, just not in the way that some 
of us would have preferred. :)

Without going too deeply into the gory details, == and != test for 
equivalence.  === and !== test for identity.  It's perfectly consistent, 
and so should stay as it is.

Your problem arises from the fact that Object defines opCmp, which means 
that /all object references/ can be compared with ==, !=, >, <, and the 
rest.  If not for this, the expression "a==b" would be a compile time 
error for types which do not explicitly define opCmp.

  -- andy
Jan 10 2005
prev sibling next sibling parent reply h3r3tic <foo bar.baz> writes:
//! My 2 bits
I'd have a different proposal... What might be done, is some more 
checking in the debug build. I'd say this is almost like array bounds 
checking, the null-ness check might be done for the == (and the rest of 
opCmp-defined) operators in debug, but removed in the release build. I'd 
prefer to see a 'nice' error with full info instead of an Access 
Violation. Something like the ArrayBoundsError would be just fine for me.


Tom



no where.com wrote:

 From the D Doc:
 
 =====================================
 Note: Comparing a reference to a class object against null should be done
 as:
 if (a === null)
 and not as:
 if (a == null)
 The latter is converted to:
 if (a.opCmp (null))
 which will fail if opCmp () is a virtual function.
 =======================================
 
 When people from C++/Java write 'if (a == null)', and get a core dump, they
will
 be easily confused: what's going wrong?  Because under the hood, it's a func
 call with null passed as parameter!  You have to think twice to realized this.
 
 Why should we introduce such a confusing feature which can mislead C++/Java
 programmer easily?  In many other cases D *intentionally* work the same way
 C++/Java works, so people familiar with C++/Java can move to D comfortably. 
But
 why make '===' a special case?
 
 My suggestions:
 
 1)  restore the old semantics of "==" as reference comparison; and
 
 2a) convert the new '===' operator to 'opCmp ()'; or
 2b) abadon '===' completely, let the programmer call 'opCmp()' explicitly;
(just
 as in Java, you call `equals()' explicitly)
 
 So C++/Java programmers will make less mistakes.
 
 I'd prefer 1) and 2b), what do you think?
Jan 10 2005
next sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
For 1.0 in its current incarnation I think there's a necessity for 
checking for the specific expression

a == null

and at least issuing a warning...  it would be a simple search over 
parse trees to catch this common mistake at COMPILE (rather than 
run)time.  Clearly there are (rare, unnecessary since you can call 
opCmp) times when you want to pass null into an opCMP but then perhaps 
having a cast or something to illustrate that you are not making a mistake

a = cast(Object)null

like so.

I guess we *could* have a lint program do this for us--but if/when this 
magical lint program gets made...and decides NOT to spit a billion 
warnings out for otherwise-working projects is a mystery.

An alternative would be making C and pascal programmers less likely to 
fail (in C == was always bitwise compare)

how about changing


a=b (read a gets b)
to
a := b;

and a==b (read a opCmp b)
to
a=b

and lastly
a===b (read a (pointer or otherwise) bitwise equals b)
to
a==b

two equals signs is already a hack--but 3...c'mon! that's making 3 
separate operators consisting of various numbers of the same char... 2 
already cause a great number of errors amongst C and C++ newbies from 
all backgrounds.




h3r3tic wrote:

 //! My 2 bits
 I'd have a different proposal... What might be done, is some more 
 checking in the debug build. I'd say this is almost like array bounds 
 checking, the null-ness check might be done for the == (and the rest of 
 opCmp-defined) operators in debug, but removed in the release build. I'd 
 prefer to see a 'nice' error with full info instead of an Access 
 Violation. Something like the ArrayBoundsError would be just fine for me.
 
 
 Tom
 
 
 
 no where.com wrote:
 

 From the D Doc:

 =====================================
 Note: Comparing a reference to a class object against null should be done
 as:
 if (a === null)
 and not as:
 if (a == null)
 The latter is converted to:
 if (a.opCmp (null))
 which will fail if opCmp () is a virtual function.
 =======================================

 When people from C++/Java write 'if (a == null)', and get a core dump, 
 they will
 be easily confused: what's going wrong?  Because under the hood, it's 
 a func
 call with null passed as parameter!  You have to think twice to 
 realized this.

 Why should we introduce such a confusing feature which can mislead 
 C++/Java
 programmer easily?  In many other cases D *intentionally* work the 
 same way
 C++/Java works, so people familiar with C++/Java can move to D 
 comfortably.  But
 why make '===' a special case?

 My suggestions:

 1)  restore the old semantics of "==" as reference comparison; and

 2a) convert the new '===' operator to 'opCmp ()'; or
 2b) abadon '===' completely, let the programmer call 'opCmp()' 
 explicitly; (just
 as in Java, you call `equals()' explicitly)

 So C++/Java programmers will make less mistakes.

 I'd prefer 1) and 2b), what do you think?
Jan 12 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Daniel Horn wrote:

 For 1.0 in its current incarnation I think there's a necessity for 
 checking for the specific expression
 
 a == null
 
 and at least issuing a warning... 


I agree - the compiler should do whatever it can to catch code that is 
obviously going to AV or something.  But for as long as Walter thinks 
warnings are a Bad Thing, it'll have to be an error....


 it would be a simple search over 
 parse trees to catch this common mistake at COMPILE (rather than 
 run)time.  Clearly there are (rare, unnecessary since you can call 
 opCmp) times when you want to pass null into an opCMP but then perhaps 
 having a cast or something to illustrate that you are not making a mistake
 
 a = cast(Object)null


Which you indeed are, albeit by dropping an '='.

<snip>

 how about changing
 
 a=b (read a gets b)
 to
 a := b;
 
 and a==b (read a opCmp b)
 to
 a=b
 
 and lastly
 a===b (read a (pointer or otherwise) bitwise equals b)
 to
 a==b


<snip top of upside-down reply>

You may be up for completely changing the meaning of every D program 
ever written.  But I'm quite sure most of us aren't.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 12 2005
parent reply Andy Friesen <andy ikagames.com> writes:
Stewart Gordon wrote:

 Daniel Horn wrote:
 

 For 1.0 in its current incarnation I think there's a necessity for 
 checking for the specific expression

 a == null

 and at least issuing a warning... 


 
 
 I agree - the compiler should do whatever it can to catch code that is 
 obviously going to AV or something.  But for as long as Walter thinks 
 warnings are a Bad Thing, it'll have to be an error....
 


Walter dislikes warnings because their need is symptomatic of a weakness 
in the language.  This makes a whole lot of sense to me: if something is 
shady enough that a warning is justified, then it's exactly the sort of 
subtle trap that a we need to avoid.

However, I also agree that this should produce a warning, because I 
believe that this is a dire weakness in the language. :)

I would be much happier, though, if it was a compile error under normal 
circumstances.

Here's a question: How many would be willing to give up the array.sort 
property in exchange for disallowing x==y? (*)

Removing opCmp from Object would achieve precisely this, and it would 
not require much change to the compiler itself.  The sort function could 
be moved to the standard library easily enough, requiring only minor 
adjustments to existing code, while still succeeding in making it harder 
to write bad code that looks good.

(*) x==y would be legal only if type(x) defines opEquals or opCmp, which 
should be a small minority of cases.

  -- andy
Jan 12 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Andy Friesen wrote:
<snip>

 Walter dislikes warnings because their need is symptomatic of a weakness 
 in the language.  This makes a whole lot of sense to me: if something is 
 shady enough that a warning is justified, then it's exactly the sort of 
 subtle trap that a we need to avoid.


It doesn't really make sense to me.  There was quite a thread on this a 
while back, and here is my input at the time....

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5403


 However, I also agree that this should produce a warning, because I 
 believe that this is a dire weakness in the language. :)
 
 I would be much happier, though, if it was a compile error under normal 
 circumstances.


Indeed.  Similarly with allowing auto references to be declared without 
initialisation.


 Here's a question: How many would be willing to give up the array.sort 
 property in exchange for disallowing x==y? (*)
 
 Removing opCmp from Object would achieve precisely this, and it would 
 not require much change to the compiler itself.  The sort function could 
 be moved to the standard library easily enough, requiring only minor 
 adjustments to existing code, while still succeeding in making it harder 
 to write bad code that looks good.


What would be the point of moving sort to the standard library?


 (*) x==y would be legal only if type(x) defines opEquals or opCmp, which 
 should be a small minority of cases.


What would be the point of that?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 12 2005
parent reply Andy Friesen <andy ikagames.com> writes:
Stewart Gordon wrote:

 Andy Friesen wrote:
 <snip>
 

 Walter dislikes warnings because their need is symptomatic of a 
 weakness in the language.  This makes a whole lot of sense to me: if 
 something is shady enough that a warning is justified, then it's 
 exactly the sort of subtle trap that a we need to avoid.


 
 It doesn't really make sense to me.  There was quite a thread on this a 
 while back, and here is my input at the time....
 
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5403


Basically, it boils down to the idea that the weakness lies in the fact 
that these questionable formations are possible at all.

For example, the code segment "if (qwert = yuiop) { ... }" could be 
exactly what the author intended, but only if they are explicitly taking 
advantage of a peculiarity in the language.

Even if it's not a mistake, it's misleading: it looks like it could be a 
mistake, and if it's not, there's no reason not to just write

     qwert = yuiop; if (qwert) { ... }

If assignment is a statement and not an expression, the formation is 
illegal.  This removes a way to write misleading code, and it makes a 
compile error out of a very frequent mistake.  I'd be hard pressed not 
to call this a win.

I'll readily agree that a warning is better than nothing at all, but a 
lot of the warnings C and C++ compilers issue could be obliviated by 
adjusting the language.


 I would be much happier, though, if it was a compile error under 
 normal circumstances.


 
 Indeed.  Similarly with allowing auto references to be declared without 
 initialisation.


I had no idea that was legal.  The behaviour seems perfectly logical to 
me, but I can understand how that might be misleading.  Perhaps auto 
references should also be final.


 What would be the point of moving sort to the standard library?


"x==y" is only legal because Object[].sort depends on Object.opCmp. 
Removing Object[].sort means that Object.opCmp can be removed, which in 
turn means that "x==y" becomes a compile-time error.

D has very nice template support now, so there's no reason not to make 
sorting a standard library function instead of a language builtin. 
Doing this allows us to turn a very common mistake with subtle 
consequences into one that is easy to find and fix.

  -- andy
Jan 12 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Andy Friesen wrote:

 Stewart Gordon wrote:


<snip>

 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5403


 
 Basically, it boils down to the idea that the weakness lies in the fact 
 that these questionable formations are possible at all.


<snip>

 I'll readily agree that a warning is better than nothing at all, but a 
 lot of the warnings C and C++ compilers issue could be obliviated by 
 adjusting the language.


Indeed.  But if a language is supposed to be portable, then individual 
compiler writers can't just adjust the language to the formations they 
personally find questionable.  This is probably where a lot of the 
warnings in C(++) compilers came from - their developers finding 
questionable 'features' of the language.

<snip>

 Indeed.  Similarly with allowing auto references to be declared 
 without initialisation.


 
 I had no idea that was legal.  The behaviour seems perfectly logical to 
 me, but I can understand how that might be misleading.


What is perfectly logical about being able to declare something if it's 
obvious there and then that you'll never be able to do anything with it 
without causing an AV?


 Perhaps auto references should also be final.


I had no idea that local variables could be final.  What does it mean, 
exactly?


 What would be the point of moving sort to the standard library?


 
 "x==y" is only legal because Object[].sort depends on Object.opCmp. 
 Removing Object[].sort means that Object.opCmp can be removed,


So can other approaches, such as reimplementing it using templates, or 
as described here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/10558


 which in turn means that "x==y" becomes a compile-time error.


== depends on opEquals, not opCmp.


 D has very nice template support now, so there's no reason not to make 
 sorting a standard library function instead of a language builtin. Doing 
 this allows us to turn a very common mistake with subtle consequences 
 into one that is easy to find and fix.


At the moment, I still don't see what turning it into a library function 
has to do with fixing this wart.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 13 2005
parent reply Andy Friesen <andy ikagames.com> writes:
Stewart Gordon wrote:

 But if a language is supposed to be portable, then individual 
 compiler writers can't just adjust the language to the formations they 
 personally find questionable.  This is probably where a lot of the 
 warnings in C(++) compilers came from - their developers finding 
 questionable 'features' of the language.


Of course, but Walter is in a position to change both.  If he so 
decrees, a questionable formation can cease to be legal D.


 I had no idea that was legal.  The behaviour seems perfectly logical 
 to me, but I can understand how that might be misleading.


 
 What is perfectly logical about being able to declare something if it's 
 obvious there and then that you'll never be able to do anything with it 
 without causing an AV?


Perhaps its behaviour is not so obvious, then. :)  I had assumed that it 
could be assigned a value later on, which would then be disposed of when 
the auto variable falls out of scope.  eg

     auto File f;
     if (reading) f = new File("foo.txt", FileMode.In);
     else         f = new File("foo.txt", FileMode.OutNew);


 Perhaps auto references should also be final.


 
 I had no idea that local variables could be final.  What does it mean, 
 exactly?


I don't think they can.  What it would mean is that it would be an error 
to assign to a final variable after initialization.


 What would be the point of moving sort to the standard library?


 "x==y" is only legal because Object[].sort depends on Object.opCmp. 
 Removing Object[].sort means that Object.opCmp can be removed,


 
 So can other approaches, such as reimplementing it using templates, or 
 as described here:
 
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/10558


That would also work, though reserving a vtable slot for opCmp feels a 
bit rickety to me.  How would you do this:

    interface I { int opCmp(I rhs); }
    interface J { int opCmp(J rhs); }

    class C : I, J { .... }

    I[] is = { new C(), .... };
    J[] js = { new C(), .... };

    is.sort;
    js.sort;

That being said, the ends are more interesting to me than the means. :)


 which in turn means that "x==y" becomes a compile-time error.


 
 == depends on opEquals, not opCmp.


Right, sorry.  In an ideal world, both would get the axe.


 D has very nice template support now, so there's no reason not to make 
 sorting a standard library function instead of a language builtin. 
 Doing this allows us to turn a very common mistake with subtle 
 consequences into one that is easy to find and fix.


 
 At the moment, I still don't see what turning it into a library function 
 has to do with fixing this wart.


Array.sort is the only place, as far as I have been able to tell, that 
can't do without opCmp without losing functionality.  (AAs may be a hair 
slower in the case of hash clashes, but they will still associate just fine)

  -- andy
Jan 13 2005
next sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Andy Friesen wrote:

 Of course, but Walter is in a position to change both.  If he so
 decrees, a questionable formation can cease to be legal D.


I don't know whether it is a good idea to illegalize things that cannot be
checked in every case. IMO, the compiler should be able to give a definite
answer as to whether some code is legal or not. Furthermore, illegalizing
always means adding a rule to the language specifications. If you add a
special rule for every questionable case, the language specs will get
really ugly.
Jan 13 2005
parent Andy Friesen <andy ikagames.com> writes:
Norbert Nemec wrote:

 Andy Friesen wrote:
 

Of course, but Walter is in a position to change both.  If he so
decrees, a questionable formation can cease to be legal D.


 
 I don't know whether it is a good idea to illegalize things that cannot be
 checked in every case. IMO, the compiler should be able to give a definite
 answer as to whether some code is legal or not. Furthermore, illegalizing
 always means adding a rule to the language specifications. If you add a
 special rule for every questionable case, the language specs will get
 really ugly.


Right.  I was thinking about more subtle methods, like making assignment 
a statement so it cannot be a loop condition.

Of course, there's no guarantee that such a solution is apparent, in 
which case a warning is really all that can be done.

  -- andy
Jan 14 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Andy Friesen wrote:

 Stewart Gordon wrote:
 

 But if a language is supposed to be portable, then individual compiler 
 writers can't just adjust the language to the formations they 
 personally find questionable.  This is probably where a lot of the 
 warnings in C(++) compilers came from - their developers finding 
 questionable 'features' of the language.


 
 Of course, but Walter is in a position to change both.  If he so 
 decrees, a questionable formation can cease to be legal D.


Of course, but what makes you think Walter is the only person in the 
world who will ever write a D compiler?

<snip>

 Perhaps auto references should also be final.


 
 I had no idea that local variables could be final.  What does it mean, 
 exactly?


 
 I don't think they can.  What it would mean is that it would be an error 
 to assign to a final variable after initialization.


It's called const.  Though I forget the extent to which such things have 
to be compile-time constants as it currently stands.

But indeed, it is specifically stated:

http://www.digitalmars.com/d/attribute.html#auto

"Assignment to an auto, other than initialization, is not allowed."

<snip>

 That would also work, though reserving a vtable slot for opCmp feels a 
 bit rickety to me.  How would you do this:
 
    interface I { int opCmp(I rhs); }
    interface J { int opCmp(J rhs); }
 
    class C : I, J { .... }


I guess that the reserved slot would only be filled if C defines 
opCmp(C) as well as opCmp(I) and opCmp(J).  Otherwise, comparing a C 
with a C would be ambiguous and therefore an error.

Of course, the interface vtbls (if there's a such a thing) would have 
opCmp(I) and opCmp(J) in those slots respectively.

<snip>

 At the moment, I still don't see what turning it into a library 
 function has to do with fixing this wart.


 
 Array.sort is the only place, as far as I have been able to tell, that 
 can't do without opCmp without losing functionality. 


<snip>

Indeed.  But that doesn't mean it can't do without _Object_.opCmp.

And you're still not telling me anything about how moving it from 
builtin to the library will be either necessary or sufficient to 
overcome the dependence on Object.opCmp.  Moreover, many builtins are 
already implemented in terms of library functions (mostly in the 
internal package), and that includes sort.  As such, the implementation 
options are pretty much the same in either case.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 14 2005
next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <cs89af$1v8p$1 digitaldaemon.com>, Stewart Gordon says...

Andy Friesen wrote:

 Stewart Gordon wrote:
 

 But if a language is supposed to be portable, then individual compiler 
 writers can't just adjust the language to the formations they 
 personally find questionable.  This is probably where a lot of the 
 warnings in C(++) compilers came from - their developers finding 
 questionable 'features' of the language.


 
 Of course, but Walter is in a position to change both.  If he so 
 decrees, a questionable formation can cease to be legal D.


Of course, but what makes you think Walter is the only person in the 
world who will ever write a D compiler?


Am I understanding you correctly, Stewart?

In the first paragraph you argue for resolving 'questionable features' so that a
standard set of D features will be implemented by anyone developing a D
compiler.

In the third, you seemingly imply that other D compiler implementers may deviate
from the reference compiler wrt 'questionable features'.

If that's the case, then (obviously), let's stay off of that slippery slope..
Andy is correct - certainly Walter should be the final arbiter on these matters.

Implementing a D compiler with one of the purposes being changing features of
the language would (again, obviously) be disastrous for everyone.

I'm sure we'ed all rather have every compiler working the same way for the
relatively few features we don't like than have one or more forks of the
language (once again, obviously).

If I'm misunderstanding where you were heading with the 3rd paragraph, please
correct me.

- Dave
Jan 14 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Dave wrote:
<snip>

 Am I understanding you correctly, Stewart?
 
 In the first paragraph you argue for resolving 'questionable 
 features' so that a standard set of D features will be implemented by 
 anyone developing a D compiler.
 
 In the third, you seemingly imply that other D compiler implementers 
 may deviate from the reference compiler wrt 'questionable features'.


Depends on what you mean.  If you mean deviate in terms of what they'll 
accept as a valid program, then of course not.  If you mean deviate in 
terms of whether to issue warnings and what warnings to issue, then they 
ought to have every right to.

<snip>

 If I'm misunderstanding where you were heading with the 3rd 
 paragraph, please correct me.


Your whole comment seems written around the pretence that there is no 
such thing as a warning.

My point is that, while Walter can indeed change D so that more and more 
questionable features are eliminated, third-party compiler writers 
cannot.  Hence they are going to want to help coders avoid common 
mistakes that aren't errors by the language spec.  The usual way to do 
this, implemented by generations of C(++) compilers, is by issuing warnings.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.
Jan 14 2005
parent Dave <Dave_member pathlink.com> writes:
In article <cs92bh$2s2n$1 digitaldaemon.com>, Stewart Gordon says...

Dave wrote:
<snip>

 Am I understanding you correctly, Stewart?
 
 In the first paragraph you argue for resolving 'questionable 
 features' so that a standard set of D features will be implemented by 
 anyone developing a D compiler.
 
 In the third, you seemingly imply that other D compiler implementers 
 may deviate from the reference compiler wrt 'questionable features'.


Depends on what you mean.  If you mean deviate in terms of what they'll 
accept as a valid program, then of course not.  If you mean deviate in 
terms of whether to issue warnings and what warnings to issue, then they 
ought to have every right to.


That different compilers not deviate on what is acceptable (and how it actually
executes) is what I was driving at and I guess you were too - I just couldn't
tell from the post and it's context.

Absolutely, different warning mechanisms intended to help the developer with
common pitfalls and such are a good thing for compilers to compete over.

- Dave
Jan 14 2005
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Stewart Gordon wrote:

 Andy Friesen wrote:
 

 Stewart Gordon wrote:


 But if a language is supposed to be portable, then individual 
 compiler writers can't just adjust the language to the formations 
 they personally find questionable.  This is probably where a lot of 
 the warnings in C(++) compilers came from - their developers finding 
 questionable 'features' of the language.


 Of course, but Walter is in a position to change both.  If he so 
 decrees, a questionable formation can cease to be legal D.


 
 Of course, but what makes you think Walter is the only person in the 
 world who will ever write a D compiler?


I'm sorry, I think I misunderstood you.  What I meant was that it's 
possible for a lot of frequent warnings to be obliviated by the language 
designer.


 I had no idea that local variables could be final.  What does it 
 mean, exactly?


 I don't think they can.  What it would mean is that it would be an 
 error to assign to a final variable after initialization.


 
 It's called const.  Though I forget the extent to which such things have 
 to be compile-time constants as it currently stands.


const values are restricted to those which can be completely evaluated 
by the compiler.  "const int x = rand();" won't work, whereas "final int 

not a D concept.


 And you're still not telling me anything about how moving it from 
 builtin to the library will be either necessary or sufficient to 
 overcome the dependence on Object.opCmp.  Moreover, many builtins are 
 already implemented in terms of library functions (mostly in the 
 internal package), and that includes sort.  As such, the implementation 
 options are pretty much the same in either case.


I'm primarily thinking about the amount of work it would take to adjust 
DMD.  As far as I can tell, array.sort isn't dealt with until late in 
compilation, in the bits whose source code we are not privy to.  I don't 
know how much renovating would be needed to change that to a template 
instantiation/invocation, but it seems logical that removing it 
completely would be straightforward enough.  This would be the only part 
of DMD itself which would need to change at all: the rest is all Phobos.

  -- andy
Jan 14 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Andy Friesen wrote:
<snip>

 I'm primarily thinking about the amount of work it would take to adjust 
 DMD.  As far as I can tell, array.sort isn't dealt with until late in 
 compilation, in the bits whose source code we are not privy to. 


Even if it's in the middle-end, there's nothing to say it can't be moved 
to the front-end.


 I don't know how much renovating would be needed to change that to a template 
 instantiation/invocation,


<snip>

It would be a simple matter of writing sort as a template function, 
maybe internal.qsort.sort(T), and then mapping

     array.sort;

to

     internal.qsort.sort!(T)(array);

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 14 2005
prev sibling next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <cs3p07$2gn6$1 digitaldaemon.com>, Andy Friesen says...

Here's a question: How many would be willing to give up the array.sort 
property in exchange for disallowing x==y? (*)

Removing opCmp from Object would achieve precisely this, and it would 
not require much change to the compiler itself.  The sort function could 
be moved to the standard library easily enough, requiring only minor 
adjustments to existing code, while still succeeding in making it harder 
to write bad code that looks good.


Oh, if only Walter would agree! 

The .sort property was in place long before either Template or Interface were
added. Since that time, the argument for having .sort as part of the language
spec is (IMO) seriously weakened; particularly so since it is the prime (and
only?) reason for the awkward opCmp within Object. Either of Template or
Interface could do the job just as effectively, and be user-replaceable
(alternate sorting mechanisms, anyone?) if the functionality were moved to a
library instead.

There's been a whole lot of discussion on this before, and it really seemed as
though there was a reasonable concensus on the issue. But ... nothing changed.

Heck, I recall Walter noting he would /definately/ remove the usage of printf()
from Object (to reduce the minimal footprint: all that FP support dragged along
for no legitimate reason) -- that he "just had to get around to it". That was
the middle of last year; Ben even posted the small list of changes needed in
Phobos (all within debug code, I vaguely recall).

Tightening up the language spec appears to be the lowest priority. 

If I come across as being somewhat dejected, it's not because D isn't a fine
language ... it's because it could be made a whole lot better through just a few
tweaks here and there (such as the removal of opCmp in Object, or making the
usage of 'override' mandatory). 

Sure, such changes may break some existing code! Better now than after v1.0,
right? I'd be happy to spend the time editing the ~100,000 lines I've written if
it meant the language was tighter, leaner, and ultimately less prone to user
error.

<sigh>
Jan 12 2005
parent "Charles" <no email.com> writes:
I second this completely, do away with it , give us sort's with user defined
sorting .

If only we could get Walter to here us ;).

Charlie


"Kris" <Kris_member pathlink.com> wrote in message
news:cs3sfd$2mer$1 digitaldaemon.com...

 In article <cs3p07$2gn6$1 digitaldaemon.com>, Andy Friesen says...

Here's a question: How many would be willing to give up the array.sort
property in exchange for disallowing x==y? (*)

Removing opCmp from Object would achieve precisely this, and it would
not require much change to the compiler itself.  The sort function could
be moved to the standard library easily enough, requiring only minor
adjustments to existing code, while still succeeding in making it harder
to write bad code that looks good.


 Oh, if only Walter would agree!

 The .sort property was in place long before either Template or Interface


were

 added. Since that time, the argument for having .sort as part of the


language

 spec is (IMO) seriously weakened; particularly so since it is the prime


(and

 only?) reason for the awkward opCmp within Object. Either of Template or
 Interface could do the job just as effectively, and be user-replaceable
 (alternate sorting mechanisms, anyone?) if the functionality were moved to


a

 library instead.

 There's been a whole lot of discussion on this before, and it really


seemed as

 though there was a reasonable concensus on the issue. But ... nothing


changed.

 Heck, I recall Walter noting he would /definately/ remove the usage of


printf()

 from Object (to reduce the minimal footprint: all that FP support dragged


along

 for no legitimate reason) -- that he "just had to get around to it". That


was

 the middle of last year; Ben even posted the small list of changes needed


in

 Phobos (all within debug code, I vaguely recall).

 Tightening up the language spec appears to be the lowest priority.

 If I come across as being somewhat dejected, it's not because D isn't a


fine

 language ... it's because it could be made a whole lot better through just


a few

 tweaks here and there (such as the removal of opCmp in Object, or making


the

 usage of 'override' mandatory).

 Sure, such changes may break some existing code! Better now than after


v1.0,

 right? I'd be happy to spend the time editing the ~100,000 lines I've


written if

 it meant the language was tighter, leaner, and ultimately less prone to


user

 error.

 <sigh>
Jan 14 2005
prev sibling next sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
Andy Friesen wrote:

 Walter dislikes warnings because their need is symptomatic of a weakness
 in the language.  This makes a whole lot of sense to me: if something is
 shady enough that a warning is justified, then it's exactly the sort of
 subtle trap that a we need to avoid.


Guess, every language designer starts out idealistic. :-)
Jan 12 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 Here's a question: How many would be willing to give up the array.sort
 property in exchange for disallowing x==y? (*)

 Removing opCmp from Object would achieve precisely this, and it would
 not require much change to the compiler itself.  The sort function could
 be moved to the standard library easily enough, requiring only minor
 adjustments to existing code, while still succeeding in making it harder
 to write bad code that looks good.

 (*) x==y would be legal only if type(x) defines opEquals or opCmp, which
 should be a small minority of cases.


opEquals and opCmp are used by the TypeInfo for Objects (see
src/phobos/std/typeinfo/ti_C.d). And the compare function in the TypeInfo is
used by associative arrays lookup. So removing opCmp would impact more than
sort - it would impact AA's and TypeInfo's (which are also used by MinTL
containers). So any proposal about removing opEquals and opCmp need to talk
about what to do about TypeInfos and how they would work for Objects.

-Ben
Jan 12 2005
parent reply Andy Friesen <andy ikagames.com> writes:
Ben Hinkle wrote:

Here's a question: How many would be willing to give up the array.sort
property in exchange for disallowing x==y? (*)

Removing opCmp from Object would achieve precisely this, and it would
not require much change to the compiler itself.  The sort function could
be moved to the standard library easily enough, requiring only minor
adjustments to existing code, while still succeeding in making it harder
to write bad code that looks good.

(*) x==y would be legal only if type(x) defines opEquals or opCmp, which
should be a small minority of cases.


 
 opEquals and opCmp are used by the TypeInfo for Objects (see
 src/phobos/std/typeinfo/ti_C.d). And the compare function in the TypeInfo is
 used by associative arrays lookup. So removing opCmp would impact more than
 sort - it would impact AA's and TypeInfo's (which are also used by MinTL
 containers). So any proposal about removing opEquals and opCmp need to talk
 about what to do about TypeInfos and how they would work for Objects.


Right.  That's the easy part.

TypeInfo.compare can be removed easily enough: it is only used in a 
handful of places, and those cases are, as far as I can tell, 
exclusively limited to the AA code. (and MinTL, evidently)  It should be 
easy enough to modify these classes to use TypeInfo.getHash() instead.

An easier way is to adjust ti_C.d to use Object.toHash() instead of 
opCmp and opEquals.  This preserves existing AA behaviour without 
requiring the definition of comparison operators.  This bugs me, though, 
as we're left with a TypeInfo.compare method which compares objects by 
effectively meaningless criteria, whether or not a more meaningful 
comparison is available. (I have tried this myself.  Everything seems to 
work okay, but I haven't tested it very thoroughly yet)

  -- andy
Jan 12 2005
parent reply parabolis <parabolis softhome.net> writes:
Andy Friesen wrote:

 
 An easier way is to adjust ti_C.d to use Object.toHash() instead of 
 opCmp and opEquals.  This preserves existing AA behaviour without 
 requiring the definition of comparison operators.


I think the opCmp and opEquals are used in AAs to deal with hash 
  collisions.
Jan 12 2005
parent reply Andy Friesen <andy ikagames.com> writes:
parabolis wrote:

 Andy Friesen wrote:
 

 An easier way is to adjust ti_C.d to use Object.toHash() instead of 
 opCmp and opEquals.  This preserves existing AA behaviour without 
 requiring the definition of comparison operators.


 
 I think the opCmp and opEquals are used in AAs to deal with hash 
  collisions.


gah.  You're right.

This would almost work as-is, because an object instance's hash code is 
(unless overridden) its address, but that's not exactly a good longterm 
solution.  Without some way to order objects that has nothing to do with 
hash codes, the AA implementation would have to resort to a linear 
search when digging out keys with a particular hash value.

So much for the trivial fix. :\

  -- andy
Jan 12 2005
parent parabolis <parabolis softhome.net> writes:
Andy Friesen wrote:

 parabolis wrote:
 

 Andy Friesen wrote:


 An easier way is to adjust ti_C.d to use Object.toHash() instead of 
 opCmp and opEquals.  This preserves existing AA behaviour without 
 requiring the definition of comparison operators.



 I think the opCmp and opEquals are used in AAs to deal with hash 
  collisions.


 
 
 gah.  You're right.
 
 This would almost work as-is, because an object instance's hash code is 
 (unless overridden) its address, but that's not exactly a good longterm 
 solution.  Without some way to order objects that has nothing to do with 
 hash codes, the AA implementation would have to resort to a linear 
 search when digging out keys with a particular hash value.
 
 So much for the trivial fix. :\


Maybe. I have been wondering whether it would be an improvement 
to eliminate Object as the default base class. Doing so would 
mean the comparison operators would not work on objects and 
classes would have to use .equals and .compareTo member 
functions instead. It would also mean redesigning the guarantee 
that an object has the .equals, .compareTo and .toHash functions 
via interfaces:
----------------------------------------------------------------
Interface Comparable {
   int compareTo();
}

Interface Equatable {
   bit equals();
}

Interface Hashable : Comparable, Equatable {
   int toHash();
}
----------------------------------------------------------------
Jan 13 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Daniel Horn wrote:


 I guess we *could* have a lint program do this for us--but if/when this 
 magical lint program gets made...and decides NOT to spit a billion 
 warnings out for otherwise-working projects is a mystery.


D should have all "warnings" enabled by default, as part of the design.

http://www.digitalmars.com/d/overview.html:

 No Warnings
 D compilers will not generate warnings for questionable code.
 Code will either be acceptable to the compiler or it will not be.
 This will eliminate any debate about which warnings are valid
 errors and which are not, and any debate about what to do with them.
 The need for compiler warnings is symptomatic of poor language design.


So all warnings and lint should be enabled by default, and give errors.


 two equals signs is already a hack--but 3...c'mon! that's making 3 
 separate operators consisting of various numbers of the same char... 2 
 already cause a great number of errors amongst C and C++ newbies from 
 all backgrounds.


I thought that "===" was deprecated in favor of "is" ? (for TOKidentity)
http://www.digitalmars.com/d/expression.html#EqualExpression

But I also think that the compiler should be able to catch "foo == null"
I mean, it already catches the "if (a = b)" typo? (not a boolean result)

--anders

PS. The only problem was there isn't such a token for TOKnotidentity.
     But something like "isnt" should do, I suppose ? Or perhaps "aint".
     Or one of the syntactically horrible "is not" or "isn't" (not alnum)
     The current workaround is to use: !(a is b), which of course works.
Jan 12 2005
parent "Charles" <no email.com> writes:
 Or perhaps "aint".


Yes! lol

"Anders F Björklund" <afb algonet.se> wrote in message
news:cs2uaf$18nj$1 digitaldaemon.com...

 Daniel Horn wrote:


 I guess we *could* have a lint program do this for us--but if/when this
 magical lint program gets made...and decides NOT to spit a billion
 warnings out for otherwise-working projects is a mystery.


 D should have all "warnings" enabled by default, as part of the design.

 http://www.digitalmars.com/d/overview.html:

 No Warnings
 D compilers will not generate warnings for questionable code.
 Code will either be acceptable to the compiler or it will not be.
 This will eliminate any debate about which warnings are valid
 errors and which are not, and any debate about what to do with them.
 The need for compiler warnings is symptomatic of poor language design.


 So all warnings and lint should be enabled by default, and give errors.


 two equals signs is already a hack--but 3...c'mon! that's making 3
 separate operators consisting of various numbers of the same char... 2
 already cause a great number of errors amongst C and C++ newbies from
 all backgrounds.


 I thought that "===" was deprecated in favor of "is" ? (for TOKidentity)
 http://www.digitalmars.com/d/expression.html#EqualExpression

 But I also think that the compiler should be able to catch "foo == null"
 I mean, it already catches the "if (a = b)" typo? (not a boolean result)

 --anders

 PS. The only problem was there isn't such a token for TOKnotidentity.
      But something like "isnt" should do, I suppose ? Or perhaps "aint".
      Or one of the syntactically horrible "is not" or "isn't" (not alnum)
      The current workaround is to use: !(a is b), which of course works.
Jan 14 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Daniel Horn wrote:


 how about changing
 
 a=b (read a gets b)
 to
 a := b;
 
 and a==b (read a opCmp b)
 to
 a=b


If you want Pascal, you know where to get it... ?

Also,
a=b reads "b is assigned to a" (Assign Expression)
a==b reads as "a.opEquals(b)" (Equality Expression)

Then again,
o==null reads* "false", but
null==o reads "segfault" ;-)

* assuming: assert(o != null)


 and lastly
 a===b (read a (pointer or otherwise) bitwise equals b)
 to
 a==b


But '===' or 'is' checks for identity, not for equality!

http://www.digitalmars.com/d/expression.html#EqualExpression (Identity)


 For operand types other than class objects, static or dynamic arrays,
 identity is defined as being the same as equality.
 
 For class objects, identity is defined as the object references are
 for the same object. Null class objects can be compared with is.
 
 For static and dynamic arrays, identity is defined as referring to
 the same array elements.


The problem is that identity and equality are confused.
Changing the token names does not help with this issue...


For a Java programmer, the D rules for objects are strange.
Of course, the Java rules are a little weird too - as in:

http://www.witscale.com/scjp_studynotes/code_examples/chapter3/string_equality.html

Then again, that's partly because all arrays and strings are
objects in Java. And partly since it doesn't have op overloads ?

--anders


PS. http://www.gnu-pascal.de/gpc/h-index.html (GPC)
     http://www.microbizz.nl/gpc.html (Mac OS X)
     http://www.freepascal.org/
Jan 12 2005
parent reply parabolis <parabolis softhome.net> writes:
Anders F Björklund wrote:

 Of course, the Java rules are a little weird too - as in:
 
 http://www.witscale.com/scjp_studynotes/code_examples/chapter3/
tring_equality.html 
 
 Then again, that's partly because all arrays and strings are
 objects in Java. And partly since it doesn't have op overloads ?



   Actually the people who created Java are the only ones who 
can (and have) overloaded ops. Your example is thus an example 
of bad operator overloading which is (fortunately) limited in 
Java. It keeps the code away from C++/D stuff like:

----------------------------------------------------------------
   ...
   Apple a = new Apple(1);
   Orange o = new Orange(1);
   if( a > o )
   ...
----------------------------------------------------------------

Some notes on comparing apples and oranges:

http://www.people.virginia.edu/~rjh9u/apporang.html
http://bmj.bmjjournals.com/cgi/content/full/321/7276/1569
Jan 12 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
parabolis wrote:


   Actually the people who created Java are the only ones who can (and 
 have) overloaded ops. Your example is thus an example of bad operator 
 overloading which is (fortunately) limited in Java.


If James Gosling can overload "plus" (+) to mean string concat,
Bjarne Stroustrup can use bit shifts (<< >>) to do stream I/O,
and Walter Bright can overload "not" (~) to mean concatenation -

then why should the rest of us be left out of all the fun ? :-)


But I am not sure I understand what you mean, since the default
implementation of equals in Java is to just use object identity.
And == works very differently for integers and strings there ?

Java's policy is just to "stay out of anything that can be misused"

--anders
Jan 12 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Anders F Björklund wrote:

 parabolis wrote:
 

   Actually the people who created Java are the only ones who can (and 
 have) overloaded ops. Your example is thus an example of bad operator 
 overloading which is (fortunately) limited in Java.


 
 If James Gosling can overload "plus" (+) to mean string concat,


James Gosling was by no means the first to do it.  But whether it was 
John Kemeny/Thomas Kurtz or if it caught on since their time isn't clear 
from my sources.

<snip>

 Java's policy is just to "stay out of anything that can be misused"


Java does nothing to stop you abusing the equals and compareTo [sic] 
methods, or otherwise implementing an interface method to do something 
completely unrelated to its purpose.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 12 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:


 If James Gosling can overload "plus" (+) to mean string concat,


 
 James Gosling was by no means the first to do it.  But whether it was 
 John Kemeny/Thomas Kurtz or if it caught on since their time isn't clear 
 from my sources.


:-) (I bow to your "Oak" knowledge)

Just seems that every language needs to use it's own character...

Java: "+", D: "~", Perl: ".", Basic: "&", and so on, and so on ?

--anders
Jan 12 2005
next sibling parent Jason Jasmin <zod269-d yahoo.com> writes:
ISTR that php used the ~ also... could be wrong though, it's been years 
since I've used php...

Anders F Björklund wrote:

 Stewart Gordon wrote:
 

 If James Gosling can overload "plus" (+) to mean string concat,



 James Gosling was by no means the first to do it.  But whether it was 
 John Kemeny/Thomas Kurtz or if it caught on since their time isn't 
 clear from my sources.


 
 
 :-) (I bow to your "Oak" knowledge)
 
 Just seems that every language needs to use it's own character...
 
 Java: "+", D: "~", Perl: ".", Basic: "&", and so on, and so on ?
 
 --anders
Jan 12 2005
prev sibling next sibling parent reply parabolis <parabolis softhome.net> writes:
Anders F Björklund wrote:


 Just seems that every language needs to use it's own character...
 
 Java: "+", D: "~", Perl: ".", Basic: "&", and so on, and so on ?


I see what you mean. I am just sorry D's character could not 
have been better. Perhaps a better character (for concat) would 
have been '·' (html entity '&middot;').
Jan 12 2005
next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
parabolis wrote:


 I see what you mean. I am just sorry D's character could not have been 
 better. Perhaps a better character (for concat) would have been '·' 
 (html entity '&middot;').


Seems to be hard enough to get people to type a ~ character...

http://www.digitalmars.com/d/faq.html#keys

And that's even before going into non-ASCII characters like ∪.

--anders
Jan 12 2005
parent reply parabolis <parabolis softhome.net> writes:
Anders F Björklund wrote:

 parabolis wrote:
 

 I see what you mean. I am just sorry D's character could not have been 
 better. Perhaps a better character (for concat) would have been '·' 
 (html entity '&middot;').


 
 
 Seems to be hard enough to get people to type a ~ character...
 
 http://www.digitalmars.com/d/faq.html#keys
 
 And that's even before going into non-ASCII characters like ∪.
 
 --anders


http://www.digitalmars.com/d/html.html

Not hard at all if you just type the html entity for the char 
you want. So '&tilde;' should also work - as would '&middot;'.
Jan 12 2005
parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

parabolis wrote:
| Anders F Björklund wrote:
|
|> parabolis wrote:
|>
|>> I see what you mean. I am just sorry D's character could not have
|>> been better. Perhaps a better character (for concat) would have been
|>> '·' (html entity '&middot;').
|>
|> Seems to be hard enough to get people to type a ~ character...
|>
|> http://www.digitalmars.com/d/faq.html#keys
|>
|> And that's even before going into non-ASCII characters like ∪.
|
| http://www.digitalmars.com/d/html.html
|
| Not hard at all if you just type the html entity for the char you want.
| So '&tilde;' should also work - as would '&middot;'.

DMD's HTML code is buggy, works with GDC though ;)

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFB5cK03w+/yD4P9tIRAhpRAKDJQPmgN4CSfMIdqSA8rkwQR3txTACgoiQF
3/d6emRllAksonmi/ipk6QU=
=5NWU
-----END PGP SIGNATURE-----
Jan 12 2005
prev sibling parent "Simon Buchan" <buchan.home ihug.co.nz> writes:
On Wed, 12 Jan 2005 17:10:23 -0500, parabolis <parabolis softhome.net>  
wrote:


 Anders F Björklund wrote:


 Just seems that every language needs to use it's own character...
  Java: "+", D: "~", Perl: ".", Basic: "&", and so on, and so on ?


 I see what you mean. I am just sorry D's character could not have been  
 better. Perhaps a better character (for concat) would have been '·'  
 (html entity '&middot;').


is that · or ‧? Some fonts they are identical :D

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 13 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Anders F Björklund wrote:

 Stewart Gordon wrote:
 

 If James Gosling can overload "plus" (+) to mean string concat,


 
 James Gosling was by no means the first to do it.  But whether it was 
 John Kemeny/Thomas Kurtz or if it caught on since their time isn't 
 clear from my sources.


 
 :-) (I bow to your "Oak" knowledge)


What is "Oak"?


 Just seems that every language needs to use it's own character...
 
 Java: "+", D: "~", Perl: ".", Basic: "&",


Every BASIC I've used has "+" here.  Though Visual Basic has "&" as an 
alternative.

But even a few BASIC manuals that predate VB have conversion guides that 
mention changing "&" to "+", so obviously VB wasn't a first here.  But 
did these others have "&" instead of, or as an alternative to, "+"?

(And apparently some BASICs had "\" as a statement separator instead of 
":".  Does anyone know about this?)


 and so on, and so on ?


Yes.  Fortran: "//"

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 13 2005
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon wrote:
| Anders F Björklund wrote:
|
|> Stewart Gordon wrote:
|>
|>>> If James Gosling can overload "plus" (+) to mean string concat,
|>>
|>>
|>> James Gosling was by no means the first to do it.  But whether it was
|>> John Kemeny/Thomas Kurtz or if it caught on since their time isn't
|>> clear from my sources.
|>
|>
|> :-) (I bow to your "Oak" knowledge)
|
|
| What is "Oak"?

Just guessing:
Your knowledge reaches as far back as that of an old holm oak/ilex.


Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFB5omO3w+/yD4P9tIRAhXrAKC8hrfm6vUr19bAwGAM8ZzIyM6yGgCePBiz
E9uwDoeVrHnG0GzrVirfy+s=
=AU8O
-----END PGP SIGNATURE-----
Jan 13 2005
next sibling parent Ant <Ant_member pathlink.com> writes:
In article <g5eib2-qu3.ln1 lnews.kuehne.cn>, Thomas Kuehne says...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon wrote:
| Anders F Björklund wrote:
|
|> Stewart Gordon wrote:
|>
|>>> If James Gosling can overload "plus" (+) to mean string concat,
|>>
|>>
|>> James Gosling was by no means the first to do it.  But whether it was
|>> John Kemeny/Thomas Kurtz or if it caught on since their time isn't
|>> clear from my sources.
|>
|>
|> :-) (I bow to your "Oak" knowledge)
|
|
| What is "Oak"?

Just guessing:
Your knowledge reaches as far back as that of an old holm oak/ilex.


or

"[java] originally called OAK. "
http://hopl.murdoch.edu.au/showlanguage.prx?exp=2131

Ant
Jan 13 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thomas Kuehne wrote:


 |>> James Gosling was by no means the first to do it.  But whether it was
 |>> John Kemeny/Thomas Kurtz or if it caught on since their time isn't
 |>> clear from my sources.
 |>
 |> :-) (I bow to your "Oak" knowledge)
 |
 | What is "Oak"?
 
 Just guessing:
 Your knowledge reaches as far back as that of an old holm oak/ilex.


Not really, I meant as in the programming language...

See http://java.sun.com/features/1998/05/birthday.html


 The reason *7 was able to control a wide range of entertainment
 platforms and appliances -- while displaying animation -- is that
 it ran on an entirely new, processor-independent language.
 
 The language itself was created by Green Team member James Gosling
 specifically for *7. Gosling called the new language "Oak,"
 after the tree outside his window.


And http://www.ibiblio.org/javafaq/javafaq.html


 The name "Oak" was later dismissed due to a patent search which
 determined that the name was copyrighted and used for another
 programming language. According to Gosling, "the Java development team
 discovered that Oak was the name of a programming language that predated
 Sun's language, so another name had to be chosen."


As of lately, Sun have begun calling *everything* "Java" :

languages, virtual machines, whole server software families,
operating systems, hardware, floor wax, dessert topping ...

--anders


PS. Then I read upon who John Kemeny/Thomas Kurtz were...
     Apparently they discovered the abomination BASIC.
     I somehow thought they were related to Java. :-)
Jan 13 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:


 Just seems that every language needs to use it's own character...

 Java: "+", D: "~", Perl: ".", Basic: "&",


 
 Every BASIC I've used has "+" here.  Though Visual Basic has "&" as an 
 alternative.


Fortunately, I haven't had to use BASIC, Fortran, or COBOL... :-)

I thought Pascal was bad enough.

--anders
Jan 13 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"h3r3tic" <foo bar.baz> wrote in message
news:crv8pk$2jcu$1 digitaldaemon.com...

 //! My 2 bits
 I'd have a different proposal... What might be done, is some more
 checking in the debug build. I'd say this is almost like array bounds
 checking, the null-ness check might be done for the == (and the rest of
 opCmp-defined) operators in debug, but removed in the release build. I'd
 prefer to see a 'nice' error with full info instead of an Access
 Violation. Something like the ArrayBoundsError would be just fine for me.


The null check is being done. It's just being done "for free" by the
hardware. You can also catch access violation exceptions just like any other
exception. There really isn't anything added by doing a redundant check in
software, other than bloat.

P.S. If you compile with -g, and run the program under the debugger, the
debugger will display the location of the access violation and the call
stack leading up to it. I use this capability regularly. It works like a
champ!
Jan 12 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:
<snip>

 P.S. If you compile with -g, and run the program under the debugger, the
 debugger will display the location of the access violation and the call
 stack leading up to it. I use this capability regularly. It works like a
 champ!


What is _the_ debugger?  Where's it found?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 13 2005
parent "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:cs6016$2ih2$2 digitaldaemon.com...

 Walter wrote:
 <snip>

 P.S. If you compile with -g, and run the program under the debugger, the
 debugger will display the location of the access violation and the call
 stack leading up to it. I use this capability regularly. It works like a
 champ!


 What is _the_ debugger?  Where's it found?


You can use gdb under linux, and any codeview compatible debugger (such as
DMC++'s debugger or Windbg.exe) under Windows.
Jan 13 2005
prev sibling parent Daniel Horn <hellcatv hotmail.com> writes:
99% of the time is spent making the test case to spew the access 
violation--once it's there fixing it is trivial.

This should really be turned into a static type checking problem... 99% of
blahobject == null
mistakes will happen because the user is testing equality against the 
null token... thus checking it in the compiler will prevent the problem 
99% of the time before it needs to be reproduced...

This is a feature that I expect for 1.0 because in no case will that 
test do what the user desired...
because if the user desires the function call against null they will and 
can write blahobject.opCmp(null);
The dot syntax makes it extraordinarily clear that unless opCmp is a 
static function (we know it is not from the spec) then it will be an 
access violation if blahobject is null



Walter wrote:

 "h3r3tic" <foo bar.baz> wrote in message
 news:crv8pk$2jcu$1 digitaldaemon.com...
 

//! My 2 bits
I'd have a different proposal... What might be done, is some more
checking in the debug build. I'd say this is almost like array bounds
checking, the null-ness check might be done for the == (and the rest of
opCmp-defined) operators in debug, but removed in the release build. I'd
prefer to see a 'nice' error with full info instead of an Access
Violation. Something like the ArrayBoundsError would be just fine for me.


 
 
 The null check is being done. It's just being done "for free" by the
 hardware. You can also catch access violation exceptions just like any other
 exception. There really isn't anything added by doing a redundant check in
 software, other than bloat.
 
 P.S. If you compile with -g, and run the program under the debugger, the
 debugger will display the location of the access violation and the call
 stack leading up to it. I use this capability regularly. It works like a
 champ!
Jan 14 2005
prev sibling parent Ben Hinkle <Ben_member pathlink.com> writes:
I'd prefer 1) and 2b), what do you think?


or 3) have the compiler explicitly check for null comparisons and issue a ...
ummm what to call it... a compiler-generated bug report... saying that line will
fail if the other value happens to be null. That will catch most ported code. I
know Walter dislikes warnings from compilers so I think I'll call it a
"compiler-generated bug report" :-)
Jan 10 2005