digitalmars.D - Structs implementing interfaces
- Lars Ivar Igesund (17/17) Mar 03 2007 Structs in D are very simple which is good, but in some cases they are j...
Structs in D are very simple which is good, but in some cases they are just too simple. In many cases you would want to handle struct instances as if they were Object derivates, by calling methods on them, methods that implement an interface. The most obvious example is toUtf8 (or toString). As it is now, for instance in a formatter, if it detects that the input is a struct, you have no way of figuring out whether the struct implements an interface or not. This is thus a request to make it possible to say that a struct implements an interface and thus can be typeid'ed on other types (interfaces) than those of the structs themselves. An enumeration of the methods of the struct would also be nice. Thanks :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 03 2007
Lars Ivar Igesund wrote:Structs in D are very simple which is good, but in some cases they are just too simple. In many cases you would want to handle struct instances as if they were Object derivates, by calling methods on them, methods that implement an interface. The most obvious example is toUtf8 (or toString). As it is now, for instance in a formatter, if it detects that the input is a struct, you have no way of figuring out whether the struct implements an interface or not. This is thus a request to make it possible to say that a struct implements an interface and thus can be typeid'ed on other types (interfaces) than those of the structs themselves. An enumeration of the methods of the struct would also be nice. Thanks :)If there are no serious technical reasons not to do this, ++votes; // :) -- Tomasz Stachowiak
Mar 03 2007
BCS <ao pathlink.com> Reply to Tom,Lars Ivar Igesund wrote:The only technical problem with doing this is the way that interfaces are implemented. IIRC when a class implements an interface, a second v-tbl pointer is inserted into the class. The layout of this table is defined by the interface. One of the members (I'll assume the first, but I'm guessing) is the offset between the v-tbl pointer and the beginning of the object. This allows for methods of a class to be called by way of an interfaces something like this: I i; // get fn ptr get this for obj ((*i)[I.method]) ((i + (*i)[0]), /* other args */ ); An alternative implementation that I have floated before would use a pair of pointers, one to the v-tbl and one to the context. A call would look something like this I i; (i.vtbl[I.method])(i.context, /* other args */ ); The down side to this is that it makes a interface instance twice as big and would require all code using interfaces to be recompiled, the up side is that it has no effect what so ever on the layout of the thing that implements the interface. This would allow structs to implement an interface wile still being plain old data. This would also allow for interface literals where the context pointer is a function stack frame as with a delegate.Structs in D are very simple which is good, but in some cases they are just too simple. In many cases you would want to handle struct instances as if they were Object derivates, by calling methods on them, methods that implement an interface. The most obvious example is toUtf8 (or toString). As it is now, for instance in a formatter, if it detects that the input is a struct, you have no way of figuring out whether the struct implements an interface or not. This is thus a request to make it possible to say that a struct implements an interface and thus can be typeid'ed on other types (interfaces) than those of the structs themselves. An enumeration of the methods of the struct would also be nice. Thanks :)If there are no serious technical reasons not to do this, ++votes; // :)-- Tomasz Stachowiak
Mar 04 2007