Re: Inherited Methods and such

On Wed, 26 Sep 2007 14:31:01 -0700, Maciej Sobczak wrote:

On 26 Wrz, 12:42, "Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx>
wrote:

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.

Nonetheless, T'Class /= T. Formally, you don't recover it, you create a new
object, then you call some operation on the result, and after completion
you convert it back. The compiler may optimize memory use. For by-reference
type it could be required to do so.

How is it possible to recover T'Class from T?

Because T inherits class-wide operations of T'Class.

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.

It does. It has a primitive operation that constructs T'Class from T. For a
tagged type this operation uses the tag embedded in the representation of
T. This fully determines the outcome both in Ada and C++.

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.

If Initialize were a constructor hook on T, then the language should
classify the program using the conversion operation above as erroneous.

In my view to avoid inconsistencies, the conversion T -> T'Class should
yield an object with the tag = T, no matter what the object was before,
otherwise it shall fail. The object's history is erased after dispatch, now
it is T, no matter what the embedded tag tells. For tagged types,
Constraint_Error should propagate when the tag differ from T.

Note an important difference to C++, C++ does this only upon
construction/destruction. I think that this should be done always. I think
we have discussed it before. I'll try to explain it on a different model:

Consider a specific type as a point T.
Then a class were an open interval [T, oo[.

The types algebra is built on points and open intervals. Subprograms are
defined on either points or intervals. So far, so good.

Now, what you want is to get in the constructor of some S derived from T,
something like a *closed* interval: [T, S].

But you don't have operations in the types algebra for dealing with such
beasts. And the subroutines aren't defined on them. This is inconsistent
with the setup above. Additionally to specific, polymorphic operations it
would require "finite" operations. They should be allowed outside the
constructors, i.e. they would leak out in the language for the sake of
regularity. It will be complex.

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

See above.

N.B. Certainly, you could play with a model where each polymorphic object
were a triple: (View_Type, Native_Type, Native_Value). Then you could try
to figure out the meaning of:

operation Foo of S called on T as if it were U.

Good luck! IMO there is enough problems with a much simpler model.

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.

*If* Initialize were a constructor.

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.

It is a consequence of contract violation. T is specific, you may not
exploit its tag, without being punished.

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.

Register from the constructor of T'Class. Factory were then an abstract
primitive operation of T.

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.

It is called dispatching, no need in changing type. Dispatching does that
for you.

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

Relevant Pages

  • Re: Inherited Methods and such
    ... Initialize converts the object X to T'Class. ... a hook on the constructor of T'Class which is officially constructed, ... Abstract factories perhaps? ... The base types and registry are part of the framework and the user ...
    (comp.lang.ada)
  • Re: Strange member pointer error - even the debugger is confused.
    ... Initialize m_pHead in your constructor to NULL. ... "Aaron Lawrence" wrote in message ... > class ATL_NO_VTABLE CIfsf: ...
    (microsoft.public.vc.language)
  • Re: Initialization & Inheritance
    ... for a recent project I was trying to initialize members of a derived ... class from the constructor of the super class (done using an abstract ... initialize, but double initialization. ... if you used the pointer as it stood, ...
    (comp.lang.java.programmer)
  • Re: Initializing static readonly methods
    ... public class TestClass ... //So assigning a value to readonly is perfectly fine. ... //readonly values are has to be initialized in constructor. ... There is no other place to initialize them. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: initialising properties in static constructor
    ... When static constructor is static it cannot initialize instance variables ... To intialize them in the constructor. ...
    (microsoft.public.dotnet.languages.csharp)