Hi Jason,

On Friday, June 15, 2012 2:07:21 PM UTC-7, Jason Zaugg wrote:

On Fri, Jun 15, 2012 at 9:39 PM, Bill Venners <bill <at> artima.com> wrote:
> I've made a small example that shows the compilation error I'm experiencing
> in M4. This small example compiles and runs fine under 2.9.1 and 2.10.0-M3.
> But it doesn't compile under 2.10.0-M4. I'll make a ticket for this shortly,
> but I thought I'd post it here as well. Here's the code:
>
> object M4Prob extends App {
>
>   abstract class LengthWrapper {
>     def length: Long
>   }
>
>   implicit def convertGetLengthFieldToLongLengthWrapper(o: { val getLength:
> Long }): LengthWrapper =
>     new LengthWrapper {
>       def length = o.getLength
>     }
>
>   implicit def convertHasLongGetLengthFieldToLengthShouldWrapper[T <: AnyRef
> { val getLength: Long}](o: T): LengthShouldWrapper[T] = new
> LengthShouldWrapper[T](o)
>
>   final class LengthShouldWrapper[A <: AnyRef <% LengthWrapper](left: A) {
>
>     def should(o: Any) {
>       println("Length was: " + left.length)
>     }
>   }
>
>   class Lengthy {
>     def getLength: Long = 99L
>   }
>
>   (new Lengthy) should "howdy"
> }
>
> Under 2.9.1 and 2.10.0-M3, it compiles and when you run it, it correctly
> prints:
>
> Length was: 99
>
> Under 2.10.0-M3, it fails to compile with this error message:
>
> M4Prob.scala:26: error: value should is not a member of M4Prob.Lengthy
>   (new Lengthy) should "howdy"
>                 ^
> one error found

AFAICT, you were relying on a bug. I'm not sure exactly when this
changed. Trimming the problem down little:

object M4Prob extends App {
  trait Lengthy {
    def getLength: Any
  }

  val l: Lengthy = null

  l: {val getLength: Any} // error here is correct: def is not a subtype of val
  l: {def getLength: Any} // okay
}

Oh, well if so that's actually just a bug in my short example. In ScalaTest there's an implicit conversion on both:

 /**

   * This implicit conversion method converts an object with a <code>getLength</code> field of type <code>Int</code> to a

   * <code>LengthWrapper</code>, to enable that object to be used with the <code>have length (7)</code> syntax.

   */

  implicit def convertGetLengthFieldToIntLengthWrapper(o: { val getLength: Int }): LengthWrapper =

    new LengthWrapper {

      def length: Long = o.getLength

    }

  /**

   * This implicit conversion method converts an object with a <code>getLength</code> method of type <code>Int</code> to a

   * <code>LengthWrapper</code>, to enable that object to be used with the <code>have length (7)</code> syntax.

   */

  implicit def convertGetLengthMethodToIntLengthWrapper(o: { def getLength(): Int }): LengthWrapper =

    new LengthWrapper {

      def length: Long = o.getLength()

    }

 

> One other problem with M4, which I imagine has been reported and may even be
> fixed by now, is that M4 is giving a deprecation warning at the use sites of
> Manifest instead of just the declaration sites. ScalaTest is using Manifest
> for its intercept method, for example, and yes when I compile ScalaTest I
> should get a deprecation warning where intercept is defined in trait
> Assertions. But what's happening is that ScalaTest users are getting a
> deprecation warning about Manifest everywhere they invoke intercept (and
> several other methods). I got so many such warnings when compiling
> ScalaTest's own tests had to turn off deprecation warnings to see what the
> errors were. Anyway, if I can't find a ticket for that one I'll submit one.

The migration path from manifests to class tags does need some smoothing,
but I suggest you would be best served to change your 2.10.x branch to heed
the warnings and switch away from manifests. Maybe Eugene can comment with
specific advice on what to change here.

It is really not practical for me to have a different branch after 2.10 is released final, because I want to support 2.8 and 2.9 as well. I'll drop 2.8 support after ScalaTest 2.0 probably, but I expect I'll support 2.9 for a long time to come. A lot of business users don't upgrade (for example, Twitter) right away after a new major Scala release comes out. The best I could do is comment out the 2.10 version, then have some tool that runs through and transforms the code uncommenting the 2.10 code and commenting out the 2.9 code, or vice versa. I'll probably have to do that for macros, but I'd rather it be limited to macro usage.

Bill

 

-jason