I noticed today that Lift WebKit's LiftScreen doesn't build in 2.10.3, as discussed here. It appears to be a type issue associated with how the latest 2.10's handle parameterized types. Specifically, in this code, 2.10.0 used to allow for the following:
case AFilter(f) => f
Where f is of type T=>T. This would result in a List[T=>T] so you could feed it into areas requiring a List[T=>T]. Except, the newer 2.10's seem to think that this code can generate a "list of something to something where some of those somethings are descendants of T" (best English rendering of the error message).
The fix appears to be to replace these with
case filter: AFilter[T] => filter.f
Fix is in progress.
Get us compiling in Scala 2.10.3.
As explained in PR #1508, there were some changes to how the Scala
compiler understands types that were introduced in the newer 2.10's.
This appears to get us compiling, though I am as of yet unsure of its
In other words: The current solution will probably create a lot of warnings along the lines of "warning: non variable type-argument A in type pattern ... is unchecked since it is eliminated by erasure," as Peter mentioned. Non- variable means that is it is a capital T it is not a bind variable.
The solution may possibly be to just change T to t. In other words case filter: AFilter[t] => filter.f. Try it --- it may get rid of the error and the warning.
case filter: AFilter[t] => filter.f
Another angle of attack, btw, might be to eliminate the need to pattern match, using inheritance instead: add methods to FilterOrValidate and subclasses as necessary. Leave the work there. Then all those collects and flatMaps don't need to deal with the types too creatively. They can just call those methods. stuff.flatMap(_.getSomething).
Of courses collect needs a PartialFunction, but every collect should have an equivalent flatMap.
Yeah, I'm not sure that's a route we'd want to go. Filters have a certain set of operations that should be valid on them, as should validations, but I don't think I should arbitrarily be able to call methods valid on one on the other.
This is superseded by #1509.