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

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

On 3 nov, 10:59, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> > Generic package hierarchy is nicer than I previously supposed
>
> Yes, but beware that there are *three* hierarchies:
>
> 1. one of the generic packages
> 2. of the instances of generic packages (you can instantiate a generic
> child of generic A as a non-generic child of non-generic B)
> 3. of nested packages (you can instantiate within a package)
>
> A creative use of 1-3 may create a perfect mess out of your program...
I was not really sure about the meaning of “ mess out ” (the term you
used), now I suppose this may mean “ real mess ”, and here is why.

I see at least three productive enough mess seeds with generic child
hierarchy (from the less to the most nasty)
1) The implicit with which comes with all child packages, generic or
not (I had never really enjoyed this implicit With).
2) The miss-match between the generic Withed path and the actual
instance matching path
3) The naming nightmare which comes while creating the instance
hierarchy

With more details :
1) Dependencies are clearly explicit with classic packages, this is no
more the case with child packages. I know this is the same with non-
generic, but this is not really welcome to me (I sometime dream about
child packages hierarchy which would require explicit With).
2) Let A, a generic package, B, a generic child of A, C, an instance
of A, then instantiating C.B requires to With A.B. I understand why it
is this way (although this could have been another way too), but an
A.B whose A actually and implicitly match C, does not help to be
clear.
3) The one I really do not like : with same packages as in #2,
instantiating A.B as a child of C, requires to use a new name which
cannot be B, and if the name B is the most natural one in the context
of A, this mostly mean this would be the same in the context of C,
thus the naming nightmare. For the purpose of the comment which will
follows right after, let call it D.

To reword what you were saying, there is indeed three hierarchies and
not two : the source generic hierarchy (like A.B), the instance
hierarchy (like C.D) and beside this instance hierarchy, another
implicit generic hierarchy (like C.B), and this is hard to deal with.

Yes, now I'm sure you were really talking about mess.

#3 may be solved using a standard prefix for all generics, like
Generic_, but I do not like it, because this easily ends in too much
long paths. Now I'm seeking for a more clever way to easily handle
this three-hierarchies structure. This would not Solve #2 any way.

(Hope I was Ok to post these comments here)