Len, sorry about the delay but I have (somewhat interruptedly)
been trying hard to understand you in this matter... I had even
formulated a lot of comments and questions but I was not happy
with them. (01)
Finally I came to the conclusion that your reference framework
was a CT one, so I shall fall back on my earlier request to you
(when you had explicitly mentioned categories and morphisms) to
return to the issue after my (still forthcoming) 5th instalment. (02)
So I am hoping I can look forward to your CT-based perspectives
once you have seen the core role in MACK of transformations. I
have a very simple programmer's view of that scene, albeit in a
strongly philosophical vein too, but I do also very strongly
suspect that CT could have an important role to play in refining
(in the sense of purifying) that aspect of MACK. (03)
Christopher (04)
----- Original Message -----
From: "Len Yabloko" <lenya@xxxxxxxxxxxxx>
To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Sent: Monday, August 25, 2008 4:22 PM
Subject: Re: [ontolog-forum] Fwd: Semantic Web shortcomings [was
Re:ANN: GoodRelations - The Web Ontology for E-Commerce]
>>>
>>>>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)
>>
>>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):
>>
>>"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."
>
> The quote above does not contradict my point because neither
> identity or behavior of o1-->o2 is involved. The behavior of
> P, on the other hand, can not be directly related to identity
> of o1 or o2. Moreover, it can be inferred that P defines the
> scope and criteria for identity of o1 and o2.
>
>>
>>Even her (and Wing's) 1999 paper, the second Wikipedia
>>reference, in its abstract opens with this sentence:
>>
>>"We present a way of defining the subtype relation that
>>ensures that subtype objects preserve behavioral properties of
>>their supertypes."
>>
>>So it would seem that the LSP does directly concern behavior.
>>
>
> LSP concerns behavior of some abstract program P that implies
> set of operations for which subtypes preserve invariance of
> some properties. Nothing here directly relates identity of
> individual type to its behavior.
>
>>And behavior in such circumstances must surely preserve
>>identity. Then If a program transmutes identity, neither type
>>nor subtype would necessarily apply any more.
>>
>
> That is correct because program is the scope where subtype
> holds.
>
>>>
>>> I can understand your concern about method overriding done
>>> incorrectly in violation of LSP, but that does not mean that
>>> allowing overriding "torpedoes LSP".
>>
>>Not necessarily, but overriding does invite practices which
>>can easily torpedo both integrity and identity and thereby the
>>intent of the LSP.
>>
>
> On the contrary - overriding according to LSP is the way to
> enforce behavioral properties defined by the program operating
> with abstract types. It provides the way to refine behavior
> without imposing unnecessary constraints. That is intent of
> LSP and not linking identity of types to their behavior. (05)
_________________________________________________________________
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 (06)
|