Implicits error

On Sat, Feb 7, 2009 at 2:47 PM, Marcus Downing wrote:
> import my.code.JodaConversions
> ...
> if (item.duration > remainingDuration)

Try this:

import my.code.JodaConversions._

This will import the object's members, rather than just the object itself.

Stuart

One general question about style and implicits - is it preferred to define
these rich wrappers as anonymous classes (using closures, yes?) as defined
in the example, or is it better to explicitly name the class?

e.g.

class JodaConversions(period: Period) {
def >= (other: Period) =
period.toStandardSeconds.getSeconds >=
other.toStandardSeconds.getSeconds
// etc.
}

object JodaConversions {
implicit def periodToJodaConversions (period: Period) = new
JodaConversions(period)
}

Is this a style issue, or are there significant implementation consequences
of doing one versus the other?

Dan

val foo = new { def x = 5 }
foo.x uses reflection at runtime (though it is statically guaranteed to succeed).  That's the difference.

2009/2/8 Daniel Wellman <etldan@gmail.com>

One general question about style and implicits - is it preferred to define
these rich wrappers as anonymous classes (using closures, yes?) as defined
in the example, or is it better to explicitly name the class?

e.g.

class JodaConversions(period: Period) {
 def >= (other: Period) =
               period.toStandardSeconds.getSeconds >=
other.toStandardSeconds.getSeconds
 // etc.
}

object JodaConversions {
 implicit def periodToJodaConversions (period: Period) = new
JodaConversions(period)
}


Is this a style issue, or are there significant implementation consequences
of doing one versus the other?

Dan
--
View this message in context: http://www.nabble.com/Implicits-error-tp21884807p21900495.html
Sent from the Scala - User mailing list archive at Nabble.com.

Reflection is about 10x slower at runtime. I'd use an explicitly named class.

--j

On Sun, Feb 8, 2009 at 8:27 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

val foo = new { def x = 5 }
foo.x uses reflection at runtime (though it is statically guaranteed to succeed).  That's the difference.

2009/2/8 Daniel Wellman <etldan@gmail.com>

One general question about style and implicits - is it preferred to define
these rich wrappers as anonymous classes (using closures, yes?) as defined
in the example, or is it better to explicitly name the class?

e.g.

class JodaConversions(period: Period) {
 def >= (other: Period) =
               period.toStandardSeconds.getSeconds >=
other.toStandardSeconds.getSeconds
 // etc.
}

object JodaConversions {
 implicit def periodToJodaConversions (period: Period) = new
JodaConversions(period)
}


Is this a style issue, or are there significant implementation consequences
of doing one versus the other?

Dan
--
View this message in context: http://www.nabble.com/Implicits-error-tp21884807p21900495.html
Sent from the Scala - User mailing list archive at Nabble.com.

Ricky Clarkson wrote:
>
> val foo = new { def x = 5 }
> foo.x uses reflection at runtime (though it is statically guaranteed to
> succeed). That's the difference.
>
Now that's worth knowing! I'll change it to using a named class forthwith.

Are there cases when the reflection based one is preferable?

Yes.  Where the named class version is impossible.

class X { def foo = 5 }
class Y { def foo = 10 }

def gimmeDaFoo(hasFoo: { def foo: Int }) = hasFoo.foo

2009/2/9 Marcus Downing <marcus@minotaur.it>

Ricky Clarkson wrote:
>
> val foo = new { def x = 5 }
> foo.x uses reflection at runtime (though it is statically guaranteed to
> succeed).  That's the difference.
>
Now that's worth knowing! I'll change it to using a named class forthwith.

Are there cases when the reflection based one is preferable?
--
View this message in context: http://www.nabble.com/Implicits-error-tp21884807p21906347.html
Sent from the Scala - User mailing list archive at Nabble.com.

Ricky Clarkson wrote:
>
> Yes. Where the named class version is impossible.
>
> class X { def foo = 5 }
> class Y { def foo = 10 }
>
> def gimmeDaFoo(hasFoo: { def foo: Int }) = hasFoo.foo
>
That's something different - that's duck typing. I was asking about the
following:

implicit def gimmeDaFooable(bar: Bar) = new { def foo: Foo = ... }

It's called structural typing in the Scala docs.  If it was duck typing, you would be able to implicitly convert Any to { def x: Int }

Basically, if it can't go wrong, it ain't duck typing.

2009/2/11 Marcus Downing <marcus@minotaur.it>

Ricky Clarkson wrote:
>
> Yes.  Where the named class version is impossible.
>
> class X { def foo = 5 }
> class Y { def foo = 10 }
>
> def gimmeDaFoo(hasFoo: { def foo: Int }) = hasFoo.foo
>
That's something different - that's duck typing. I was asking about the
following:

implicit def gimmeDaFooable(bar: Bar) = new { def foo: Foo = ... }


--
View this message in context: http://www.nabble.com/Implicits-error-tp21884807p21954524.html
Sent from the Scala - User mailing list archive at Nabble.com.