Re: colored point redux

On Sun, Feb 25, 2007 at 10:21:28PM -0500, Vadim Nasardinov wrote:
> On Sunday 25 February 2007 06:45, Pascal Costanza wrote:
> > On 25 Feb 2007, at 04:23, Vadim Nasardinov wrote:
> > > Much better because it's more honest.  We have now completely
> > > abandoned any pretense of Liskov substitutability: 'COLOR-POINT is
> > > no longer a subtype of 'COLOR.  Which is as it should be.  If we
> > > are completely honest, however, we should take this a step further
> > > and change the IS-A relationship to HAS-A.
> >
> > ...and this relates to generic functions how?
> 
> It shows a typical pattern of abuse.  First, you paint yourself into a
> corner by treating ColorPoint as a subtype of Point -- a demonstrably
> false proposition.

Two things:

1. Could you explain why color-point should not be a subtype of point? I 
don't see why thisis the case.

2. It was just an example of a situation that multiple dispatch handles 
cleanly, whereas single dispatch doesn't. Whether or not the design 
choice was smart has no bearing on that. Unless, of course, you can 
demonstrate that situations where multiple dispatch is helpful are 
_always_ the result of bad design choices.

> A better way to handle this is relax, take a deep breath, and see with
> startling clarity that all this pain is entirely self-inflicted.
> ColorPoint is not a subtype of Point.  Hence, it shouldn't be a
> subclass.  Once this crucial insight is gained, everything else falls
> into place quite neatly and without multiple dispatch.

How do things fall into place?

> I'm not dismissing multiple dispatch as entirely useless.  I'm saying
> it's overused in much the same way that macros are overused in Common
> Lisp.  90% of the uses of macros in Lisp would disappear if only Lisp
> had lightweight thunks like the call-by-name syntax in Scala.

There has been a long discussion about macros being overused or even 
unnecessary in Lisp on comp.lang.lisp. Yours was one of the positions, 
with the opposing position mostly being that

1. The things you can do with macros go well beyond what you can do with 
anonymous functions, syntactic sugar or no.

2. Your argument can also be reversed: syntactic sugar for thunks is 
unnecessary if you have macros.

3. Given the above facts, if we have to choose between macros and 
syntactic sugar for anonymous functions, macros are the better choice.

Of course, there is no reason a language couldn't have both.

> > But what do you think the following lines simulate?
> >
> > [...]
> > >  |         if (!(obj instanceof Point)) { return false; }
> > >  |         Point that = (Point) obj;
> > [...]
> 
> Pray tell.

Multiple dispatch?

(defmethod eqv ((this point) that) nil)

(defmethod eqv ((this point) (that point)) ...)

Regards,

Bob

-- 
An eye for an eye makes the whole world blind.
	-- Gandhi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF4tykfb9wcmD+WN4RArYyAKCAVCXRVS0gR/LRZfYuoowCVA78MgCdEKgl
agBYUXkaiU10UtWa4XF8ddQ=
=vDKe
-----END PGP SIGNATURE-----