Re: Inherited Methods and such

On Thu, 27 Sep 2007 14:02:37 -0700, Maciej Sobczak wrote:

On 27 Wrz, 17:02, "Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx>
wrote:

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.

No, because it makes no difference at the semantic level.

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.

=> down with re-dispatch! T = T!

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.

Certainly types have operations acting on the values of, is that
surprising? (:-))

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.

type T is tagged ...;
procedure Foo (X : T);
procedure Baz (X : T'Class);

procedure Foo (X : T) is
begin
Baz (X);
end Foo;

type S is new T with ...;
-- Inherits Foo

X1 : T;
X2 : S;
X3 : T'Class := X1;
X4 : T'Class := X2;
begin
Foo (X1); -- OK
Foo (X2); -- Constraint_Error
Foo (X3); -- OK
Foo (X4); -- Constraint_Error

The rule tag = T, excludes object's implicit promotion (downcasting). If
you wanted to downcast you should have to do it explicitly:

Baz (S'Class (S (X)); -- This is OK, if S is visible

You can still shoot yourself in a foot but it would require much more
precise aiming...

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.

Egh, what phenomenon? The problem is that you have no "typed" means to
describe the phenomenon. I have no problem with the semantics of object
construction. I have one with lack of formalism.

Is it inconsistent? Yes, if the static type algebra is requested -
that's your point as I understand.

That's one, another is that, as we saw in the discussion, it is simply
wrong to call it "dispatch on the operations of T." From dispatch there is
only the assembler's instruction JMP.

Does it work "properly" when expected? Yes, for some reasonable
definition of "properly".

(:-))

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.

It is a predefined operation of, otherwise it would be illegal to call
class-wide operations on T.

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.

Why does it expose anything?

Last but not least - what if the developer of T'Class forgets to
register? How can I force it?

The developer of T and T'Class is the same programmer. In a fictional
language which would provide user-defined class-wide hooks on the
constructor of T'Class, this hook will be declared before freezing T:

type T is tagged ...;
private
procedure Register (X : in out T'Class);
for T'Class'Constructor use Register;

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

The only safe thing about that is that it is semantically wrong.
Registration shall happen for all members of T'Class. This automatically
classifies it as either primitive or class-wide. The former falls away,
because 1) you don't want to expose it, 2) you don't want them override it,
3) you want optionally dispatch upon registration. So here you are, it
shall be class-wide.

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.

It does, because after dispatch you are in a primitive operation, where the
argument's type is specifically Child, for example. So you have your
Child's interface there. No mess.

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

Relevant Pages

  • Re: Inherited Methods and such
    ... Forget dynamic dispatch where you are in the constructor. ... I'm arguing against using this concept in the context of constructor. ... that I can register. ... Whether references need to have types at all is a matter of taste. ...
    (comp.lang.ada)
  • Re: Performance of generic functions
    ... You were asking why not dispatch on number of args. ... you could use a more permissive semantics and define ... It may give you an idea of the complexities of designing such language extensions. ...
    (comp.lang.lisp)
  • Re: [RFC] MMIO accessors & barriers documentation
    ... MMIO area to write to for each thread. ... to the last register of one "file" and an unrelated store from another ... accessors _per bus_ (per bus type really, archs can make it more specific ... ordering semantics of readX/writeXfrom the supposed standard Linux ...
    (Linux-Kernel)
  • Re: Returning by value (here we go again!)
    ... > and as such the copy constructor wouldn't need to be ... This can be achieved with move semantics: ... substr to construct another string. ... into an existing string a temporary is still created. ...
    (comp.lang.cpp)
  • Re: copy ctor question
    ... > for each member and base class. ... The compiler generated copy constructor isn't ... > do proper copy semantics themselves. ... Secondly you can't put a breakpoint on a compiler generated ...
    (comp.lang.cpp)