This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Implicits error

8 replies
sadie
Joined: 2008-12-21,
User offline. Last seen 42 years 45 weeks ago.

I'm using implicits to enhance the Joda date time library like so:

object JodaConversions {
implicit def enhancePeriod (period: Period) = new {
def >= (other: Period) =
period.toStandardSeconds.getSeconds >=
other.toStandardSeconds.getSeconds
def > (other: Period) =
period.toStandardSeconds.getSeconds >
other.toStandardSeconds.getSeconds
def <= (other: Period) =
period.toStandardSeconds.getSeconds <=
other.toStandardSeconds.getSeconds
def < (other: Period) =
period.toStandardSeconds.getSeconds <
other.toStandardSeconds.getSeconds
def - (other: Period) = period.minus(other)
def + (other: Period) = period.plus(other)
}
}

And using it elsewhere like so (simplified):

import my.code.JodaConversions
...
if (item.duration > remainingDuration)

Which gives me this error:

error: value > is not a member of time.this.Period

Both values are indeed Period, not some other ReadablePeriod implementation.
What's wrong? I thought it might be the = new { syntax I was using, but
changing that to a named class does nothing.

Stuart Cook
Joined: 2008-12-24,
User offline. Last seen 42 years 45 weeks ago.
Re: 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

Daniel Wellman
Joined: 2009-02-02,
User offline. Last seen 1 year 48 weeks ago.
Re: Implicits error

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

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Implicits error
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 [at] gmail [dot] 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.


Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Implicits error
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 [dot] clarkson [at] gmail [dot] 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 [at] gmail [dot] 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.



sadie
Joined: 2008-12-21,
User offline. Last seen 42 years 45 weeks ago.
Re: Implicits error

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?

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Implicits error
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 [at] minotaur [dot] 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.


sadie
Joined: 2008-12-21,
User offline. Last seen 42 years 45 weeks ago.
Re: Implicits error

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 = ... }

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Implicits error
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 [at] minotaur [dot] 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.


Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland