On Tuesday, March 19, 2013 02:17:28 Peter Williams wrote: > Am I right in thinking that removal of these methods from Object > will mean that it will no longer be necessary for the the > argument to be of type Object and that the need for casting in > the implementation will go away?
Well, IIRC, if when you override a function, and you give it a different parameter type, it's a new overload rather than actually overriding anything (even if the type of the parameter in the derived type's function is a derived type of the type of the parameter in the base class' function). So, if you don't use a common type for the parameter, you'll run into overload conflicts regardless. So, while you _could_ use something other than Object, you could run into overload conflicts if you do. That can be gotten around by aliasing base class functions into the scope of the derived class (though that may cause derived types to be compared as base types if they're referred to via references to the base type, so that may no be a good idea) or by creating overloads for comparing every base class, but it's arguably easier to just accept Object and cast - or accept whatever the base type is which first introduces opEquals into the hierarchy. So, there's a good chance that what you'll end up doing is using the base type in the hierarchy which introduces opEquals as the parameter for opEquals. This is better than using Object in that it'll avoid having completely unrelated types even be comparable (as their opEquals wouldn't accept each other), but it would still require derived types to use that type as the parameter type for opEquals for the reasons mentioned above. - Jonathan M Davis