On Wednesday, 11 July 2012 at 15:27:55 UTC, Andrei Alexandrescu
wrote:
I think I'll find it rather difficult to get behind modeling
arbitrary escapes from immutability. If you want classes, you
buy into a certain contract with inherent rights and
constraints (starting with using references). It's a given, and
again I find it unreasonable to ask that classes allow for
arbitrary customization.
Some classes don't lend themselves to immutability. Let's take
something obvious like a class object representing a dataset in a
database. How is an immutable instance of such a class useful?
The solution to this problem is obvious and right there for us to
use, the only thing arbitrary here is the limitation we put on
classes by not using it.
Your LuaD example goes like this:
/**
* Compare this object to another with Lua's equality
semantics.
* Also returns false if the two objects are in different
Lua states.
*/
bool opEquals(T : LuaObject)(ref T o) @trusted
{
if(o.state != this.state)
return false;
push();
o.push();
scope(success) lua_pop(state, 2);
return lua_equal(state, -1, -2);
}
You may be able to make this work by putting the state
associated with push() and pop() in the Cache subsystem.
Sounds like the kind of workaround people would accompany with a
nasty comment.
If all else breaks, have opEquals assert(false, "Call bool
lua_equals()").
This is exactly what I was talking about earlier. opEquals failed
me for no good reason, so I'm begrudgingly going to leave an
assert behind and give up, writing my own method. As mentioned,
this has far-reaching consequences for anything that relies on
opEquals.
We can't really model every possible design.
No, but apparently we can model this one quite readily.
