Re: Inherited Methods and such

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

On 22 Wrz, 10:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > OK. But then your initial usage of it (still cited above) is wrong in
> > case of constructor, because the type changes in the "more specific"
> > direction.
>
> It is not "more specific." Just note the name, it is called programming "by
> extension"

This name does not matter much to me. Something can be more specific
and require additional state to provide this more specific behavior.

> >> class T
> >> {
> >>    T () { f(); g(); }
> >>    void g() {}
> >>    virtual void f() {}
>
> >> };

> > Not exactly. In the constructor of T, *this already has type T.
>
> But you objected that *this is specific. You claimed that it dispatches in
> f(), if it does then it is of T'Class.

This concept has no meaning there. *this is of type T and dispatches
to T::_().


> When you claim that T has been constructed prior the body of T(), then the
> latter simply cannot be a constructor of T!

It is a constructor, because the initializer list is part of T::T().

To be strict, object is considered to be constructed *after* the
constructor executes to the end (without an exception), so formally
the object is not yet constructed when T::T() is executing its body.
The point is that in the constructor's body the components (fields)
are already constructed (the initializer list handles this) and this
fact makes it safe to use these fields.
This is important - you can *use* the fields, because they were
already constructed.
It would not be possible if *this dispatched to Derived::f(), because
there the Derived's fields do not yet exist.

> It is plainly inconsistent.

It is consistent - the dispatch will never trick you into using not-
yet-constructed fields.


> If it were T'Class then f() would function properly as it shall do on the
> class. But it does not. It exposes a different behavior, hence, either it
> has a different type, or else the language is wrong.

You got stuck with the idea that T'Class must be constant.

> The point is that in NO typed language a constructor can be
> defined solely in the language terms. Constructors have to be generated
> "per magic." But the language shall provide hooks for user-defined
> insertions in the generated constructors at the points, where the type
> contracts are satisfied. Isn't it obvious?

Makes sense. Isn't it true in what I describe?

> Ada keeps on trying to use only magic. Returning limited types, new in Ada
> 2005, is just another step in this direction. This is IMO a road to
> nowhere. And also, it is inconsistent with Ada's own stance on types
> matching by-name rather than by-structure. Surprisingly, but C++ took the
> opposite direction, alas its construction model is inconsistent.

I don't see any inconsistency there. The inconsistency can be found
under the assumption that types must be invariant. But if we remove
this assumption, then the inconsistency is gone.

> > Constructor is not a function - you cannot just "call"
> > it.
>
> You mean that ptr->T::T() is illegal in the current incarnation of C++?

Exactly.

> Don't hurry, I can pass this as parameter:
>
>    T() : A(this), B(this), C(this)  {...}
>
> and enjoy all the mess.

Yes. You can remove this by prohibiting the use of 'this' in the
initializer list (some compilers warn about it anyway).
It is formally allowed, because can be useful if handled with enough
care.
Kind of Unrestricted_Access.

> > Identifier is permanent and this allows me to say that the object
> > *persists* along the process (there is no object replacement, etc.).
> > The type evolves during this process.
>
> What does persist? What is an object? You said it has a name. I am excited,
> but it does not help me in any way. What can I do with the object through
> its wonderful name? If you say that I can take its address, then that
> means: the type (behavior) has the function &. If you say that I cannot
> take its address, then the type does not have &. Either or. You cannot have
> conditionally legal methods in a statically typed language.

I don't get it. You can call & on the type, unless operator& is
private.
How does it relate to the rest of the discussion, anyway?


> > What about growing up?
>
> The type is Human. Height is an attribute of.

I'm not talking about getting higher, but about growing up.
Human has subclasses Child and Adult. Presumably they can do different
things. :-)

So - what about growing up?

The only way to grow up the child in Ada and C++ is to kill a child
and resurrect it as an adult, reshuffling all necessary references in
the system so that they point to the new entity.
Not funny.

> > What about getting promoted in the company?
>
> The type is Employee. Rank is an attribute of.

Too easy. Employees on different levels on their career paths have
different attributes as well. For example, Managers have lists of
people who report to them. Employees with different contracts have
different attributes related to how their salary is computed. Etc.

Same problem as growing up.


> Actual type /= the type. The type = a common denominator of the behavior of
> "all objects like this." When you say that the behavior changes in a way
> the you cannot identify anything common, then it is "strongly" untyped [and
> absolutely useless too]. If you say that you can determine something like
> "actual" type, then it is "weakly untyped." Any such system can be made
> "strongly typed," by introducing methods like <dynamic_cast>. Here
> <dynamic_cast> is defined on the true type. "Actual type" is just the type
> of the result of the method <dynamic_cast> and it yields *another* object.
> In cannot be the same object, because the types differs. If they differ
> then equivalently there exists a method you can apply to one, but not to
> another. For this method you cannot say if it were legal to apply it to the
> object that has both types.

No. dynamic_cast gives another view on the same object. It does not
give another object.
You talk with someone over the phone. At some point you discover that
it's an adult, then you agree with him (dynamic_cast) that from now on
you can talk like adults. It's still the same person, you just know
more about him.


> > Because the language recognizes the fact that construction/destruction
> > does not happen immediately and it is a "build-up" process. Assignment
> > is performed on the object that is already "established".
>
> You introduce many new terms: "immediately," "built-in,"  "established."
> Why these should be relevant to a type system? Do we need such complexity?

As long as things don't happen "immediately", yes.
Without this "complexity" you get real complexity with dispatching to
vacuum.

> And what does prevent you from accepting the proposition that no object
> exists prior its construction?

Why do you thing it would conflict with anything here?
If you think that it would prevent me from doing anything in the
constructor (because I cannot do anything if there is no object), then
it's wrong - in the constructor I can use already constructed fields.
Even from other functions, which are called by the constructor. It's
after the constructor finishes when the clients can use the object via
its public interface. From their point of view the object exists after
the constructor finished. From the constructor point of view, the
fields exist before the constructor's body is executed. Easy.


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