21 Apr 2006 23:44:11 -0400

Related articles |
---|

[2 earlier articles] |

Re: Implementing OO oliverhunt@gmail.com (oliverhunt@gmail.com) (2006-03-27) |

Re: Implementing OO Ido.Yehieli@gmail.com (2006-03-27) |

Re: Implementing OO mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-03-29) |

Re: Implementing OO oliverhunt@gmail.com (oliverhunt@gmail.com) (2006-04-03) |

Re: Implementing OO mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-04-08) |

Re: Implementing OO henry@spsystems.net (2006-04-17) |

Re: Implementing OO mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-04-21) |

From: | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |

Newsgroups: | comp.compilers |

Date: | 21 Apr 2006 23:44:11 -0400 |

Organization: | cbb software GmbH |

References: | 06-03-072 06-03-093 06-04-008 06-04-034 06-04-115 |

Keywords: | OOP |

Posted-Date: | 21 Apr 2006 23:44:11 EDT |

On 17 Apr 2006 23:46:16 -0400, Henry Spencer wrote:

*> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:*

*> It's actually a very natural choice, provided you wish to dispatch on only*

*> one parameter, for encapsulation or performance (and a big reason for C++'s*

*> success is its performance).*

There are better ways to solve the performance problem. One of them is

to prevent re-dispatch.

*>>A subroutine can be a method (subject of inheritance) or not. Depending on*

*>>that it will be either overloadable or overridable. It can't be both*

*>>(better not.)*

*>*

*> Actually, one solution to the co/contravariance problem relies on being*

*> able to do both: <http://david.stoutamire.com/tr-97-061.ps>.*

Hmm, I don't see how it solves the problem. Clearly, for each

dispatching method all slots in its dispatching table can be observed

as individual "overloaded" subroutines. When types are statically

known, the result will be equivalent to dispatch. The problem though

is that the types might be unknown. Even the result type. An example

is abstract factory. But it is not what I actually meant, sorry ,if I

used sloppy language. I did prevention of occasional overloading where

an overriding was intended.

BTW, the common claim that immutability is the key to solve LSP

problem is wrong. A trivial analysis shows that substitutability is

potentially violated in in-methods upon generalization. These are

perfectly immutable.

Another wrong claim is that all this has anything to do with

"computerized" ellipses and circles as opposed to the "mathematical"

ones. In fact, LSP is violated by *pure* mathematical

circles. Consider the following theorem:

"forall x,y Real there exist <ellipse>, such that its axis have the lengths

of x and y."

Substitute <ellipse> by <circle> and the above will become untrue. The

reason is that "exist" quantifier is incompatible with specialization

(injective mapping of the domain set.) This is why out-methods are

broken upon specialization. "Forall" isn't better, it obviously breaks

in-methods in generalization. There is a full duality between

them. With multi-methods, which take both in- and out-parameters (the

arguments and the result), either specialization or generalization

breaks LSP. In general, LSP would require bijective mappings of

values, which, of course, would make subtyping useless.

(Mathematics is OK, LSP is not.)

What the paper correctly observes, is that there is in- and

out-inheritance. A further move to refine it, could be conditional

substitutability and partial inheritance.

*>>...There is no*

*>>way to make all objects polymorphic, because that would exclude small*

*>>objects like bits, pointers and the values of type tags itself.*

*>*

*> This can be treated as an optimization problem rather than a matter of*

*> language definition. Small objects can be used by the implementation when*

*> the value in question is known at compile time not to be polymorphic.*

It could be. Still this knowledge should be reflected in types, because

objects would in effect have different representation. So it is reasonable

to have them of different, though related types.

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.