Re: Question on LSP

On Fri, 05 May 2006 19:26:13 GMT, H. S. Lahman wrote:

Responding to Kazakov...

It seems to me that failing to preserve is-a semantics in the type
systems would be much worse than choosing OOPL names like X.Y() for
OOA/D abstractions like Account.withdrawal().

It is not failing, it is expressing it in a different way. When you have
virtual memory management, do you really care about physical addresses?

No. But I care very much about instantiation and two instances with the
same identity are a no-no.

But you cannot use physical memory address for identity. The point is that
you have to model the identity in an appropriate way.

Instantiation of types in an OO is-a context is inherently different
that instantiation of types in, say, and RDB context. In OOA/D
referential integrity is married to set membership and that, in turn, is
married to problem space semantics. If one changes the nature of the
is-a relationship in the transformation of OOA/D -> OOP, how can one
guarantee unambiguous mapping for things like enforcing referential
integrity?

But I can't help pointing out that nobody had much interest in type
theory in general and LSP in particular until OOA/D became prominent.
When the only abstractions one needed to play with were procedures, one
could make do with less sophisticated graph and set theory for 3GL
language design. B-) So I find it hard to believe that the type
mavens weren't strongly influenced by OOA/D abstraction semantics like is-a.

It could be true or just a coincidence. Clearly we have a difficult problem
of growing complexity at hand. Old tools and customs stop working. So
people are searching in all corners. My hope is in a great unity, which
would cooptate functional and relational guys.

I don't see that level of cooperation happening real soon. B-) The OO,
functional, and P/R construction paradigms are fundamentally
incompatible because they have different goals and objectives.

Brain and bowel have different goals and objectives, yet they are perfectly
compatible! (:-))

The best
one can do is provide a notation that is sufficiently bland that all can
use it. But the way they use the notation when they build software will
remain methodologically quite different. 3GL type systems provide a
sufficiently bland semantics to design specialized languages for each
paradigm, but those languages will remain specialized. Nor can one talk
about things like LSP unless one defines the problem space AND the
construction methodology.

A good reason to give up nGL stuff which differentiates us! (:-))

It does not, it has a potential to become. Is-a is abstracted as "is
substitutable for" and the latter is as "inherits this method from."

Another fundamental disagreement. "is-a" does not imply anything at all
about substitutability. Is-a is abstracted as "is a member of that
set". Nothing more.

I am constructivist, show me the set! (:-))

The set is any set in the tree. The is-a relationship is just a Venn
Diagram in tree form; nothing more. It is in tree form because that
makes it convenient to deal with the fact that each set is defined in
terms of another set (of properties).

Ah, but I have no objection to is-a defined on properties. I do to is-a
defined on values and objects. The first can imply the latter only if you
have a special sort of identity, which is a property itself. I just don't
consider the latter. It is irrelevant. Anything I want to say about objects
I do in terms of properties.

I would say LSP is relevant to any relationship.

1 grades *
[Teacher] -------------- [Student]

All members of the [Student] set have identical properties, including
identical behaviors. Same thing for all members of the [Teacher] set.
No matter what collaborations take place over that relationship, the
same behaviors are involved, regardless of individual member identity
(i.e., which instances actually participate in the collaboration). In
transforming to 3GL code, each class would be mapped to a single type.
Thus there is no behavior or type substitution in any conceivable
collaboration. So how can LSP be relevant?

In aggregation? I don't see it as types relationship. But I always wished
to go this way to its logical end, i.e. to have abstract record and array
types. Then teacher would be derived from that type, and student from
associated abstract member type. I suppose it is the same discussion as one
about pointer. The idea is to treat all types relationships uniformly, as
subtyping.

That's OK, but it is already beyond types. I want (and I think Liskov did
too) to judge about types regardless to what they implement.

I agree it is beyond the semantics of pure types. But it is not beyond
the semantics of substitution of types. IMO, Liskov's original question
(which Daniel T. quoted) was a philosophical question about what one
/does/ with types. She asked, "What does it mean...". That question
seems to me to be about the context semantics rather than the type
semantics.

That cannot be answered. What does it mean to add? Nothing, full stop.
Scientific answer is elusive: try numbers, they can be added, try
probability measure it is additive, etc.

Hmm, I could have fat pointers and thin objects. This is actually what
always wished to see in modern OOPL. Technically it means that the type tag
is not stored in the object (that will have no type identity). It is in the
pointer. Note that semantically fat-pointer-to-thin-value is equivalent to
thin-pointer-to-fat-value. Both dispatch, both are dynamically polymorphic.
But it breaks your "is-a" fiction. BTW, having this mechanism, you will be
able to translate your OOA/D "is-a" much more uniformly and efficiently.

I think all you are doing is moving the interface definition (type) out
of the object into into the message addressing mechanism.

Abstracting dispatching mechanics? Not really, pointer is an object to me.
It can be of class (fat) or of type (thin) [but never both]. It is just a
consequence of my view on pointers as subtypes.

As an analogy consider that I can describe any complex behavior with
interacting state machines using asynchronous event-based
communications. Almost always the state machine actions will be
executed at some lower level by making synchronous procedure calls.
Does that make a synchronous procedure call inherently asynchronous?
No. Like a pointer, it is just an implementation artifact. In this
case that call is /inherently/ synchronous even though it implements an
asynchronous solution. So the synchronous procedure call has no more to
do with asynchronous behavior than a pointer has to do with polymorphic
dispatch.

Agree, but why do you think that this supports your point of view and not
mine?! (:-))

LSP can only exist if there is type substitution. One can only have
type substitution if there is polymorphic dispatch. Pointers can
implement any sort of dispatch.

I consider only one particular case, where target operation is accessed via
pointer. It is a perfect type substitution. It is also polymorphic
dispatch:

If Foo can be called on T and on T* then there exist a polymorphic
subprogram defined on the class T U T*. The polymorphic subprogram has two
bodies:

1. Foo which works on T
2. Foo o "*", which works on T* ("*" is pointer dereferencing operator)

So when you call Foo on a pointer it is a polymorphic call that resolves to
the body 2.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.