Len, (01)
> Christopher:
>
> EB:
>>> Now the fact that the "override" syntax gives rise to some
>>> bizarre abuses is just the Goedel Corollary for Languages:
>>> "You can't allow everything you want without allowing things
>>> you don't want." And "thinking in Java" is no better than
>>> "thinking in Fortran" -- it is one level of abstraction
>>> below that required for the task of software design.
>
> I agree with Ed. (02)
I agree too: I couldn't spot anything much to disagree with
there, when talking of conventional programming. (03)
>
> CS:
>>While I can quite understand the short-term convenience of it,
>>my problem with method overriding is that it torpedoes the
>>Liskov Substitution Principle: an instance of a subclass is
>>no longer guaranteed to be an instance of the baseclass.
>>That's more than just a bizarre abuse -- it's an overthrow of
>>polymorphism as well as inheritance.
>
> I don't agree. Identity and behavior are orthogonal aspects in
> OO. (04)
Not so. If an instance X of class A is defined as necessarily
having behavior P, but a programmer now states that entity X in
this situation must now have behavior Q but not P, then, for all
I know, X is no longer an A. Given encapsulation, there is no
way to be certain that Q is not inconsistent with P. Whereas my
program could always deal with X as if P applied, now it can no
longer do so. The LSP is infringed, inheritance can no longer
be taken advantage of, and I don't know what I am dealing with
any more. I don't even know that this alleged "X" is an A. Oh
yes, the programmer might! But only by cheating. (05)
If, on the other hand, further orthogonal properties and
behaviors are added, in refinement of A, then X is merely an
entity, identical to what it was, about which we now know more.
X is still an A. The LSP applies. (06)
But how can we be sure that a refining property is orthogonal?
Wait for that 5th instalment of my "MACK basics" series! You'll
also see (if I succeed in making it clear...) how the whole
story is really just plain logic and does not need to be dressed
up in any fancy OO terminology. (07)
> What matter is invariance with respect to specific operations.
> Preservation of identity or any other property can only be
> theoretically guarantied if you define category with
> morphisms. However, in practice invariance may be undecidable
> or hard to compute. (08)
Please remind me, if necessary, to try to address those comments
after another instalment or two? I will ask for clarification
of what you mean by reference to what I will by then have
introduced. (09)
>
> As of today OO is simply the closest we can come to enforcing
> LSP in general programming language. (010)
Yes, maybe, as of today...
And I look forward to where this discussion will lead.
So, thank you Len!
Christopher (011)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (012)
|