Re: Generic Collection

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

On Sun, 13 May 2007 12:00:58 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> I would probably end up with a package for each, with appropriate Add
>>> operations.
>>> 
>>> with Tuples;
>>> package Tables is
>>>   type Table is private;
>>>   procedure Add (To : in out Table; Item : Tuples.Tuple);
>>
>> + some other set-theoretic operations on the containers.
>>
>> You meant
>>
>>    procedure Add (To : in out Table; Item : Tuples.Tuple'Class);
>>
>> of course.
> 
> Did I? Not if Tuple isn't (visibly) tagged. Why would I make it
> tagged?

No, the package in question does not define Tuple. That means that Add will
not be a primitive operation of. Consequently Add is declared to work with
any Tuple, per design. To me it is class-wide. This is independent on
whether Tuple is tagged or not. After all one can derive from non-tagged
types.

> (I don't see anything in the application use cases so far (!)
> to say it should be).

Yes, but that is the problem with the whole idea. However, what about
function "=" (Left, Right : Tuple) return Boolean?

> If your implementation guidelines say that everything should be tagged

Probably yes, I am not certain about this issue. But not in the present
Ada, which has tagging overhead and no multiple dispatch.

BTW, this is why everything should better be "tagged" (in the sense of
having T'Class), just to be relieved of making such choices. A comparable
case is generics. Any type can potentially be an actual for "type T(<>) is
limited private;" So, any type is in the generic class "(<>) limited
private." Why 'Class should be discriminated?

> I'd have to ask why? (I don't believe that programming-language
> inheritance is necessarily a good way of implementing application area
> specialization/generalization).

That could be, but so far there is no great alternative mechanisms for
that. Other types of polymorphism are supported by generics and
overloading. Neither of them really shines.

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