Re: Generic package parameters not externally visible : what's the rational ?

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

On Fri, 30 Oct 2009 19:06:56 -0700 (PDT), Hibou57 (Yannick Duch�ne) wrote:

> On 30 oct, 20:32, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Do you use generic in other generics?
> 
> While I do not know if it is the kind of reply you were expected, here
> is mine : I use generics in other generics, when a generic has a
> formal type parameter which come from another generic package. If want
> want to assert the type T is provided (or derived from the one
> provided) by a package P, then both P and T must appear in the
> parameters. If P is generic (this can be legitimate), then you end up
> with a generic using another generic.
>
> Note : and in that case, this may be useful to make this package
> visible from the outside (exporting the content via renames and
> subtype, is not always done exhaustively)

Yes, I do it as well. This is the case when a formal parameter of a generic
is used in another generic.

Note that a generic child package can use formals of its parent. That is
the case why your proposal about visibility is so important in my eyes. It
is an *obvious* language bug.

The case is represented here:

generic
   type T is private;
package P is
end P;

generic
package P.Q is
   Y : T;
end P.Q;

with P.Q;
generic
   with package PQ is new P.Q (<>);
package R is
   X : PQ.T; -- Wring! You cannot see T, and there is no way to name it
end R;

In R you see Y of a "non-existent type".  This is obviously broken to me.

(Yes, I am extensively using the trick of subtype and renaming formal
parameters you wrote about earlier)

But as I said, generics are broken per their nature. With the time it gets
only worse. (:-()

> You may also understand you can have generics dealing with generics,
> when you use the Mixin pattern to add features in a well designed way,
> to that if you ever modify the Mixin package, then modifications
> applies to all the package created with this Minxin. The Mixin may be
> generic, and the package it receives as a parameter as well.

Yes I do it very often. But to give a word of warning, it is a road to
hell. In our current project the diagram of generic units is several pages
long, because of mixins. There is no other way because "high language
priests" have decided that multiple inheritance were bad for us, so the
language has crippled interface types instead of normal MI. The result is
just horrific. Mixin is a bad design pattern, but I wrote about it and
generics many times before.

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