Re: Inherited Methods and such

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 26 Wrz, 12:42, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >> 2. This degenerate is anyway inviable, as you can call primitive operations
> >> from non-primitive ones.
>
> >> 3. There already exists a type that has the desired property of
> >> non-dispatching, it is T (specific).
>
> > 2. and 3. are inconsistent.
>
> No, because the specific type does not kill primitive operations it only
> freezes them.

Not much. I can recover T'Class from T, as in the example from
previous post.

[...]
> >    procedure Initialize (X : in out T) is
> >    begin
> >       Put ("P.Initialize for T");
> >       New_Line;
> >       Put ("-> doing some operation with the object");
> >       New_Line (2);
> >       Dispatch (X);
>
>        ^^^^^^^^^
> The problem is here. Initialize converts the object X to T'Class.

Bingo. Now you might want to explain to me how is this possible if
type of X is specific T.
How is it possible to recover T'Class from T?
Apparently the type I see in Initialize is somehow decoupled from the
type of the object itself. In other words, what I see in Initialize is
not the whole "truth" about the object. The truth is within the object
itself, not in the parameter of Initialize, and with appropriate
question I can get the full answer.
But this only means that T does not really fully determine X.

With appropriate application of the notion of view this is easy - as
far as I'm concerned, the object is T'Class, but Initialize sees only
the T view on it.

But you claimed that views are not needed. Try to explain this without
reinventing views. :-)

> The
> result of this conversion would be wrong if Initialize were a hook on the
> constructor of T. But it isn't. So formally everything is OK. Initialize is
> a hook on the constructor of T'Class which is officially constructed, no
> matter that S's Initialize wasn't called.

None of Initializes was called before T'Class was complete. That's the
problem. It's entirely reversed, leading to untyped mess.

> Note that the case you presented is just a variant of the more general
> problem called "re-dispatch." As your example nicely illustrates,
> re-dispatch is inherently inconsistent.

I'm not sure whether this is inherent, or just a consequence of the
fact that T'Class is formally complete before it's initialized.

> C++ openly uses re-dispatch, Ada does it through the backdoors like above.

Note that C++ protects the programmer from *this* type of mess.


> > I want to register T'Class, but I don't want to involve those who
> > derive from T.
>
> Sorry, but T'Class includes them, your design is inconsistent with that.
> Can you explain where could it be useful?

Abstract factories perhaps?
I want to set up a framework for the abstract factory design pattern.
The base types and registry are part of the framework and the user
provides the concrete factories. The base types register the factories
in the registry so that later the user can request them and get
concrete behaviour.
This is cool and clean only if the registry mechanics is encapsulated
within the framework, so that the user does not have to care about it
in his own constructors - but this is possible only if the base type
can register T'Class, not just T.

But as we've seen, I can recover T'Class from T, so I can do this
anyway. :-)

> >> You could say it simpler: Children and Adult are different types. Period.
>
> > They are both in Human'Class. You try to escape the problem instead of
> > solving it.
>
> I don't see any. If they are in Human'Class <=> they have the behavior of.
> A client would use that behavior. Why do you need to change anything?

A client can ask for the additional interface after discovering the
concrete type.


> > A wrong solution is exploited in the example above.
>
> You have switched the subject from the language to its [ab]use. That Ada
> does not solve the construction problem is clear to me. But that is not an
> inconsistency, it is an incompleteness.

OK. Name it as you want. I don't like it anyway, no matter what's the
name. :-)

> > But so-called "constructor functions" will not solve this problem.
>
> Certainly. I think we, two! (:-)) agree that Ada should have a better
> construction model with user insertions. The next step would be to convince
> others, and to learn for the mistakes made by C++.

Yes. So what are those mistakes actually? :-)

I don't claim there are none.

--
Maciej Sobczak
http://www.msobczak.com/