Required reading prior to this: http://goo.gl/eXpuX

You destroyed, we listened.

I think Christophe makes a great point. We've been all thinking inside the box but we should question the very existence of the box. Once the necessity of opCmp, opEquals, toHash, toString is being debated, we get to some interesting points:

1. Polymorphic comparisons for objects has problems even without considering interaction with qualifiers. I wrote quite a few pages about that in TDPL, which add to a lore grown within the Java community.

2. C++ has very, very successfully avoided the necessity of planting polymorphic comparisons in base classes by use of templates. The issue is template code bloat. My impression from being in touch with the C++ community for a long time is that virtually nobody even talks about code bloat anymore. For whatever combination of industry and market forces, it's just not an issue anymore.

3. opCmp, opEquals, and toHash are all needed primarily for one thing: built-in hashes. (There's also use of them in the moribund .sort method.) The thing is, the design of built-in hashes predates the existence of templates. There are reasons to move to generic-based hashes instead of today's runtime hashes (such as the phenomenal success of templated containers in C++), so it can be argued that opCmp, opEquals, and toHash exist for reasons that are going extinct.

4. Adding support for the likes of logical constness is possible, but gravitates between too lax and onerously complicated. Walter and I don't think the aggravation is justified.

There are of course more angles and considerations. Walter and I discussed such for a while and concluded we should take the following route:

1. For the time being, rollback the changes. Kenji, could you please do the honors? There's no need to undo everything, only the key parts in object.d. Apologies for having to undo your work!

2. Investigate a robust migration path from the current use of opCmp, opEquals, toHash (we need to also investigate toString) to a world in which these methods don't exist in Object. In that world, associative arrays would probably be entirely generic. Ideally we should allow existing code to still work, while at the same time fostering a better style for new code.


What say you?

Andrei

On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu wrote:
> Required reading prior to this: http://goo.gl/eXpuX

Referenced post (for context):
>> The problem is not only in the constness of the argument, but also in
its purity, safety, and throwability (although the last two can be
worked arround easily).



I think we're looking at the wrong problem here.


If we're trying to escape problems with 'const' Objects by removing the members form Object entirely, that should be raising a red flag with const, not with Object.

I say: finally.  I've long felt that Object was already too heavy, but hadn't worried about it much in years (since there was no apparent solution at that time).  Just as notifyRegister/notifyUnRegister were eventually moved out to the runtime, it should be possible to do the same for these, if we cannot just obviate them outright.

On 07/12/2012 06:15 AM, Andrei Alexandrescu wrote:
> Required reading prior to this: http://goo.gl/eXpuX
>
> You destroyed, we listened.
>
> I think Christophe makes a great point.

+1.

> We've been all thinking inside
> the box but we should question the very existence of the box. Once the
> necessity of opCmp, opEquals, toHash, toString is being debated, we get
> to some interesting points:
>
> 1. Polymorphic comparisons for objects has problems even without
> considering interaction with qualifiers. I wrote quite a few pages about
> that in TDPL, which add to a lore grown within the Java community.
>
> 2. C++ has very, very successfully avoided the necessity of planting
> polymorphic comparisons in base classes by use of templates. The issue
> is template code bloat. My impression from being in touch with the C++
> community for a long time is that virtually nobody even talks about code
> bloat anymore. For whatever combination of industry and market forces,
> it's just not an issue anymore.
>
> 3. opCmp, opEquals, and toHash are all needed primarily for one thing:
> built-in hashes. (There's also use of them in the moribund .sort
> method.) The thing is, the design of built-in hashes predates the
> existence of templates. There are reasons to move to generic-based
> hashes instead of today's runtime hashes (such as the phenomenal success
> of templated containers in C++), so it can be argued that opCmp,
> opEquals, and toHash exist for reasons that are going extinct.
>
> 4. Adding support for the likes of logical constness is possible, but
> gravitates between too lax and onerously complicated. Walter and I don't
> think the aggravation is justified.
>
> There are of course more angles and considerations. Walter and I
> discussed such for a while and concluded we should take the following
> route:
>
> 1. For the time being, rollback the changes. Kenji, could you please do
> the honors? There's no need to undo everything, only the key parts in
> object.d. Apologies for having to undo your work!
>
> 2. Investigate a robust migration path from the current use of opCmp,
> opEquals, toHash (we need to also investigate toString) to a world in
> which these methods don't exist in Object. In that world, associative
> arrays would probably be entirely generic. Ideally we should allow
> existing code to still work, while at the same time fostering a better
> style for new code.
>
>
> What say you?
>
> Andrei

Thank you for taking the time.

Removing the default methods completely is actually a lot better than making inheriting from Object optional or tweaking const beyond recognition and/or usefulness.
I was afraid to suggest this because it breaks all code that assumes
that the methods are present in object (most code?), but I think it is
a great way to go forward.

Regarding toString, getting rid of it would imply that the default way
of creating a textual representation of an object would no longer be
part of Object, paving the way for the proposal that uses buffers and
scope delegates - this will be purely a library thing.

Regarding backwards-compatibility, an issue that is trivial to fix is
the invalidation of 'override' declarations in the child classes.
They can be allowed with the -d switch for those methods. And if they
use 'super', the compiler could magically provide the current default
implementations.

Timon Gehr , dans le message (digitalmars.D:172014), a écrit :
> Thank you for taking the time.
> 
> Removing the default methods completely is actually a lot better than
> making inheriting from Object optional or tweaking const beyond
> recognition and/or usefulness.
> I was afraid to suggest this because it breaks all code that assumes
> that the methods are present in object (most code?), but I think it is
> a great way to go forward.

It's not worse thant breaking all code that overrides opEqual by changing it's signature.

> Regarding toString, getting rid of it would imply that the default way of creating a textual representation of an object would no longer be part of Object, paving the way for the proposal that uses buffers and scope delegates - this will be purely a library thing.

I agree. toString should be a purely library solution. The standard library could easily use templates trying to use different ways to print the the object, depending on what methods are implemented for that object: direct conversion to string/wstring/dstring, a standard method using delegates, etc.

> Regarding backwards-compatibility, an issue that is trivial to fix is the invalidation of 'override' declarations in the child classes. They can be allowed with the -d switch for those methods. And if they use 'super', the compiler could magically provide the current default implementations.

Magic is not good for langage consistency. I would rather do a different fix:

Introduce a class in the standard library that is like the current Object. To correct broken code, make all classes inheriting from Objet inherit from this new class, and rewrite opEqual/opCmp to take this new class as an argument instead of Object. This can be done automatically.

People may not want to use that fix, but in that case, we don't have to implement a magical behavior with super. What can be used is deprecation: if I someone uses super.opEqual (meaning Object.opEqual), and others, he should bet a warning saying it's deprectated, with explanations on how to solve the issue.

A possible course of action is this:
 - revert changes in Object (with renewed apologies to people having
worked on that)
 - introduce a class implementing basic Hashes functions with the
current signatures. (A class with the new signatures could be provided
too, making use of the late work on Object, which would not be
completely wasted after all)
 - introduce a deprecation warning on uses of Object.opEqual and
friends, informing the programmer about the possibility to derive from
the new class to solve the issue.
 - in the mean time, make the necessary changes to enable classes not to
have those methods (like structs)
 - after the deprecation period, remove Object.opEqual and friends.

"Mehrdad" , dans le message (digitalmars.D:172012), a écrit :
> On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu wrote:
>> Required reading prior to this: http://goo.gl/eXpuX
> 
> Referenced post (for context):
>>> The problem is not only in the constness of the argument, but also in
> its purity, safety, and throwability (although the last two can be
> worked arround easily).
> 
> I think we're looking at the wrong problem here.
> 
> If we're trying to escape problems with 'const' Objects by removing the members form Object entirely, that should be raising a red flag with const, not with Object.

const has no problem. It is bitwise const, and it works like that. Logical const is not implemented in D, but that is a separate issue.

The problem is to force people to use const, because bitwise const may not be suited for their problems. If opEquals and friends are const, then D forces people to use bitwise const, and that is the problem, that is largely widened by the fact that bitwise transitive const is particularly viral. But if we do not impose to implement any const methods, the problem disappear.

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.

On 12/07/12 06:15, Andrei Alexandrescu wrote:
> Required reading prior to this: http://goo.gl/eXpuX
>
> You destroyed, we listened.
>
> I think Christophe makes a great point. We've been all thinking inside
> the box but we should question the very existence of the box. Once the
> necessity of opCmp, opEquals, toHash, toString is being debated, we get
> to some interesting points:
>
> 1. Polymorphic comparisons for objects has problems even without
> considering interaction with qualifiers. I wrote quite a few pages about
> that in TDPL, which add to a lore grown within the Java community.
>
> 2. C++ has very, very successfully avoided the necessity of planting
> polymorphic comparisons in base classes by use of templates. The issue
> is template code bloat. My impression from being in touch with the C++
> community for a long time is that virtually nobody even talks about code
> bloat anymore. For whatever combination of industry and market forces,
> it's just not an issue anymore.
>
> 3. opCmp, opEquals, and toHash are all needed primarily for one thing:
> built-in hashes. (There's also use of them in the moribund .sort
> method.) The thing is, the design of built-in hashes predates the
> existence of templates. There are reasons to move to generic-based
> hashes instead of today's runtime hashes (such as the phenomenal success
> of templated containers in C++), so it can be argued that opCmp,
> opEquals, and toHash exist for reasons that are going extinct.
>
> 4. Adding support for the likes of logical constness is possible, but
> gravitates between too lax and onerously complicated. Walter and I don't
> think the aggravation is justified.
>
> There are of course more angles and considerations. Walter and I
> discussed such for a while and concluded we should take the following
> route:
>
> 1. For the time being, rollback the changes. Kenji, could you please do
> the honors? There's no need to undo everything, only the key parts in
> object.d. Apologies for having to undo your work!
>
> 2. Investigate a robust migration path from the current use of opCmp,
> opEquals, toHash (we need to also investigate toString) to a world in
> which these methods don't exist in Object. In that world, associative
> arrays would probably be entirely generic. Ideally we should allow
> existing code to still work, while at the same time fostering a better
> style for new code.
>
>
> What say you?
>
> Andrei

Well:
* having opCmp() defined for all objects is just plain weird.
* toString() is a poor design anyway.

But we'd need to be very careful, this is a very disruptive change.

On Thursday, 12 July 2012 at 08:40:25 UTC, Jonathan M Davis wrote:
> it does appear to solve the const issues that we've been having quite nicely


How would we expect people to deal with these const issues when the issues come up in their own libraries?

Or do we not care?

On Thursday, July 12, 2012 11:07:42 Mehrdad wrote:
> On Thursday, 12 July 2012 at 08:40:25 UTC, Jonathan M Davis wrote:
> > it does appear to solve the const issues that we've been having quite nicely
> 
> How would we expect people to deal with these const issues when the issues come up in their own libraries?
> 
> Or do we not care?

The issue that we're trying to solve here is making opEquals, opCmp, toHash, and toString work both for const and non-const objects. That's it. We're not talking about revamping const. It doesn't need it. I know that you're unhappy with how const works in D, but as a group, we do not believe that it is fundamentally broken. Rather, this particular situation where OO and const collide needs a solution. _That_ is what we're trying to solve.

That may mean that you can't use const in your code, because what you're trying to doesn't work with D's const. But taking care of this issue with opEquals, opCmp, toHash, and toString will make avoiding const easier for those that need to for their particular code base.

- Jonathan M Davis