Pointers, casting, SetGetWindowLong problem...

[Chris Warwick]

"Frits van Bommel" <fvbommel at REMwOVExCAPSs.nl> wrote in message 
news:est2j6$1f2d$1 at digitalmars.com...
> Chris Warwick wrote:
>> "Derek Parnell" <derek at psych.ward> wrote in message 
>> news:1f2c01vt6zeaq$.ac8d0velaphe$.dlg at 40tude.net...
>>> On Fri, 9 Mar 2007 23:16:34 -0000, Chris Warwick wrote:
>>>
>>>>     if (window == null)  return DefWindowProcA(handle, msg, wparam, 
>>>> lparam);
>>>>
>>>> but i keep getting an access violation on the if (window == null),
>>>>
>>> Use this instead ...
>>>
>>>    if (window is null) ...
>>>
>>> Because ...
>>>
>>>    if (window == null)
>>>
>>> is identical to
>>>
>>>    if (window.opEquals(null))
>>>
>>> which will fail if 'window' is null because it needs to use it to 
>>> reference
>>> the opEquals method.
>>
>> So opEquals must be inherited from Object cause I havnt implememented it 
>> in my class. So what exactly does this inherited opEquals do? How can an 
>> inherited opEquals have any sensible result in descendant classes unless 
>> overriden by those subclasses?
>
> Ironically, it returns the result of "this is other" :P.
> Unfortunately, execution never gets that far when the left-hand side of 
> '==' actually *is* null...
> But yes, that method is indeed meant to be overridden by most classes that 
> want to be equality-comparable.

Seems odd that it's even implemented at all, = is not overloadable if i 
understood the docs right, 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).

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