Re: Inherited Methods and such

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

On Tue, 25 Sep 2007 16:02:55 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:19ie8rfpiitdx$.i2sz3r6uj66w.dlg@40tude.net...

> That's what I tried to do with Janus/Ada, and it doesn't work in all cases.

Probably one should give another try and consider the cases where it
appears not working. Maybe they indicate language design problems to fix.

BTW, back in the time I wrote compilers, I noticed that the number of cases
tend to geometrically explode. At some point it was impossible to keep
everything in the head. I played with an idea of some metalanguage to
describe all the mess and to generate a part the compiler dealing with
semantic analysis and intermediate code from a [semi-]formal description.
Something equivalent to what grammars do for the syntax analysis. The
problem is that there existed no formal framework comparable with formal
grammars to describe the types system. (UML is a joke, IMO). I am quite
outdated with compiler design, maybe somebody already did that thing.

>>> Note that this is very similar to the reasons that Ada cannot have "real"
>>> user-defined assignment; it's not possible to divide an assignment into
>>> components managed separately.
>>
>> Same as above. Moreover it would be probably possible to make the old LHS
>> visible in the hook computing the constraints.
> 
> No, you can't have visibility on both objects in a hook routine, because
> there are cases where one side or the other does not exist. You have to
> define three sets of hooks, which would greatly increase the chance of
> errors and probably would be too complex for most to understand.

But it is necessary to have three different hooks when dealing with a
class-wide object of an unconstrained type. Maybe even more, because of the
rules about composition of the constraints. There are three independent
hierarchies involved:

1. A hierarchy of constraints (discriminants added/overridden/removed)
2. A hierarchy of components (record extensions)
3. A hierarchy of inheritance (class)

> The problem doesn't exist if your language doesn't have disappearing
> components, and I would be much more likely to try to approach the problem
> from there. But that wouldn't be Ada.

I am not so sure. IMO, the complexity comes from the hierarchies above.
Whether within one of them (the hierarchy of components) items get added or
removed is a detail.

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