All right, all right! Interim decision regarding qualified Object methods

[Jonathan M Davis]

On Thursday, July 12, 2012 00:15:48 Andrei Alexandrescu wrote:
> What say you?

If you can figure out how to make this work, it's fine by me.

However, I see two potential issuses which cause currently working idioms to 
no longer work:

1. Anything which wants to be able to operate on Objects generically (e.g. 
have a container full of Objects) is going to have problems, since comparison 
and hashing won't work anymore. For the standard stuff, at minimum, that will 
screw up being able to put Object in AAs and RedBlackTree. For 3rd party 
containers which decided to go the Java route of containing Objects, they risk 
being completely screwed.

For the most part, I think that operating on Objects like that is horrible, 
and we certainly don't encourage it, but it's been possible for ages, so I'm 
willing to bet that there's plenty of code which does it. For instance, what's 
Tango do? As I understand it, they're fairly Java-esque in their general 
approach to things, so it wouldn't entirely surprise me if their containers 
held Object rather than being templated (though the need to hold primitive 
types may have made it so that they didn't go that route).

I don't know whether that inability to do anything with Object beyond hold it 
- no comparison, no nothing - is really acceptable or not. It wouldn't mess up 
anything _I_ do, because I abhor operating on Object - it throws away too much 
type information and encourages bad practices (such as having a container full 
of unrelated types which happen to have the same base class) - but plenty of 
other people do it, and it won't be possible anymore.

2. Will this work with toString? How much stuff relies on being able to get a 
string from Object? We've been switching everything in Phobos over to use 
variadic templates, which should make it easy enough to get around that 
problem (presumably, classes are then in the same boat as structs which don't 
define toString), but we may have older functions which will run into problems 
with this, and some stuff in other libraries could be completely screwed by 
this. Again, what does Tango do? Does it use variadic templates for its print 
function, or does it use D style variadics? At first glance, it seems to me 
that getting rid of toString on Object would screw over its use with D style 
variadics. That may or not be true, but if it is, we're closing doors on stuff 
which currently works.

So, I think that it's probably a solid way to go, and it does appear to solve 
the const issues that we've been having quite nicely, but it also appears to 
break a number of things which have worked for some time, and we're going to 
have to figure out how we're going to deal with that, even if it's only 
providing a good deprecation path.

- Jonathan M Davis


P.S. I think that we should still keep how the free function opEquals 
currently works with regards to comparing Objects of differing types. The 
comparison won't work with Object anymore, but classes which have opEquals 
will still have polymorphic opEquals, and I think that all of that great logic 
that we thought up to solve some of the problems that Java has with that 
should be kept. So, if anyone was thinking that that only existed because 
Object has opEquals on it and that it would be unnecessary now, I completely 
disagree.