Re: Implementing OO

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

Return to the comp.compilers page.
Search the comp.compilers archives again.