Re: overriding in private part

[Adam Beneschan <adam@irvine.com>]

On Oct 3, 1:52 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > But
> > since "overriding" has been added, you should just use it, and it will
> > solve the problem.
>
> Unfortunately it does not.

I shouldn't have said "solve".  It *partially* solves the problem, in
that if the programmers use "overriding" and "not overriding"
consistently on everything, it won't let you write a program that has
an unexpected result of the sort Maxim ran into.  Of course, having
the compiler tell you your program is illegal isn't really a full
solution when the language should be letting you do what you need to
do, but it's a heck of a lot better than accepting your program and
doing the wrong thing.


> The programmer desired to override P2, and this
> is impossible to do, because there is a type in between which effectively
> *hides* the operation in all packages, regardless their visibility.
> Further, this behavior changes when the offending type is derived in A1
> rather than in A1.A2. In that case A1.A3 would be able to override P2.
>
> This is obviously broken to me.

I think this is a good point, and I'm trying to think of a possible
solution.  The small stumbling block is that it's possible to declare
a private extension in a package Package_1

   type T1 is new T with private;

and then, in the private part of Package_1:

   type T1 is new T2 with ...

where T2 is a child of T.  Clearly, any *new* operations that were
declared for T2 but not for T shouldn't be visible, or overridable, by
any package that can't see into the private part of Package_1.  But
that just means that any proposed change would have to be written a
bit more carefully; it's not an insurmountable obstacle.

Anyway, I'm thinking about how this could be fixed.

                               -- Adam