Re: Preventing type extensions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 22 Sep 2010 21:41:35 +0200, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>>>> No, the actual problem here is re-dispatch. Just do not do that, it is
>>>> always bad.
>>> 
>>> How do you suggest to avoid redispatch?  Make non-dispatching calls to
>>> dispatching subprograms?
>>
>> Yes.
>>
>>> And how does this address the issue?
>>
>> Because nothing can get broken by overriding, all targets are resolved.
> 
> Perhaps not directly, but you still have the problem that you make the
> extension because you want a behavioral change, and that change may
> break other things.

No, the point is that it cannot break existing code, because it is
statically resolved and frozen. In Ada freezing is accomplished
automatically by default. Any implementation in is frozen.

You can use the implementation inappropriately, but that is your problem as
a user. When you call sine instead of cosine you do not break either, you
do your code only.

> (And unlike Objective Caml, Ada has downcasts, so
> the fact that there are unblessed extensions is very visible even
> without resorting to non-portable bit fiddling.)

That is another issue. In my opinion Ada should abstract all operations of
the type. E.g. member access, pointer types evaluation, attributes etc.
Conversion to a derived interface is another candidate to become a
primitive operation, which you as a provider of the derived type should be
able to override in order to have a finer control over downcasting.

>>> It makes it more likely that you cannot write a useful extension.
>>
>> Why? I can override anything I need.
> 
> Yes, but you may have to copy source code from the parent type's
> implementation because it won't pick up your new code automatically.

I can reuse parent's operations by calling them explicitly.

> Back in mid-90s, there was a thought that it should be possible to
> subclass all (public) classes and override all (public) methods.  This
> design is still followed by the JDK.  I think this is quite the wrong
> way to do OO.

Yes, I stick to the design rule: override once.

>>> Wouldn't it be better not to hide this aspect in the implementation?
>>
>> This does not compute to me. Are you saying that if an operation gets
>> broken upon extension you won't allow to override it? (And if it is not
>> broken, why do you care?)
> 
> I want to make an explicit statement, "I do not support extending this
> type" because I do not want to have the additional maintenance burden
> of this dependency (or the debugging necessary because other code
> breaks because there is an unexpected extension).

That is not your business as a provider of the type. You cannot foresee
further uses of the type and there is no burden on your side anyway. You
publish the interfaces and provide some implementation for, and then you
leave. 

>  I can write this in
> a comment, but I think it's better to make such things explicit in the
> interface.

Nope, as I already wrote in a subthread, the contract is between someone
who extends the type and someone who uses it. You are not involved.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de