Re: Preventing type extensions

["J-P. Rosen" <rosen@adalog.fr>]

Le 21/09/2010 15:57, Cyrille a �crit :
> On Sep 13, 11:13 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:
> 
>> These arguments make sense for languages without the notion of
>> class-wide types.
> 
> all OO languages I'm aware of, have the notion of classwide types...
> They just don't make the distinction between a type on its own and a
> type with its derived types. 
That's exactly what I meant: they don't have a /distinct/ notion for
class-wide type.

> If you think about it, it is a peculiar
> distinction at the "design" level.
To distinguish a node from the subtree generated by this node? Does not
seem peculiar to me

> A horse is an animal... When I deal
> with animals, I must be ready to accept that maybe the animal I'm
> dealing with may be a horse, or may be something else. It's peculiar
> to expect it to be the pure notion of "animal" and nothing else...
I don't understand the argument here. Clearly, "Animal" should be
abstract, and you can deal only with Animal'Class.

>> However, I think that redispatching can be replaced
>> with class-wide operations, with great benefits from the POV of testing.
> 
> In some cases, it may be true. Generally speaking, it is an important
> to distinguish between primitive operrations and class wide
> operations. They both have their use. If you are suggesting the rule
> "any primitive operation that calls another primitive op of the same
> type (that usually is when redispatch should occur) must be
> transformed into a class-wide operation", I'm afraid this is a fierce
> restriction... much fiercer than the simple dispatch rule... which
> imposes one particular style of programming.
No, since the class-wide operation can contain a single (re-dispatching)
call. What's the gain? We have concentrated the dispatching into a
single subprogram. This subprogram can be tested in isolation, and
stubbed in all users. Otherwise, under the "big case" model, every user
must be tested for all branches of the "big case". In a sense, it is the
opposite effect of inlining. Take the arguments against inlining, you'll
have the justification for this strategy.

>> Cyril, will you come to the workshop? That would be very valuable.
> 
> No, I don't plan to go. Note that on our side, we are already working
> on our own set of recommendations... maybe we should try to find a
> vehicle more permanent than a conference to make a community effort on
> this...
The workshop at the conference is the starting point for a document that
will define appropriate restrictions ("Fairfax profile"). Starting such
an effort during an Ada conference seems absolutely appropriate. If
AdaCore has plans along the same line, by all means, send someone to the
workshop (if you can't come - which I regret, since I know that you are
deeply involved on this topic).

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00