Re: class wide iterable (and indexable)

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:q0pvlp$1vp1$1@gioia.aioe.org...
> On 2019-01-05 10:21, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:q0n6av$1tqs$1@gioia.aioe.org...
>> ...
>>> In real programs dispatch is rare, thus there is no overhead.
>>
>> This is probably true, but then interfaces are even more useless (they
>> provide nothing that could possibly be of value other than dispatch!).
>
> From the SW design POV they provide a description of an interface, which 
> is a lot of value as is.

That's primarily the job of package specifications, how the contents are 
structured isn't very relevant from a description standpoint.

...
>> ...
>>> No, interfaces cannot contain common code except for class-wide one. Is
>>> that what Randy meant about overhead?
>>
>> Not really. My main point is that you'll never have more than one 
>> concrete
>> instance of a generic interface in any individual program (certainly not 
>> of
>> an interface like that of a container),
>
> I don't understand this. Usually I have dozens of instantiations of the 
> same generics with different actual parameters.

Right, but all of those are *different* interfaces because they have 
*different* generic parameters. You can't mix those types in any useful way, 
because you almost always have the generic parameter type(s) involved.

For instance, for the containers, an interface would have to contain the 
element type. But that substantially limits reuse, because almost every 
container instance would have a different element type. You can't even pass 
just the interface into a generic because you wouldn't be able to call the 
primitives without knowing the element type. To make such a reuse possible 
you'd have to pass so many parameters that you are typing instantiations for 
days. And then the compilation time also would be days. You'd have to be 
slightly mad to even try it. :-)

>> Note: I mean one concrete type, there might be many objects of that type.
>> But it doesn't make sense to use bounded and indefinite containers at the
>> same time for the same element type.
>
> Of course it does. The best example is Ada strings, a container of 
> characters. Practically every program in effect uses both bounded and 
> unbounded strings, the later, maybe, in the form of access String (I tend 
> to avoid Unbounded_String).

As with many things OOP, there seems to be exactly one example where it 
works. And everything else it doesn't work (or at least help - it "works" in 
the sense that you can write it that way and get it to work -- but you've 
gained nothing, you've just changed the problems).

>> Dmitry is of course an all-interface all the time sort of guy. All I see
>> from that is a vast amount of typing to get nothing in particular in 
>> return.
>
> You get type safety. Otherwise you can always go back K&R C! (:-))

Ada has plenty of type safety without using OOP.

>> [But I'm not much of a fan of OOP, either; the big advantage of OOP is
>> requiring few recompiles when adding features. That was a big deal in 
>> 1990,
>> but it hardly matters today. (I can recompile the entirety of Janus/Ada -
>> 250,000 lines - in 15 minutes or so. Why try to save compiles?) And for
>> that, you get to type dozens and dozens of declarations to do anything.
>
> That is because compilers are no longer large software, not even 
> medium-size (:-)). My current project takes a half of week to recompile 
> from scratch [*].

Because you greatly overuse generics in the hopes of making interfaces 
useful. [You admitted as much at the bottom of this message.] You understand 
the cost of using interfaces very well, yet don't seem to make the obvious 
connection. ;-)

> And recompilation is not the biggest problem. Deployment of the modules 
> is.

Keeping protocols consistent is definitely a hard problem. (One I'm glad to 
skip.) I don't see any reason that OOP would help there, though. My attempt 
at that in the Claw Builder was mostly unsuccessful.

 >> While the supposedly terrible case statement solution gives you case
>> completeness checks, variant checks, and essentially has no more chance 
>> of
>> failure (and costs a lot less, and keeps all of the similar code together
>> rather that scattering it about to every different kind of object).
>
> The main problem is that the "similar" code logically has nothing in 
> common, except the shared interface. It must be written by different 
> teams, at different locations and time. Independently tested, used, 
> deployed, versioned, maintained. The case-statement solution crushes not 
> only the architecture but all software process.

Understood, but I'm a "smaller is better" guy. If the team for the project 
doesn't fit in a room, you are guaranteed to have to mess. You can only get 
by then with very strong specifications -- but interfaces themselves don't 
buy anything there (the reverse, in fact, since they're hard to serialize). 
The specifications have to include not just declarations and semantics but 
data layout and protocols and all of that mess that never really works.

And you talk about this a lot, so I don't know what it is that you think you 
gain with interfaces that you wouldn't have with a normal record type and 
primitive operations.

> ----------------------
> * GNAT is awfully slow when compiling specifically generic instantiations, 
> and I have lots of them. The more I have, the more I hate them.

This is the point where I'd usually suggest trying a different compiler. :-) 
A compiler using shared generics could take a lot less time to compile 
instances because there is little code involved. OTOH, I don't want you to 
try Janus/Ada (even on the code that don't use actual interfaces), 'cause 
the way you use generics would inevitably break stuff and I'd hate to have 
to debug code like that. :-) :-)

                              Randy.