Re: Seeking for papers about tagged types vs access to subprograms

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1q07vm77kfwla$.1cz0xwxspxhay.dlg@40tude.net...
> On Thu, 9 May 2013 16:33:55 -0500, Randy Brukardt wrote:
>
>> As usual, I pretty much totally disagree with your thinking here. The 
>> last
>> statement is trivially true, of course, but so what? A program has to be
>> built on top of a handful of "big" abstractions. And for each of those 
>> "big"
>> abstractions, there has to be a single type which takes the lead 
>> (probably
>> with a family of other types in support).
>
> Takes the lead, how? An abstraction including Employer, Employee, Factory,
> Salary, Time, Duration, Integer, Address, Gender, Age ... Who takes the
> "lead"?

The container that wraps those things up, of course. And if there is no 
container, then they're clearly all separate abstractions that have to be 
treated that way.

>> In bigger systems, each of those abstractions corresponds to a subsystem 
>> (in
>> Ada, that's best modeled as a family of child packages). Inside each of
>> those subsystems, you'll have another family of types. But the majority 
>> of
>> these types should not extend beyond the subsystem.
>
> How these subsystems are going to interact to each other?

As little as possible. That's necessary to reduce coupling. Beyond that, 
almost exclusively by containment, that is that one abstraction contains 
components of another.

>> You seem to claim that all types are equally important, which is obvious
>> nonsense.
>
> Yes, I say that unimportant types need not to be exposed in public
> interfaces.
>
> Everything declared in the *same* scope is equally important, or else you
> have a design issue.

What utter nonsense.

Ada.Text_IO defines Count, File_Type, File_Mode, Field, and Number_Base 
types. If you think these are all equally important for the primary task of 
doing I/O, you have a real problem with perspective. File_Type does all of 
the work, while the rest just raise the abstraction level a bit.

>> Claiming that the
>> lookup result enumeration ("Found", "Missing", "Ambiguous") is as 
>> important
>> as the symbol table data structure is insane.
>
> How do you measure importance?

You don't have to quantify it in order for it to be a useful idea. If it's 
not obvious, your design is already too unstructured.

> It is not a simple question. If you tried to roll up a measure and apply 
> it
> most commonly used types, you would probably see your the idea of leading
> types (which, BTW, is one of most damaging ideas in OO ever) quickly
> falling apart.

I don't see any reason to quantify "importance". Almost every package that 
I've designed (as opposed to tossed stuff in, and there are a number of 
those. ;-) has a single type around which everything else is built. There 
are a few (like the containers) that have a pair of such types -- but that 
always proves to be a problem in practice.

I don't quite see what this has to do with OOP; I've used this design 
pattern since I first encountered a package (in the form of a Modula module) 
in 1978. That predates OOP doctrine by a number of years (some of the 
principles already existed, especially in Simula, at that point).

                                          Randy.