Unofficial wish list status.(Jul 2008)

[Michel Fortin]

On 2008-07-24 05:01:37 -0400, Don <nospam at nospam.com.au> said:

> I think it is quite different. The member function is defined inside the class.
> 
> Think what it means for the 'this' parameter to be invariant. Unlike 
> const, it's not conditional. An invariant instance can only call 
> invariant and const member functions; it can never call mutable member 
> functions. Likewise, a non-invariant instance can never call invariant 
> member functions.
> Seems to me, that you've actually defined 2 classes. There could, for 
> example, be completely different vtables for invariant vs mutable 
> instances.
> 
> interface ConstFoo
> {
>    .. constmemberfunctions
> }
> 
> class MutableFoo: ConstFoo
> {
> }
> 
> class InvariantFoo: ConstFoo
> {
> }
> 
> Any instance of Foo is either an instance of MutableFoo, or of InvariantFoo.
> 
> I'm not sure why you wouldn't just make two classes, and apply 
> invariant at the class definition level.

Indeed, and that's pretty much how it is done in Objective-C, and it 
works very well there, except that in Objective-C you generally find 
this pattern:

    abstract class Foo {}
    abstract class MutableFoo : Foo {}
    class PrivateFooImpl : Foo {}
    class PrivateMutableFooImpl : MutableFoo {}

where abstract classes here represent the base class of a class 
cluster[1], providing mainly an interface to build upon.

The downside is that this scheme only works with classes. You can't 
have invariant primitive types this way, and since a D string is a 
primitive type, you still have a need for invariant in D. Basically I 
like all this const/invariant stuff, but I feel the model in 
Objective-C works better for classes.

 [1]: 
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_9.html

-- 


Michel Fortin
michel.fortin at michelf.com
http://michelf.com/