- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Implicits error
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.
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
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
Re: Implicits error
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>
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?
Re: Implicits error
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>
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 = ... }
Re: Implicits error
Basically, if it can't go wrong, it ain't duck typing.
2009/2/11 Marcus Downing <marcus [at] minotaur [dot] it>
Re: Implicits error
--j
On Sun, Feb 8, 2009 at 8:27 AM, Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] com> wrote: