>
>>Len,
>>
>>> Christopher:
>>>
>>> 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.
>>
>>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.
>
> LSP does not relate identity to behavior. In fact it does not
> deal with identity or behavior directly - instead it promotes
> substitutability and correctness resulting from behavior.
> (see
> http://en.wikipedia.org/wiki/Liskov_substitution_principle) (01)
Thanks for the pointer. So I followed its references. In the
first, Liskov's original 1987 paper enunciates "the following
substitution property" (where S is a subtype of T): (02)
"If for each object o1 of type S there is an object o2 of type T
such that for all programs P defined in terms of T, the behavior
of P is unchanged when o1 is substituted for o2, then S is a
subtype of T." (03)
Even her (and Wing's) 1999 paper, the second Wikipedia
reference, in its abstract opens with this sentence: (04)
"We present a way of defining the subtype relation that ensures
that subtype objects preserve behavioral properties of their
supertypes." (05)
So it would seem that the LSP does directly concern behavior. (06)
And behavior in such circumstances must surely preserve
identity. Then If a program transmutes identity, neither type
nor subtype would necessarily apply any more. (07)
>
> I can understand your concern about method overriding done
> incorrectly in violation of LSP, but that does not mean that
> allowing overriding "torpedoes LSP". (08)
Not necessarily, but overriding does invite practices which can
easily torpedo both integrity and identity and thereby the
intent of the LSP. (09)
> OO languages such as Java provide type-safety of overriding,
> which guaranties invariance of type properties resulting from
> it.
>
> Yes, programmer can still violate LSP, the same way he/she can
> violate other properties at runtime. I doubt, that this can be
> prevented with any language or system. You can go to next
> level with proof-carrying code, but it only guaranties some
> properties of program at runtime - not consistent behavior.
>
> More generally, I don't believe that identity or behavior of
> an entity can be guarantied in absolute sense, and even less
> that it can be feasible to implement such checks outside basic
> finite automation. So the question for me is: what properties
> should constitute identity and behavior and what is the
> reasonable scope to enforce it. (010)
Yes, you are right, this is an absolutely key issue. But it is
not solved either by narrow type-safety (which is where the LSP
is usually invoked), or by conventional OO's encapsulation
principles and practices. The semantics of intermodule
coupling, hopefully so thin or weak, go far beyond mere method
signatures. I recall in 1996/97 having an extended email and
web debate with Andrew Watson, now still the chaiman of the
OMG's Architecture Board, on a closely related issue. He was
insisting that a Generalized Object Model's method despatch
necessarily infringed encapsulation by requiring more
information (which I then read and still do read as "semantics")
than is present in the method signature as defined by the Corba
IDL for it. I argued that even that IDL is not enough,
therefore their then-current Business Object Design Task Force
efforts should fill the gap. When the winning proposal for a
Business Object Facility did not do so, I predicted its failure,
and it was indeed rejected later, after (and surely at least
partly because of) criticism by Jim Rumbaugh for its inadequate
semantics (He was minuted [at bom/98-03-03.pdf, now moved] as
having complained "I thought the idea of this BOF was to raise
the semantic level"). (011)
So as you can imagine, there is a lot in MACK concerning such
issues, and I look forward to addressing them in detail in
coming instalments in my "MACK basics" series. So thanks again
for the prompt! Meanwhile, there is a good start in the
"relationship method" already introduced in the previous
instalment, now here:
http://ontolog.cim3.net/forum/ontolog-forum/2008-04/msg00109.html,
with a further note in its supplement, now here:
http://ontolog.cim3.net/forum/ontolog-forum/2008-04/msg00112.html (012)
Christopher (013)
_________________________________________________________________
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 (014)
|