One concern with this approach is the readability of the compile-time errors you will get. Do you know about ways to improve these error messages?

I have been thinking of a PartialFunction as a function applicable to a subset of the input types’ value space.

Your example makes me realize there’s a dual way to think of a PartialFunction: as a normal function across the entire input value space + a predicate that partitions the input value space in to two subsets:
* values you might apply the function to
* values for which the function application result is meaningless and should be ignored.

PartialFunction.isDefinedAt(…) *is* that partitioning predicate function.

Probably worth another post, the equivalence between a PartialFunctionX and a(FunctionX, predicate function) tuple, and how you can refactor/translate between the two forms.

One other method I like a lot is “collect” which filters and maps at the same time:

val dirWithJPGs = fileNames collect { case n if new File(n).list((_:String).endsWith(“jpg”)).nonEmpty => new File(n) }.headOption

Of course, I’m cheating a bit in the code above. There’s supposed to be an implicit conversion from (String => Boolean) to java.io.FilenameFilter (for the ‘list’ method), and one from java.util.Array to Iterable (to use the ‘nonEmpty’ method),…

Eric.

Please let me know the schedule of the training and the cost.

Thanks,
Soheila Zandi

Do you have plans to conduct the course in the Los Angeles area?

Thanks,
Richard