Re: Question on LSP

On Sun, 07 May 2006 16:57:17 GMT, H. S. Lahman wrote:

Responding to Kazakov...

But that is beside the point. The issue here is about instantiating two
objects with the same identity, regardless of the implementation of
identity. That's a no-no in an OO context because referential integrity
cannot be preserved during collaboration. [Even RDBs introduce
compound linked identifiers to get around the problem.

It is a dirty hack to improve performance, they lack because RM is
inherently weak here.

Since OO IDs do
not have to be explicit attributes (e.g., they can be addresses),

They cannot be addresses, because addresses may change during program
execution. ID has a definite type. One can use for this purpose the type
Machine_Address. But only under some circumstances, namely when
Machine_Address implements the contract of ID. So it is first identity,
then address, in that order, not in reverse.

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! (:-))

But brains and bowels are the products of construction and they are
constructed differently. The issue here is that the construction
methods for the three software paradigms are inherently incompatible so
they do not mix. I could solve a problem using an FPL in an OO manner
through extensive use of monads and whatnot, but any experienced
functional developer would throw up over the result. Similarly, a
functional developer could solve a problem using an OOPL in a functional
manner with composition and no state variables and I would throw up all
over that result.

To what extent the difference in methods influences one in languages and
reverse? Isn't it so that one cannot mix methods just because there is no
way do describe them same language? If the goal to have one language per
one construction method, then indeed there is little hope. But why it
should be the goal?

But there is still nothing in an OO is-a relationship that says anything
about "is substitutable for". In fact, in the Venn Diagram sense
objects of one subclass are not substitutable for those in another
subclass (i.e., one cannot move objects from one subclass to another).
The substitution only enters the picture through polymorphic dispatch
during collaboration with objects outside the is-a relationship.

I am not sure, what you say, because we are using very different languages.
But in the model where each object has one type there is no place for
direct types substitutability. Maybe it is what you meant. If so, then
things automatically become polymorphic when instead of a type T we
consider the some set of types related to T (class). A value in that class,
equivalent to some value x of T, is itself polymorphic. That is
substitutable for.

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.

Yech. You must have had a traumatic encounter with functional
programming in your formative years. B-)

I had FORTRAN-IV, which was much worse... (:-))

However, I don't see it as a types relationship either. That's kind of
my point about OOA/D not using type systems. B-) However, to implement
it at the 3GL level one will have to deal with a type when mapping
collaboration messages. But there will still be no type substitution
involved because any Teacher always accesses any Student through a
single Student type (and vice versa).

Yes, it is not a substitution between Teacher and Student, it is between
Abstract_Referential_Containter and Teacher; Abstract_Referential_Element
and Student. It should be a sort of abstract relational algebra
instantiated in Teacher/Student pair.

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.

OK. But she proceeded to /define/ substitutability in terms of types
from the client perspective, which limited the philosophical context
drastically. The True Meaning then becomes academic, along with the
number of angels one can fit on the head of a pin. Nonetheless, she was
defining something that was beyond the semantics of types themselves.

Maybe, but IMO that was an non-constructive element which actually killed
her program. The piece was too big to swallow. One just cannot talk about
semantics in general.

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.

Fine. But it is all still specific computing space implementations of
how one sends an OOA/D message from [Teacher] to [Student].

Yes, see above.

BTW, it is a message sent to the pair (Teacher, Student).

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.

But T* is an intermediary; an indirection. It has nothing to do with
and knows nothing about T's properties.

It knows that T has Foo, this is what allows you to do Ptr.Foo (). Only
typeless pointers know [almost] nothing. But we don't want them at all.

Foo can only be called on T.

That's Foo 1. Foo 2 can be called only on T*. Foo polymorphic can be called
on any (on one the class).

When the client invokes Foo, it is always from T, regardless indirection
or what language implementation mechanism is used for addressing a T.
That's why modern OOPLs don't make a distinction and always address
T.Foo. The fact that the language always introduces a hidden T* is a
pure language implementation issue.

Maybe, but I don't want implicit assumptions. If T* is a side effect, then
one cannot talk about identity. If it is an intentional choice to achieve
identity, then that should be made explicitly.

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

Relevant Pages

  • Re: Question on LSP
    ... If the goal to have one language per ... The substitution only enters the picture through polymorphic dispatch during collaboration with objects outside the is-a relationship. ... Like a pointer, it is just an implementation artifact. ... Foo which works on T ...
    (comp.object)
  • Re: Question on LSP
    ... That is an implementation detail. ... It looks like substitution, it works like substitution... ... A pointer always gives one exactly the same thing every time it is ... Your substitutability, OTOH, is an issue for instantiation. ...
    (comp.object)
  • Re: Positive/Negative after taking the square root
    ... With the substitution u = x^2 this appears to become an integral ... Suppose we wish to calculate the average distance of a planet from a star, ... Method 2 (for the industrious student who eschews tables or CASs): ... seen to be wrong because the limits of integration, t=0 to t=2 pi, become ...
    (sci.math)
  • Re: Assignments with $_ using substitution
    ... If I want to assign the result of a substitution in $_ to a variable, ... foreach (@foo) { ... to $a without explicitly assigning $_ to it? ...
    (comp.lang.perl.misc)
  • Re: Variable Eval Question
    ... >gamename wrote: ... >> expect1.62> puts $foo ... >In Tcl quoting, means a literal string, no substitution takes place. ... Prev by Date: ...
    (comp.lang.tcl)