March 31, 2003
"Walter" <walter@digitalmars.com> wrote in message news:b60uqc$7pi$1@digitaldaemon.com...
>
> "Benji Smith" <Benji_member@pathlink.com> wrote in message news:b5ven6$233d$1@digitaldaemon.com...
> > I wholeheartedly agree. I need to be able to trust that I can use == and
> ===
> > without worrying about access violations for null pointers.
>
> I'm going to disagree with a couple points. First of all, I'm going to disagree with the notion that an access violation is something bad. I
worked
> for 10 years on MSDOS programs were accessing null pointers scrambled the operating system. I *like* having a program bug promptly generate an exception and stop. Those bugs tend to be easy to find. The hard ones are where your program silently continues on chugging, corrupting data, and obfuscating its origins. It's a good thing when cases not accounted for cause exceptions.

I agree that use of null pointers should generate exceptions but ....
>
> The == operator is defined as checking the equivalence of the *contents*
of
> the object references. If the reference is null, it's a program bug and should properly generate an exception. It's analogous to:

isn't null equivilant to null ?

and if nulls are usually programming errors why then can I append to a null
array.
(I like the Java ability to have 0 length arrays)



April 01, 2003
On Mon, 31 Mar 2003 23:15:00 +0000 (UTC), Jonathan Andrew <Jonathan_member@pathlink.com> wrote:
> 
> //in our program
> Object o1, o2;   //by default, &o1 == &null, &o2 == &null
> 
> if(o1 == o2)   //no longer an access violation, since both references are //pointing to a valid object.
> 
> myObj = null;  //now just points to the null object, which is valid.
> 
> To make life simpler, classinfo, toString(), etc. would all just return "null",
> to aid in debugging.
> 
> I'm no language designer or theorist, but this seemed to me to be an easy way to avoid those nasty crashes but still be assured that you will know if an object is uninitialized. Whether or not this is a kludge is up to you guys. =) Do any other languages do this?
> 
> -Jon
> 

Simple, rational, elegant -- it'll never fly.

Karl Bochert


April 01, 2003
Jonathan Andrew wrote:
> //somewhere in memory,
> Object null;
> 
> //in our program
> Object o1, o2;   //by default, &o1 == &null, &o2 == &null
> 
> if(o1 == o2)   //no longer an access violation, since both references are
> //pointing to a valid object. 
> 
> myObj = null;  //now just points to the null object, which is valid.
> 
> To make life simpler, classinfo, toString(), etc. would all just return "null",
> to aid in debugging.
> 
> I'm no language designer or theorist, but this seemed to me to be an easy way
> to avoid those nasty crashes but still be assured that you will know if an
> object is uninitialized. Whether or not this is a kludge is up to you guys. =)
> Do any other languages do this?

  Object Null = new Object;
  Foobar bar = Null;

Null is not a Foobar.  It saves this specific case, but putting incorrect objects in cells is a good way to get bad debug sessions.  At least with ((void*) 0) we can catch bad method calls in the invariant contract.  Also, null has multiple types - it's an object reference, pointer, and empty array.

Has anyone any reasons for not doing the translation method:

   a === b || (a !== null && b !== null && a.eq (b))

Because I think what Matthew's eqi suggestion is going to lead to is an eqi implementation in Object that is identical to this and is almost never overloaded - so a little slower than doing it directly and involving obscure functionality that'll like as not just confuse.

April 01, 2003
> Has anyone any reasons for not doing the translation method:
>
>     a === b || (a !== null && b !== null && a.eq (b))
>
> Because I think what Matthew's eqi suggestion is going to lead to is an eqi implementation in Object that is identical to this and is almost never overloaded - so a little slower than doing it directly and involving obscure functionality that'll like as not just confuse.
>

Why is it slower than doing directly? Surely it'll inline. And please bear in mind that I said it would be an explicit part of the language that the compiler gets to choose whether eq() or eqi() gets called, which in my estimation will mean it'll probably be more efficient. (Walter's quite good at writing optimising compiler's, is he not?)

As I've said earlier, if it was up to me I'd just ditch the eqi() and have
that part implicit. The compiler can do whatever it likes with ==
expressions, but should it need to call your eq() you are guaranteed to be
talking to two (whether one is "this", or it's static) non-null object
instances.



April 03, 2003
Matthew Wilson wrote:
>>Has anyone any reasons for not doing the translation method:
>>
>>    a === b || (a !== null && b !== null && a.eq (b))
>>
>>Because I think what Matthew's eqi suggestion is going to lead to is an
>>eqi implementation in Object that is identical to this and is almost
>>never overloaded - so a little slower than doing it directly and
>>involving obscure functionality that'll like as not just confuse.
> 
> Why is it slower than doing directly? Surely it'll inline. And please bear
> in mind that I said it would be an explicit part of the language that the
> compiler gets to choose whether eq() or eqi() gets called, which in my
> estimation will mean it'll probably be more efficient. (Walter's quite good
> at writing optimising compiler's, is he not?)

You can't inline virtual methods.  Unless if it's final, it'll be a
minor speed burden, and if it is final, then it shouldn't be polluting
Object.

In any case we're not talking about an overhead worth caring much about.
 The big problem is that eqi is a Babel feature; I don't want to spend
hours scanning through code to finally realise that the programmer
overloaded eqi with some new semantics.

April 03, 2003
Then let's dispense with eqi(). I am *very* happy to do so.

That way we can completely leave it to the compiler, with maximal efficiency.


"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b6g21o$28g5$1@digitaldaemon.com...
> Matthew Wilson wrote:
> >>Has anyone any reasons for not doing the translation method:
> >>
> >>    a === b || (a !== null && b !== null && a.eq (b))
> >>
> >>Because I think what Matthew's eqi suggestion is going to lead to is an eqi implementation in Object that is identical to this and is almost never overloaded - so a little slower than doing it directly and involving obscure functionality that'll like as not just confuse.
> >
> > Why is it slower than doing directly? Surely it'll inline. And please
bear
> > in mind that I said it would be an explicit part of the language that
the
> > compiler gets to choose whether eq() or eqi() gets called, which in my
> > estimation will mean it'll probably be more efficient. (Walter's quite
good
> > at writing optimising compiler's, is he not?)
>
> You can't inline virtual methods.  Unless if it's final, it'll be a minor speed burden, and if it is final, then it shouldn't be polluting Object.
>
> In any case we're not talking about an overhead worth caring much about.
>   The big problem is that eqi is a Babel feature; I don't want to spend
> hours scanning through code to finally realise that the programmer
> overloaded eqi with some new semantics.
>


April 09, 2003
Mike Wynn wrote:
> isn't null equivilant to null ?

No. Taken C++:

mytype a, b;
mytype & A = a;
mytype & B = b;
//	...
if (A == B) {}
// here both A and B are first dereferenced, then compared.

If you handle references, how are you going to compare them, when dereferencing one of them already causes an exception?

To compare adress values of references, you would want to say:
if (&A == &B) {}

Or in D with objects, simply
if (A === B) {}

I simply can't see what you don't buy about it.

-i.

April 09, 2003
"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b71res$1541$1@digitaldaemon.com...
> Mike Wynn wrote:
> > isn't null equivilant to null ?
>
> No. Taken C++:
>
> mytype a, b;
> mytype & A = a;
> mytype & B = b;
> // ...
> if (A == B) {}
> // here both A and B are first dereferenced, then compared.
>
> If you handle references, how are you going to compare them, when dereferencing one of them already causes an exception?
>
> To compare adress values of references, you would want to say:
> if (&A == &B) {}
>
> Or in D with objects, simply
> if (A === B) {}
>
> I simply can't see what you don't buy about it.
>
not sure what you thing I've not bought ?

that was my obscure sence of humour, and also question about the semantics of D objects, which are not quite C++ references and not quite Java objects (which are a little basically unchangeable pointers with '.' replacing '->')

( null = = = null ) you agree

should null.eq( null ) [null = = null] be true or throw an exception ?
in java/c++ obj.equals( null ) is usually valid but null.equals( obj ) is
not, why not ?
should the semantics of = =  be  (a = = b) = = = (b = = a).

as I've said b4 I don't believe a language should be driven by implementation, but driven by semantics. (and for me also robustness)



April 10, 2003
> should null.eq(null) [null = = null] be true or throw an exception?

true, because

> language should be driven by ... semantics and ... robustness


You've got me sold.


May 17, 2003
The reason the operator overloads are class members is so they can be virtual.

It might be a good idea to do an "op" prefix to all the operator overloads.

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b638ou$1v3k$1@digitaldaemon.com...
> Agreed.
>
> Although I can understand that Walter may say it's easier for the compiler to parse a named function than the C++'s operator syntax.
>
> If that's the objection, then why not have the python model? There are a limited number of operators in the character set, all of which can be
named.
>
> Your example would then be
>
> BigInt __op_add__ (BigInt a, BigInt b)
> {