March 10, 2007
"Chris Warwick" <sp@m.me.not> wrote in message news:est492$1igu$1@digitalmars.com...
>
> Seems odd that it's even implemented at all, = is not overloadable if i understood the docs right,

Nope, it's assignable with opAssign.  There are restrictions, but it can be overloaded.

> and I cant see add or sub being overloaded in Object.. So why implement opEquals? Especialy when it's basicly worse than (obj1 is obj2).

It's implemented for associative arrays to work properly.

> Unless it's a cunning ploy, using AV faults to cattle prod people into using 'is'.

Well == and 'is' have two entirely different purposes.  == is only for seeing if two things have the same _value_, while 'is' is used to see if _two references point to the same instance_.  == is perfectly fine to use on class instances -- as long as they're not null!  It's just like any other method.


March 10, 2007
Bradley Smith wrote:
> I've started recording "surprises" like these on a Web page here: http://www.baysmith.com/d/

That's a good idea, but I see a couple of errors on that page.

At the bottom: "crashes because null not evaluated as false".  null does evaluate to false.  The reason it crashes is that assert(obj) doesn't check for null, it just calls the class invariant. http://www.digitalmars.com/d/class.html#invariants

And "Don't use == to compare with null" can be a bit misleading.  If the object has an opEquals defined that takes a reference as an argument, you would actually "use == to compare with null".  Maybe if it said "Don't use == to check if a reference is null".

But it's a nice initiative nevertheless.  The official docs are a bit unclear on many issues.
March 10, 2007
On Sat, 10 Mar 2007 03:06:46 +0200, Bradley Smith <digitalmars-com@baysmith.com> wrote:

> Bill Baxter wrote:
>> This is definitely an F.A.Q.
>> Is there a D Programming FAQ anywhere?
>> 'Why does "if (someobject == null)" keep crashing?' would definitely be there.
>> What else?
>>  --bb
>
> I've started recording "surprises" like these on a Web page here: http://www.baysmith.com/d/
>
>    Bradley


The comment of the following line:

  ContainsResource res1; //  Error: variable scope.main.res1 reference to auto class must be auto

uses the 'auto' keyword instead of 'scope'.

(Or is the error message of the compiler out of date?)
March 10, 2007
"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:est9bb$1pac$1@digitalmars.com...
> "Chris Warwick" <sp@m.me.not> wrote in message news:est492$1igu$1@digitalmars.com...
>>
>> Seems odd that it's even implemented at all, = is not overloadable if i understood the docs right,
>
> Nope, it's assignable with opAssign.  There are restrictions, but it can be overloaded.

For objects? Wouldnt that make assigning to a null object imposible?

MyObj obj = obj2;

if opAssign is overloaded that will always be

null.opAssign(obj2);

wont it?


>> and I cant see add or sub being overloaded in Object.. So why implement opEquals? Especialy when it's basicly worse than (obj1 is obj2).
>
> It's implemented for associative arrays to work properly.
>
>> Unless it's a cunning ploy, using AV faults to cattle prod people into using 'is'.
>
> Well == and 'is' have two entirely different purposes.  == is only for seeing if two things have the same _value_, while 'is' is used to see if _two references point to the same instance_.  == is perfectly fine to use on class instances -- as long as they're not null!  It's just like any other method.

Just feels kinda wrong to me. Objects are referance types, passed by, and managed by referance, so imo == and = should test and assign referance not value.

Although i guess it does seem logical to make a clearer distinction between equality and identity, so maybe ill get used to it.

cheers,

cw


March 10, 2007
Chris Warwick wrote:
> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:est9bb$1pac$1@digitalmars.com...
>> Nope, it's assignable with opAssign.  There are restrictions, but it can be overloaded.
> 
> For objects? Wouldnt that make assigning to a null object imposible?
> 
> MyObj obj = obj2;
> 
> if opAssign is overloaded that will always be
> 
> null.opAssign(obj2);
> 
> wont it?

No, one of the restrictions Jarrett mentioned is that an overloaded opAssign is only invoked if the type of the value assigned is different from the type of the variable it's assigned to.
If they have the same type (or the assigned value is implicitly convertible to the type of the variable) the user-defined opAssign isn't used.
March 10, 2007
"Chris Warwick" <sp@m.me.not> wrote in message news:esu8ah$4uj$1@digitalmars.com...
>
> Just feels kinda wrong to me. Objects are referance types, passed by, and managed by referance, so imo == and = should test and assign referance not value.

= does assign reference, except if opAssign is overloaded (I don't like opAssign with classes for that reason; for structs it makes more sense). The nice thing about having '==' vs. 'is' for reference types is that you don't have to write

if(obj1.equals(obj2))
    // ...

like in certain other languages.

On a side note, I just like the way 'is' reads more than '=='.  And you can even use it with non-reference types, where it acts just like '==', so you can write things like

if(x is 5)

Which just looks great IMO :)


March 10, 2007
Kristian Kilpi wrote:
> On Sat, 10 Mar 2007 03:06:46 +0200, Bradley Smith <digitalmars-com@baysmith.com> wrote:
>
>> I've started recording "surprises" like these on a Web page here: http://www.baysmith.com/d/
>>
>>    Bradley
> 
> 
> The comment of the following line:
> 
>   ContainsResource res1; //  Error: variable scope.main.res1 reference to auto class must be auto
> 
> uses the 'auto' keyword instead of 'scope'.
> 
> (Or is the error message of the compiler out of date?)


Perhaps, but the above is the error message from DMD v1.007.
March 10, 2007
torhu wrote:
> Bradley Smith wrote:
>> I've started recording "surprises" like these on a Web page here: http://www.baysmith.com/d/
> 
> That's a good idea, but I see a couple of errors on that page.
> 
> At the bottom: "crashes because null not evaluated as false".  null does evaluate to false.  The reason it crashes is that assert(obj) doesn't check for null, it just calls the class invariant. http://www.digitalmars.com/d/class.html#invariants
> 
> And "Don't use == to compare with null" can be a bit misleading.  If the object has an opEquals defined that takes a reference as an argument, you would actually "use == to compare with null".  Maybe if it said "Don't use == to check if a reference is null".
> 
> But it's a nice initiative nevertheless.  The official docs are a bit unclear on many issues.

Thanks for the feedback. I've updated these points.
March 11, 2007
On Sat, 10 Mar 2007 22:58:02 +0200, Bradley Smith <digitalmars-com@baysmith.com> wrote:

> Kristian Kilpi wrote:
>> On Sat, 10 Mar 2007 03:06:46 +0200, Bradley Smith <digitalmars-com@baysmith.com> wrote:
>  >
>>> I've started recording "surprises" like these on a Web page here: http://www.baysmith.com/d/
>>>
>>>    Bradley
>>   The comment of the following line:
>>    ContainsResource res1; //  Error: variable scope.main.res1 reference to auto class must be auto
>>  uses the 'auto' keyword instead of 'scope'.
>>  (Or is the error message of the compiler out of date?)
>
>
> Perhaps, but the above is the error message from DMD v1.007.

Ok, when the 'auto' keyword was changed to 'scope', the error message
(at least this one) wasn't updated. I wonder if Walter knows about it.

1 2
Next ›   Last »