property magic for inerfaces (please!)

Kristian Kilpi kjkilpi at gmail.com
Sun Nov 19 04:43:48 PST 2006


On Sun, 19 Nov 2006 13:27:14 +0200, Reiner Pope  
<reiner.pope at gmail.REMOVE.com> wrote:

> == Quote from Lionello Lunesu (lionello at lunesu.remove.com)'s article
>> What if getChildren() is a costly function, that, say, does an SELECT  
>> on a
>> remote database? You would not want it to have that particular
>> implementation since it would not need to collect the children first,  
>> just
>> to check whether there are any.
>> Unfortunately, the only correct way to work with interfaces *is*  
>> declaring
>> all the functions virtual. You want to do getChildren().length because  
>> you
>> already know the implementation of getChildren, which is not a fair way  
>> to
>> look at it.
>> L.
>
> But you could apply this sort of argument ("we want to allow people to  
> implement
> it differently") everywhere so, by that logic, we shouldn't have final  
> methods,
> since there *might* sometime be a reason to reimplement them (and you  
> could even
> extend this argument to disallow every function which isn't a class,  
> since none of
> them involve a virtual function lookup!). There is a limit to how much  
> flexibility
> can be achieved in an API, and it is sometimes useful to final methods.  
> If the
> interface expects that getChildren will run in a reasonable time, then  
> it violates
> the Liskov Substitution principle if an implementing class takes too  
> long on it.
>
> Cheers,
>
> Reiner


Well said.

But why should functions defined in an interface to be final? They could  
be 'copied' to a class creating virtual functions just like mixins do.

This way you could use interfaces to create final functions and default  
implemenations for virtual functions. No need to split an interface to a  
mixin + interface definitions.



More information about the Digitalmars-d mailing list