Re: Inherited Methods and such

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

On Mon, 24 Sep 2007 08:02:05 -0700, Maciej Sobczak wrote:

> 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.

Concepts apply to the language as a whole. This includes everything already
written and anything that could be written in the language...

> It does not belong there for the simple reason - T'Class denotes a
> potential family of specific types. These don't exist yet.

Are you making my point? (:-)) How can you dispatch on something
non-existing? If you don't want to dispatch, then just do not! Specific
types do not dispatch.

>>> 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.

An invariant that doesn't hold isn't invariant! (:-))

>> 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.

No, because:

1. It introduces another type T w/o primitive operations;

2. This degenerate is anyway inviable, as you can call primitive operations
from non-primitive ones. It would leak, or else you should mount one
constraint on another in order to keep the card house from collapse;

3. There already exists a type that has the desired property of
non-dispatching, it is T (specific).

>> 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).

You cannot do that because it contradicts to the definition of class T
(T'Class). It is no problem to re-define it as class {T,S}. But in the
contract of it was defined as T'Class = class{T, S, anything else derived
from T}. Thus calling any method of the latter on the former breaks the
types contract => untyped.

You are in an unresolvable contradiction by trying to mix class and its
truncations. It is untyped, just because mixing types in untyped. Ada 95
solved that by naming the truncation as T and the class of as T'Class. The
rest was easy.

> 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.

I don't understand your example - if you don't derive from T, its
constructor will not be called. What do you want, to register objects of
the type T or objects of the type T'Class? Answer this and you will know
from where to do the registration of what.

>>> How do you compare C++ with Ada in this context?
>>
>> In Ada it is called T'Class.
> 
> I'm asking about the "aberration" part.

Ada has some inconsistencies. For example, bounds-sliding renaming of
arrays.

>>> 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.

Oh, yes, let's blow up everything around, then nobody would notice that
hole! (:-))

>> 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.

Not in Ada. You cannot dispatch in Initialize because its argument is
specific.

>> 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.

How and why should I care?
 
> The thingy is typed, because at any given moment the target of the
> dispatch can be predicted.

Huh, the address of any JMP instruction can be predicted at any given
moment. To be typed you should be able to express your predictions in terms
of types.

>>> 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.

You could say it simpler: Children and Adult are different types. Period.

>> 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.

But not to Human. Crocodiles eat humans. The only operation they know is
"chew."

>>> 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.

Do "telephone conversations" have value? (:-)) What is the value of?

> Whether references need to have types at all is a matter of taste.

It is a matter of completeness. You have introduced things beyond values,
types and objects. Either your model is fundamentally too weak to describe
references without that or else you lost your way.

"entities should not be multiplied beyond necessity."

>> 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.

We need it to prevent infinite recursion. More generally, here the
behavioral principle applies: if there is a difference between object and a
reference to => that should be observable through the behaviors of => they
have different behaviors => they have different types.

>>> 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. :-)

Yup, Pickwickian functions in Ada 2005 (:-))

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

There is nothing special in identity. A view can have many identities:

1. The name of the view
2. The type of the view
3. The target if the type of is comparable
4. The tag of the view if it is polymorphic
5. The tag of the target if that is polymorphic
...
 
>> 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.

Incomplete, but consistent. Absence of solution is better than a wrong one.

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