Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: martin odersky <martin.odersky-p8DiymsW2f8 <at> public.gmane.org>
Subject: Re: isDefinedAt introduction
Newsgroups: gmane.comp.lang.scala.internals
Date: Monday 9th November 2009 18:30:28 UTC (over 7 years ago)
Come to think of it, I believe we have to revert the change to
Function1, and remove the isDefinedAt method. Why? The root cause is
that PartialFunction is a subtype of Function1. How can it be, and
still respect the LSP? Well, nothing in the contract of Function1 says
that it might not reject its argument due to a MatchError, or a failed
requires, or something else. So PartialFunction simply refines the
contract of Function1 in saying that it will tell via its isDefinedAt
method whether its apply method is prepared to give back a meaningful
result for the given argument. It's true that we have not specified
what this means exactly, but that's the fundamental idea of it.

Now, if we added an isDefinedAt to Function1, we'd need to let it
return "undefined", or "don't know", but these are not Boolean values.
In the proposed implementation we always return true. This is clearly
false because then the LSP would force every subclass including
PartialFunction to always return true also.

So, in summary, PartialFunction being a subclass of Function1 is fine,
but isDefinedAt has no place in Function1.

Cheers

 -- Martin
 
CD: 3ms