Re: Inherited Methods and such

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

On 27 Wrz, 17:02, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

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

No. I can have an access variable to the object and I can observe
modifications using this additional alias. This means that no new
object is created.

> The compiler may optimize memory use. For by-reference
> type it could be required to do so.

If it's required to optimize, then it's not optimization, but
semantics. There is no new object.

> > How is it possible to recover T'Class from T?
>
> Because T inherits class-wide operations of T'Class.

Too bad. T'Class can be {T, S} or {T, S, U}, or ... and there is
observable difference between them, so that redispatching on T might
give different behaviours, which means that T /= T. Oops.

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

Then you admit that there is something more than just T - the object
is involved. You have just decoupled T from object. Still without
views? :-)

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

I don't understand it. What is "otherwise"? There is no condition
before that part.

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

Yes, but this assumes that these types would be needed outside of
constructors. I mean - outside of the temporal frame when this
actually matters. C++ avoids this complexity by limiting the time
frame when this phenomenon occurs and uses open intervals during the
"regular" lifetime of the object.
Is it inconsistent? Yes, if the static type algebra is requested -
that's your point as I understand.
Does it work "properly" when expected? Yes, for some reasonable
definition of "properly".

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

T /= T

Recovering T'Class from T is not in T's interface. It's the object
that does it. There is some necessary magic in redispatch that
bypasses T and get's to the object directly (inconsistency), but T
itself does not have this operation.


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

Exactly. The point is that without constructors we have to resort the
the next closest match. Even if that leads to mess.


> > I want to set up a framework for the abstract factory design pattern.

> Register from the constructor of T'Class.

I don't want to, because that exposes the registry to the developers
of T'Class and it was supposed to be encapsulated part of the
framework.
Last but not least - what if the developer of T'Class forgets to
register? How can I force it?

Registering from the base type is more straightforward - and safer.

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

No, it does not give the *additional* interface.

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