Re: class wide iterable (and indexable)

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

On 2019-01-06 17:33, George Shapovalov wrote:
> On Sunday, January 6, 2019 at 3:13:45 PM UTC+1, Dmitry A. Kazakov wrote:
>> 3. Constraints. Interfaces cannot have discriminants.
> Well, discriminants (at their basis) are essentially glorified record members treated in a special way, so I grouped them together with 2. But that special treatment can quickly become "sufficiently special" to warrant a separate category. Especially when we start considering all special-cased derived tagged/untagged types overriding or hiding discriminants, so that it turns "simple parameters of the type" into a mixture of data and code (at least according to some discussions of gnat internals I read at some point)..

This is largely because discriminants fuse two different things: 
constraint and a record member representing the constraint. Not every 
constraint is a record member, e.g. array bounds. So the idea is flawed.

>> There is no difference between operations and record members except than
>> language design faults/artifacts. Publicly visible record members should
>> have been overridable as other operations are.
>  From purely logical point of view, perhaps. But once we start considering implementation details, there is a very clear distinction between code and data. Code, you only (usually) have one copy that can be called many times as needed. Data entries can and are duplicated. (At least according to classical paradigm, which is no longer true of course, but see just below).

Both record member and code should be mere implementations of the 
interface <object>.<name>. Things you refer are implementation aspects 
nothing more. The problems arise because of entangled interface and 
implementation.

> Overriding method (from this point of view) is trivial - so what that we got some extra block of code which is called perhaps once? But what do we do with overridden record entry? Do we eliminate it?

You override getter and/or setter. Whatever representation of inherited 
bases stay unless overridden as a whole. The similar approach is used 
for discriminants: either extension or overhaul. (The latter case may 
not be limited, it must be strictly by-value)

> And now, of course, we come back to generics, or rather their "abuse, beyond initial intention". Having powerful and type-checked generics is a big plus of Ada, except when we use that mechanism to blend the boundaries between "code" and "data" by creating millions of specialized code copies thus ending up with "callable data". You refer to just such a situation being common in your projects and I feel your pain. This is also exactly the reason why I try to avoid such scenario as much as possible - going as far as breaking compiler while (ab)using interfaces (compared to what is expected in Ada, although it is a normal use case in some other languages) but to avoid overusing generics beyond their "original intention".

True, but the lobby behind generics is quite powerful. So many things 
unavailable for the core language were crammed into generics. For 
example, Ada 83 had no subroutine type parameters. Even now it is only a 
pointer to subprograms you can have, though lots of accessibility 
problems would go if you could pass a subprogram instead of a pointer 
to. But generics had subroutine parameters from the day one!

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