Re: Inherited Methods and such

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

On 27 Wrz, 15:39, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> I agree with you that during construction you shouldn't dispatch to the
> deeper type(s) -- i.e. the ones that can see parts of the object that
> are not yet initialized.

Exactly.

> But I find the C++ solution less than ideal -- the programmer might well
> expect to dispatch to the deeper type, and be surprised when it doesn't.

Of course. I can assure you that this question is quite regular and
even has its own FAQ entry:

http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.5

> Question: why do you want to dispatch at all during construction?

I don't. And I can assure you that I don't remember any piece of code
where that would actually matter to me. But Dmitry wanted to discuss
completeness. ;-)

> I think I remember you saying you wanted to install the object in some
> global data structure.  But that just means you want to create an
> access-to-class-wide, and put that somewhere -- no need to dispatch.

Yes, but this was taken out of some fragment of this lengthy
discussion. Registration requires that T'Class is available in the
base type constructor.

So - even if I don't need to dispatch, I might need T'Class.

> In other words, would you be happy with a rule saying you can't dispatch
> during construction?

I would be perfectly fine with this rule, but having this rule *and*
access to T'Class are not much compatible with each other. How can you
prevent me from dispatching if I already have T'Class? With runtime
checks, perhaps? That's the only reasonable option (injecting
artificial types is not reasonable, even if compelling for theorists),
although it would mean that some type provides the interface that
changes with time. I understand Dmitry's arguments against it.

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