interfaces :-(
Jari-Matti Mäkelä
jmjmak at utu.fi.invalid
Fri Mar 10 03:45:27 PST 2006
Kris wrote:
> In article <durcu5$2ulj$1 at digitaldaemon.com>, John Demme says...
> [snip]
>> C'mon... Can't we do better than this? And actually, it'll only work
>> without ugly casting if you're working with a HashMap:
>>
>> Map!(char[], int) myMap = new HashMap!(char[],int)();
>> Map!(char[], int) originalMap = cast(Map!(char[],int)) myMap.clone();
>>
>> The whole point of the interface, in this case, is to encourage people to
>> disconnect their code from the implemantation of the map; encourage them to
>> use the interface instead.
>
> Exactly. It's unfortunate that Interfaces are still something of a red-headed
> stepchild in D ~ It's not entirely clear that Walter uses Interfaces, or fully
> appreciates their powerful 'contractual' and decoupling aspects. There's no need
> for such tools when you're not working in a reasonably-sized team, or trying to
> build some kind of extensible library (or whatever).
Very true. Semantically these uses guarantee the minimal functionality
of a class instance. That's very valuable property in a proprietary
software library, because the implementation is going to be hidden from
the end user. It's a essential thing in other types of software too.
Think of a RPG world full of players and monsters - it's full of
subclasses and different interfaces. Creatures can cross-breed and do
very complicated things to every possible object. What kind of object
should a class method return then? This "advanced" use of interfaces
prevents the coder from doing anything nasty in a class that knows
nothing special about a passed object reference. The interfaces work as
a greatest common denominator thus preventing the access to any
properties that are "private" on a completely different abstraction level.
Currently very simple operations require awfully lot of casting. It's
definitely not practical to pass only Object references and then do a
heavy amount of test&casting to find out the basic types of the objects.
One other alternative would be to do a switch(class.getTypeInfo) { ... }
to find out the correct casting, but it really makes the whole concept
of interfaces rather pointless.
We can already "emulate" some the functionality of these "advanced"
interfaces by using abstract classes instead of interfaces, but the
problem is that there's no way to emulate multiple inheritance with them.
>
> D interfaces have 'just enough' to make them useful in simple cases. For that,
> they are just fine ~ there's enough functionality there. Perhaps it'll mature?
I really hope so. If Walter doesn't provide any valid alternative or fix
these, I must stop using D and switch to Java or Ruby. I know there are
few people here who appreciate properly implemented interfaces, but I
think a majority of us still don't get this. E.g. simply sorting an
array of interface-type objects should be possible, but it isn't:
Interface[] a;
a ~= new instanceOfInterfaceAndAClass();
a ~= new instanceOfInterfaceAndASecondClass();
a.sort; // segfaults
--
Jari-Matti
More information about the Digitalmars-d-dtl
mailing list