On Mon, 14 May 2012 02:35:16 -0400, Jakob Ovrum <[email protected]>
wrote:
On Sunday, 13 May 2012 at 17:02:46 UTC, Stewart Gordon wrote:
On 13/05/2012 17:41, Alex Rønne Petersen wrote:
<snip>
I agree with everything but toString(). I'm afraid that forcing
toString() to be const
will have harm flexibility severely. Can't we do better, somehow?
How exactly?
If you're talking about memoization, it ought to be possible to make
use of std.functional.memoize to implement it.
Otherwise, using toString to change the state of an object is bending
semantics. If you want a method to generate a string representation of
an object in a way that might do this, then create your own method to
do it.
Stewart.
How about logically constant opEquals, toString etc? Currently, this is
perfectly possible by just *not using const*. Logical constancy goes
beyond memoization.
This means you cannot compare two const objects.
The issue is, non-const opEquals makes sense on some objects, and const
opEquals makes sense on others. However, you must make them all come
together in Object.opEquals.
I think we already have the hooks to properly compare objects without
requiring Object.opEquals.
Right now, when two objects are compared, the compiler calls
object.opEquals (that's little o for object, meaning the module function
*not* the class method).
So why can't object.opEquals be a template that decides whether to use
Object.opEquals (which IMO *must be* const) or a derived version? I don't
think it's that much of a stretch (not sure if we need a compiler fix for
this).
-Steve
