Community

"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)

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

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.

> 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.

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.

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.
>

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.

"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)

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)
> {