Re: Equivalent of dynamic_cast (downcast) for tagged types

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

On Fri, 28 Jan 2011 18:12:20 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1phnecgw6ckgv.1vm12emlufu5b.dlg@40tude.net...
> ...
>> Yes, it is wrong (language design). The operation is primitive even if
>> invisible in *some* contexts. It means that there might exist other
>> contexts where two operations would conflict. Furthermore, Ada designers
>> tried (and expectedly failed) to ensure that "multiple inheritance" always
>> override.
> 
> I have no idea as to what you are talking about here.

I mean that the issues, MI is customary accused of, are common and
unavoidable with or without MI.

> IMHO, MI is a 
> large cannon whose primary purpose is to blow off limbs.

Nope, MI is an important software development tool for refactoring and
reuse. My current project's size could be reduced in a third, if Ada had
MI.

> Remember that a lot more goes into what is overriding than just the names of 
> operations; it also depends on the profiles and visibility.

But the core issue is always same: the choice between overloading vs.
overriding.

> And, regardless of whether there is a language design flaw, there is no 
> chance that this would change. It would break too much existing code. 

I don't think so, because the means to control the choice are just absent.
Clearly there should be some syntax additions to specify the behavior. So
far the only one is the keyword "overriding."

Also there must be means to resolve unavoidable conflicts. Each overloaded
item should have a unique name. Furthermore, the primitive operations
should have names (presently the names of their type-specific instances are
used in an ambiguous manner).

> Moreover, I think that what you are talking about is actively harmful. Claw, 
> for instance, uses the current rules to have implementation operations that 
> are dispatching, but that clients cannot override in any circumstances. (If 
> they did, Claw would likely fall over in a heap, causing a debugging and 
> support nightmare.)

I am talking about the reality, the reality hurts, I know (:-)). BTW, I am
not proposing to change the current language behavior. I want new language
means to be able to *describe* this behavior explicitly and same means to
describe the alternative behavior where I wanted.

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