Re: Best use cases for OOP (resent quoted sorry)

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2025-08-28 17:45, Kevin Chadwick wrote:

    [ snip ]

> I have struggled to find compelling reasons to use tagged types considering
> they affect the size of records and potentially elaboration issues that
> cannot exist without tagged types.
> 
> I know some use tagged types just for dot notation but that doesn't really
> move the needle in my mind.

An Ada amendment (AI22-0091-1) that extends dot notation to almost all 
untagged types has been approved for the next Ada standard:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai22s/ai22-0091-1.html?rev=Top1.8

> I would certainly appreciate it if people could share their favourite
> use cases for tagged types though. Things that are perhaps a pain
> without them or were with Ada 83.
Rather than a use-case, here is a general argument (well known already): 
in principle a tagged type T could be replaced by an Ada 83 record type 
with an enumerated discriminant (corresponding to the tag of T) and 
corresponding variants (corresponding to the types in T'Class). 
Dynamically dispatched operation calls would be replaced by "case" 
statements indexed by the discriminant.

However, that would make it much harder to structure and maintain the 
program, because:

1. The declaration of the discriminant enumeration must contain all 
values that will be used anywhere in the program. This central 
declaration must be visible to all uses of the discriminant.

2. Every "case" statement must contain a "when" branch for every value 
of the discriminant. Thus every "case" statement has to handle all 
variants and have visibility on the modules that implement the logic for 
each variant. This leads to a lot of inter-module dependencies across 
variants that may be quite unrelated.

3. Consequently, adding or removing a variant (corresponding to adding 
or removing a type in T'Class) implies changes to many source files and 
requires a lot of recompilation and perhaps much retesting.

In contrast, when a tagged type is used, instead of a record with variants:

A. There is no central declaration of all derived types (all types in 
T'Class). Each such type can be declared and be visible only in the 
modules where it is relevant. Only the root type T must be widely visible.

B. The implementation of each operation on the class is not a "case" 
statement with a "when" branch for each derived type. Instead, thru 
dynamic dispatch, the implementations of the operations for a derived 
type can be placed in the modules relevant to that type, as if the 
"case" statements had been cut up to collect the "when" branches for 
each variant into a module for that variant.

C. Consequently, adding or removing a derived type in T'Class is usually 
a very local change to a closely related set of source files. Adding or 
removing primitive operations of T can still require changes to many 
source files (the files implementing each derived type), but that can be 
mitigated by creating subclasses of T'Class so that operations 
applicable to a subclass (a subset of the types in T'Class) are defined 
only in that subclass and not all T'Class.

In summary, tagged types provide a new and IMO powerful and useful way 
to modularize a program, separate concerns, and reduce unnecessary 
inter-module dependencies.