Re: Inherited Methods and such

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

On 24 Wrz, 11:32, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > T'Class. It has no meaning, because there is no possible family of
> > types there. There is one type T and everything dispatches to T.
> > Forget dynamic dispatch where you are in the constructor.
>
> Sorry, are you arguing against the concept or against C++ model (that uses
> this concept in an inappropriate way? (:-))

I'm arguing against using this concept in the context of constructor.
It does not belong there for the simple reason - T'Class denotes a
potential family of specific types. These don't exist yet.

> > The funny part is that formally there is no such object yet.
>
> Finally. And how is it called when something non-existing can still be used
> as if it were existing and, moreover, were of the type T? It is called
> "untyped mess."

And how is it called when something dispatches into vacuum?
I think "untyped mess" is not exact. Close, but not exact. :-)

> > Still, there is a lot I can do from the methods of the class,
> > which understand the state. These methods can even operate before the
> > invariants of T are fully established. After all, it's their natural
> > ability.
>
> No, this is incorrect. Methods are allowed to break public invariants in
> the course of their execution. But that by no means implies that invariants
> do not hold on the method's input and output.

It's up to the designer to decide which methods can be called and
which invariants should hold and where.

> My position
> is even stricter. It is that it is inconsistent to dispatch even after
> having a fully constructed T. To dispatch you have to construct a
> polymorphic object (like T'Class), to have a specific T is only a premise
> of construction of T'Class.

OK. Let's forbid to call virtual functions altogether until the full
object is ready. I'm fine with such restriction.

> Note the implication: if you construct an S derived from T and have
> constructed only T, then T'Class is still not constructed and you cannot
> dispatch. Only after construction of S, you can proceed to T'Class, and
> after that, lo and behold, you can dispatch safely!

This is extreme, but I understand it.
The C++ way is to allow dispatch with just T, by restricting the
dispatch itself to T only (this is more meaningful when more types are
involved in the chain, so that you can already talk about T'Class
after constructing T *and* S, but not yet U, V and W - this is already
polymorphic in the restricted T+S sense).

> This is why I am arguing for class-wide constructors (strictly speaking,
> user-defined hooks on the completion of). From there you could dispatch.

OK. Such a restriction makes sense when seen in isolation, but makes
some scenarios rather clunky, see below.

> > What are we discussing, then? :-)
>
> That the type of a given object is invariant.

Let's say I want to register my new object from T's constructor in
some map or somewhere. I don't want to hook to complete T'Class,
because I cannot force users deriving from my T to call be back so
that I can register. I want the registration process to be
encapsulated and invisible and I want to do it from T's constructor.
If you restrict the possibility to use T'Class inside the constructor,
you have to way to register T'Class reference/pointer from T's
constructor. Too bad.
One possibility would be to register kind of proxy instead and that
proxy could be used to query whether the object is ready or not. But
this is not really different from having a built-in dispatch that
changes the depth of dispatch dynamically, so we're back at the same
problem.

> > How do you compare C++ with Ada in this context?
>
> In Ada it is called T'Class.

I'm asking about the "aberration" part.

> > I understand your objection that in this case (given the above
> > constraint) it's not T anymore, but making it formally complete would
> > bring more practical issues than it theoretically solves.
>
> That is another discussion. The point was about inconsistency of the model.

Yes, it has holes. I still prefer it due to the fact that it does not
dispatch into vacuum.

> Ada does not have user-defined constructors, so it stays consistent.

Yes.

> Though
> this greatly limits Ada and gives the birth to chimerical constructs like
> functions returning limited objects.

This is just part of the problem. Another part is dispatch into
vacuum.

> Formally it would mean that the object is of the type
>
>     class {T1,T2,...,Tn}
>
> where T1-Tn is the construction path. This type has the operation
> "address," etc. Alas, this is not what actually happens. Because, as you
> claimed, you can dispatch and the target of dispatch moves => it is more
> than just one class. It is not even a type, it is a set of. Something like
>
>    { class {T1}, class {T1, T2}, class {T1, T2, T3}, ... }

Yes. Keep in mind the temporal aspect of this.

> But the effect of all this horrible mess is equivalent to the following
> simpler set of types:
>
>    { T1, T2, T3, ... }

No. You lost the temporal aspect. :-)

> This is why I initially said that
>
> 1. it does not dispatch (in the simpler model);
> 2. the type is specific in each "constructor";
> 3. the thingy is untyped because we have a set of types instead one

Surely you lost the temporal aspect.
The thingy is typed, because at any given moment the target of the
dispatch can be predicted.

> > What about growing up?
>
> The attributes do.

No. Children and Adults have different interfaces. It's not even the
case-block-pretending-dispatch. There are different primitive
operations, some of them not even rooted in Human.

> If you want to keep it one class (human), you are forced
> to have a model where each client would be able to deal with either a child
> or an adult.

No. I can add new operations in derived types.

> > View is what you have with references to objects. There is nothing to
> > introduce here.
>
> You did references. Is reference an object? What is the type of?

Reference is not an object. It it only a "telephone conversation" with
some object.
Whether references need to have types at all is a matter of taste.
They can be transparent (untyped), but in typed language they should
be typed and their type can be T'Class (or just T if the language
allows it - this influences how the dispatch works).

> My point is, a view is
> just a new object of a *new* type.

It does not have to be, but I find it acceptable except that I don't
think you need a *new* type for them. In the extreme case (see Java)
references are the only way to talk to objects, so no new type is
needed, because there is no way to confuse the type of the object with
the type of the reference.

> > And your point is? Mine was that dynamic_cast does not give another
> > object.
>
> It does. Any function returns a new object. Simple? (:-))

If you define it like this, yes. But I can extend the notion of the
function so that function can return views, which are not object.
Simple. :-)

Control question: what is the identity of the view? :-)

> > If I dispatch to the type where even the fields were
> > not yet initialized, how I can decide what I can do? Which type should
> > I ask?
>
> q.e.d.
>
> You cannot consistently answer this question => the model is wrong.

C++ avoids this question by not dispatching into vacuum. If there is
no question, then there is no problem with the answer or the lack of
it.

> Ada is consistent because Initialize is not a constructor. It washes its
> hands: if we don't know how to do it properly, we better don't.

Leaving the problem open? I don't call it consistent.

> >> ----------------
> >> Just annotate types. Fields construction does struct {...}. No less, no
> >> more.
[...]
> > I like it. Really.
> > Well, not really.

Indeed - I cannot register from constructor.
Registering a proxy leaves me again with some form of dynamic_cast
changing its behavior with time, but just with different name.

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