On 2011-02-10 04:36:56 -0500, Don <nos...@nospam.com> said:
so wrote:
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be
marked const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
unless we also state that every function in Object must be const and
accept the fact that no one would use these functions for other
purposes like caching, late binding etc...
I can think of many examples where opEquals would be logically pure,
but not formally pure, but it's harder to come up with ones where it is
not const. I guess you can have situations where a lazily-computed hash
value is cached in the object, to speed up comparisons, but it doesn't
seem inappropriate for casts to be required when you're doing that.
Can you think of a use case where the calling function should know that
opEquals() isn't truly const?
If you use casts on some member variables, make sure the member is
marked shared don't forget to cast to shared mutable, not just mutable,
because you never know when your immutable object is shared between
threads. Suggesting casts looks error prone to me, but it can probably
work.
To answer the original question, yes opCmp, opEquals, toHash, toString
should all be const. Otherwise it makes it impossible to use
const/immutable objects in any generic code requiring those functions
to be available. And generic code will otherwise work perfectly fine
with non-mutable objects once Walter merges my const(Object)ref patch
in the mainline.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
