Abusing tagged types

Abusing tagged types

[Maciej Sobczak]

Is it considered to be a good practice to make a given type tagged
only to benefit from the Object.Operation notation in Ada 2005?

Let's say there is a library where there are several types. Some of
them are inherently tagged due to their design and they allow Obj.Oper
notation out of the box. For others there is no design motivation to
make them tagged (no dispatching calls for them, no Controlled, etc.)
and as a result the whole library does not "feel" consistent, since
Obj.Oper is not available across all exposed types.

The type can be made tagged *only* to get the syntax sugar.
Is it considered to be an abuse of the language feature?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Abusing tagged types

[Samuel Tardieu]

>>>>> "Maciej" == Maciej Sobczak <see.my.homepage@gmail.com> writes:

Maciej> The type can be made tagged *only* to get the syntax sugar.
Maciej> Is it considered to be an abuse of the language feature?

This will increase the memory size of every instance. Even if no
dispatching is used the tag will be stored in each object because
dispatching *could* be used.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: Abusing tagged types

[Maciej Sobczak]

On 28 Lis, 11:50, Samuel Tardieu <s...@rfc1149.net> wrote:

> Maciej> The type can be made tagged *only* to get the syntax sugar.
> Maciej> Is it considered to be an abuse of the language feature?
>
> This will increase the memory size of every instance. Even if no
> dispatching is used the tag will be stored in each object because
> dispatching *could* be used.

Let's say that in this case it does not matter anyway.

I'm asking about the design principles - the *purpose* of tagged type
is to achieve polymorphism with dispatching calls. Is it OK to use
tagged type without this motivation?
(well, Controlled is also in this category...)

By the way - what is the rationale for allowing Obj.Operation only for
tagged types and not for all types? "Ada 2005 Rationale" does not seem
to explain this.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Abusing tagged types

[Ludovic Brenta]

Maciej Sobczakwrote:
> By the way - what is the rationale for allowing Obj.Operation only for
> tagged types and not for all types? "Ada 2005 Rationale" does not seem
> to explain this.

Actually it does but I find the explanation a bit cryptic for untagged
types other than access types:

"Other variations on the rules for the use of the notation were
considered. One was that the mechanism should apply to untagged types
as well but this was rejected on the grounds that it might add to
rather than reduce confusion in some cases. In any event, untagged
types do not have class wide types so they are intrinsically simpler.
It would have been particularly confusing to permit the notation to
apply to access types especially an access type A referring to a
tagged type T. If the access type and the tagged type both had the
same or similar operations Op then ambiguities or errors could easily
arise."

Maybe the AI has more details.

--
Ludovic Brenta.

Re: Abusing tagged types

[Adam Beneschan]

On Nov 28, 6:08 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Maciej Sobczakwrote:
>
> > By the way - what is the rationale for allowing Obj.Operation only for
> > tagged types and not for all types? "Ada 2005 Rationale" does not seem
> > to explain this.
>
> Actually it does but I find the explanation a bit cryptic for untagged
> types other than access types:
>
> "Other variations on the rules for the use of the notation were
> considered. One was that the mechanism should apply to untagged types
> as well but this was rejected on the grounds that it might add to
> rather than reduce confusion in some cases. In any event, untagged
> types do not have class wide types so they are intrinsically simpler.
> It would have been particularly confusing to permit the notation to
> apply to access types especially an access type A referring to a
> tagged type T. If the access type and the tagged type both had the
> same or similar operations Op then ambiguities or errors could easily
> arise."
>
> Maybe the AI has more details.

From the beginning of AI-252:  "Note: We considered generalizing this
to allow non-tagged types to use this shorthand, but this becomes
complex when the type is an access type, since both the access type
itself, and its designated type must be considered. Furthermore, the
benefit is lower since there is no issue of class-wide operations for
non-tagged types, so all the "interesting" operations are all from a
single package."

I don't see much other discussion in the AI about this issue; perhaps
all the discussion about it was done elsewhere before AI-252 was
opened.

                                  -- Adam

Re: Abusing tagged types

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:f31c3700-731a-495e-b2da-7a909ef9c5db@l33g2000pri.googlegroups.com...
> On Nov 28, 6:08 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>> Maciej Sobczakwrote:
>>
>> > By the way - what is the rationale for allowing Obj.Operation only for
>> > tagged types and not for all types? "Ada 2005 Rationale" does not seem
>> > to explain this.
>>
>> Actually it does but I find the explanation a bit cryptic for untagged
>> types other than access types:
>>
>> "Other variations on the rules for the use of the notation were
>> considered. One was that the mechanism should apply to untagged types
>> as well but this was rejected on the grounds that it might add to
>> rather than reduce confusion in some cases. In any event, untagged
>> types do not have class wide types so they are intrinsically simpler.
>> It would have been particularly confusing to permit the notation to
>> apply to access types especially an access type A referring to a
>> tagged type T. If the access type and the tagged type both had the
>> same or similar operations Op then ambiguities or errors could easily
>> arise."
>>
>> Maybe the AI has more details.
>
> From the beginning of AI-252:  "Note: We considered generalizing this
> to allow non-tagged types to use this shorthand, but this becomes
> complex when the type is an access type, since both the access type
> itself, and its designated type must be considered. Furthermore, the
> benefit is lower since there is no issue of class-wide operations for
> non-tagged types, so all the "interesting" operations are all from a
> single package."
>
> I don't see much other discussion in the AI about this issue; perhaps
> all the discussion about it was done elsewhere before AI-252 was
> opened.

I think most of the discussion on this came at the ARG meetings. (The text 
in the AI was the one-paragraph summary of the meeting conclusions, written 
by someone [me] that had lots of other things to do.) My recollection was 
that there was a problem with dealing with the automatic dereference and 
'Access rules when the type could be an access type. It seemed that only one 
(having those rules) or the other (having access types) worked, and we 
choose the more useful semantics by limiting it to only tagged types. 
Perhaps there is more detail in the meeting minutes (or maybe it is just 
lost).

                                         Randy.

Re: Abusing tagged types

[Jean-Pierre Rosen]

Maciej Sobczak a �crit :
> I'm asking about the design principles - the *purpose* of tagged type
> is to achieve polymorphism with dispatching calls. Is it OK to use
> tagged type without this motivation?
One of the nice things in Ada is the ability to make a difference 
between a method and a subprogram (and yes, I'm afraid about the new 
generation of programmers who know only classes as unit of 
modularization, and call every subprogram a method).

IMHO, the term method should be reserved to operations that have a 
general semantics, but whose implementation (the way of doing the thing 
- the /method/ for doing the thing) depends on the type to which it 
applies. Methods make sense only in the presence of dynamic dispatching, 
i.e. the ability to tell an object: "do this your own way".

O.M notation stresses this by making clearer that a method is applied to 
a given object. Although subprograms may have a parameter of a 
non-tagged type which is in some sense distinguished, they are not 
methods by my definition, and I would not favour using that notation (to 
be honnest, I've never been a great fan of the O.M notation in any case 
- it is misleading if you have more than one controlling operand, which 
is a great superiority of Ada over other OO languages).

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr