Re: Generic Collection

[Simon Wright <simon.j.wright@mac.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon.j.wright@mac.com> wrote in message
> news:m2tzuh0yz9.fsf@mac.com...
> ....
>> If your implementation guidelines say that everything should be tagged
>> 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).
>
> Not to speak for others, but there are a lot of reasons:
>
> (1) Most complex types need to be controlled in order to properly manage
> their memory. Making them visibly tagged thus has no overhead.
>
> (2) Maximum flexibility: allowing future clients the ability to extend the
> type without modifying the base type likely reduces future maintence (can't
> break something that you don't change). I don't care much for or about
> inheritance, but extension is a big win.
>
> (3) Tagged types "work right" in Ada: "=" composes properly, user-defined
> operations are used in generics (not true for untagged types, where the
> predefined ones "reimerge"), parameter passing is consistent;
> 'Access can be used in the implementation without forcing users to declare
> everything in sight aliased, you can use prefix calls on the objects, and
> there may be more that I've forgotten.
>
> Note that none of these have anything to do with classwide programming,
> dynamic dispatching, or inheritance, or in fact the tag itself. (3) was an
> important enough issue that we actually considered adding an "aliased" type
> to the Amendment which would provide those benefits without requiring a tag.
> But in the end it was considered to be not enough of an improvement.
>
> Conclusion: (almost) all new ADTs in Ada should be visibly tagged and
> possibly visibly derived from Controlled.

Thanks for that. Those are all reasonable reasons (possible exception
of (2); application ADTs tend not to have 'clients', I'd have thought,
in the sense that you'd want to support unforeseen extensions? And I
can probably break something in strange ways by bad overridings.
Framework ADTs, on the other hand, are of course there to be extended).

It's a shame that untagged types don't "work right" in Ada :-)