We don't build in 2.10.3 #1508

Closed
wants to merge 1 commit into from

3 participants

@farmdawgnation
Lift Web Framework member

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:

stuff.collect {
  case AFilter(f) => f
}.toList

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

stuff.collect {
  case filter: AFilter[T] => filter.f
}

Fix is in progress.

@farmdawgnation farmdawgnation 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
correctness.
4566fd1
@nafg
@nafg

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.

@farmdawgnation
Lift Web Framework member
@nafg

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.

@farmdawgnation
Lift Web Framework member

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.

@nafg
@pbrant
Lift Web Framework member
@nafg
@farmdawgnation
Lift Web Framework member

This is superseded by #1509.

@farmdawgnation farmdawgnation deleted the msf_issue_1508 branch Dec 20, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment