Re: Inherited Methods and such

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

On Fri, 21 Sep 2007 14:02:06 -0700, Maciej Sobczak wrote:

> On 21 Wrz, 20:59, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>>>>> If you say that an object of the type T1 can take values of the type T2,
>>>>>> such that not T1<:T2, then either:
>>
>>>>> What is T1<:T2 ?
>>
>>>> Subsumption.
>>
>>> This I can guess. What is the direction?
>>
>> Any value of T1 is also one of T2.
> 
> 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" in both Ada and C++. If that were more specific, then C++ would
have no problem with calling virtual functions from there.

>>> No, this is strongly typed, because the type is determined
>>> declaratively and can be deduced without examining the value.
>>
>> If it were so, then
>>
>> class T
>> {
>>    T () { f(); g(); }
>>    void g() {}
>>    virtual void f() {}
>>
>> };
>>
>> should be illegal. Consider f() called in the constructor. The hidden
>> parameter *this of is neither of T nor of T'Class:
>>
>> It cannot be of T, because T is not yet constructed (and you don't want to
>> consider *this specific anyway).
> 
> 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.

> Note that f() is called *after* initializing the fields (the
> constructor initializer list serves some purpose!). Some invariants
> might not be established yet, but the fields are supposedly already
> initialized. The invariants are not an issue - functions calling each
> other have to deal with this effect in general.

"Fields" refer to an implementation detail or else to some other type, like
struct { <same-fields> }. T has more than just fields, it not struct {...}.

When you claim that T has been constructed prior the body of T(), then the
latter simply cannot be a constructor of T! Otherwise, you may not call
methods of T from its body. 

It is plainly inconsistent.

>> It is not of T'Class
> 
> It is - T belongs to T'Class.

If you have a wheel from a car that does not mean you can turn the motor.

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. [In fact it is both
(:-))]

>> BTW, this is also the reason why people calling Ada's Initialize a
>> constructor are wrong.
> 
> Right. Ada doesn't have *any* constructors. :-)

Surely it has. 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?

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.

>> Further, the type of *this is indeterminable, because I can explicitly call
>> the constructor
> 
> No, you cannot. Constructor is not a function - you cannot just "call"
> it.

You mean that ptr->T::T() is illegal in the current incarnation of C++? But
that's no matter.

> (So I cut out your wrong conclusions.)

Don't hurry, I can pass this as parameter:

   T() : A(this), B(this), C(this)  {...}

and enjoy all the mess. The point is, this may appear only after },
otherwise, the type system leaks.

>> 2. If the identifier is the only permanent property of an object then it is
>> exactly what one understand under untyped.
> 
> Which consistently means that you just got stuck with the idea that
> type must be permanent.
> 
> 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.

>> In my world people don't become whales upon fattening. At least not in one
>> generation. (:-))
> 
> Good. :-)
> 
> What about growing up?

The type is Human. Height is an attribute of.

> What about getting promoted in the company?

The type is Employee. Rank is an attribute of. Your employer, should know
that you are a "promotable thing" in order to promote you. Otherwise, he is
risking to assign an ash-tray as a project manager.

>>> I *know* how the type will change without looking
>>> at the value.
>>
>> If you *know* it, then the actual type of the object is a class containing
>> the trace of all possible types the object would "take."
> 
> No. There is nothing that forces me to take this view.

Typing does.

> I don't need
> any "actual" type, becuase the actual type is determined by the
> progress along the inheritance chain.

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.

>>> It is completely different from assigning whatever value
>>> to some object and saying that it changed its type as a result of
>>> this.
>>
>> How is it different? Why the type can be changed upon construction, but
>> cannot upon assignment?
> 
> 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?

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

>> It is difficult to implement but
>> consistent, under the assumption, that you do not change the type! The type
>> is T'Class.
> 
> You can end up with Java-like Object'Class. Not much helpful.

I am not sure what you mean here. If you mean a common ancestor, then it is
irrelevant. It is the programmer's choice in a language which types algebra
has operations other than only inheritance. Consider Ada's:

   type Int is new Integer;
 
There is no class of Int and Integer, so you cannot have any objects from
that class.

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