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

[Jonathan M Davis]

On Thursday, July 12, 2012 17:47:10 Mehrdad wrote:
> So if you're saying you can't use const with OOP, then I'm saying
> one of those needs to be fixed, and I was suggesting the former
> as a candidate.

You can use const and OOP together just fine, but that means that if you have a 
function which is marked as const in the base class, and you're operating on 
the objects through the base class pointer, then all of the derived classes 
must be able to have that function as const. In general, I really don' think 
that that's a big deal. The problem is that opEquals, opCmp, toHash, and 
toString affect _all_ classes, because they're in Object, and that 
unnecessarily restricts all classes. const is forced on you, and it's forced 
on you with incredibly common functions in a way that completely disallows 
some idioms (e.g. caching and lazy loading).

On the other hand, if you're dealing with your own class hierarchy, you can 
choose what you're going to mark as const or not, and so you can either forgoe 
const entirely or only use it on functions where you can reasonably require 
that they be const in all classes in that hierarchy. It's not being forced on 
you, and you can pick what works best for your set of classes.

The fact that const is restrictive isn't the problem. It's the fact that const 
is forced on you which is. As long as you have the choice whether to use it or 
not, then it's fine.

- Jonathan M Davis