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

implicit classes for fun and profit pimping (was: new language "Kotlin" from jetbrains)

10 replies
Sciss
Joined: 2008-12-17,
User offline. Last seen 28 weeks 5 days ago.

hi,

( i hadn't been subscribed, so i can't reply to the original thread ('new language "Kotlin" from jetbrains').)

i was just thinking about the two statements

Nikita: "After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala."
Cédric: "Fair enough, but you need to realize that implicits come with their own baggage as well."

i was curious and took a look at their example:

fun List.swap(x : Int, y : Int) {
val tmp = this[x] // 'this' corresponds to the list
this[x] = this[y]
this[y] = tmp
}

this looks 'easy' but will need to deal with a few problems in the actual implementation, i guess. first of all - "this" suggests that inside that function you are in the context of the pimp'ed class. but i doubt they will allow you to access protected or even private members of that class? although... technically maybe it's possible (i think you can write byte code for the JVM that calls into other classes' private methods)

anyway. i was thinking about how the equivalent in scala looks:

import collection.mutable.{IndexedSeq => MIdxSeq}

object MyPimps {
implicit def idxPimp[A]( sq: MIdxSeq[A]) = new IdxPimp(sq)
class IdxPimp[A] private[MyPimps] (sq: MIdxSeq[A]) {
def swap( x: Int, y: Int ) {
val tmp = sq(x)
sq(x) = sq(y)
sq(y) = tmp
}
}
}

import MyPimps._
val x = MIdxSeq( 1, 2, 3, 4 )
x.swap( 0, 3 )
assert( x == MIdxSeq( 4, 2, 3, 1 ))

and then, even more, a maybe not thought-through idea how that could be liberated from boiler plate:

object MyPimps {
implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
def swap( x: Int, y: Int ) {
val tmp = sq(x)
sq(x) = sq(y)
sq(y) = tmp
}
}
}

error: `implicit' modifier can be used only for values, variables and methods
implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
^

hmmm... so there is actually "space" in the language def :))))

the neat thing here over the kotlin stuff would be that all pimps are grouped together in one class, and that the particular symbol (implicit class) could be imported just like you import other implicits (i _do_ think the need import implicits is a Good Thing).

best, -sciss-

Sciss
Joined: 2008-12-17,
User offline. Last seen 28 weeks 5 days ago.
Re: implicit classes for fun and profit pimping (was: new langu

( on the other hand, this is virtually as clutter-free as the 'implicit class'

object MyPimps {
implicit def idxPimp[A]( sq: MIdxSeq[A]) = new {
def swap( x: Int, y: Int ) {
val tmp = sq(x)
sq(x) = sq(y)
sq(y) = tmp
}
}
}

so maybe not a thought worth pursuing. )

On 26 Jul 2011, at 23:07, Sciss wrote:

> hi,
>
> ( i hadn't been subscribed, so i can't reply to the original thread ('new language "Kotlin" from jetbrains').)
>
> i was just thinking about the two statements
>
> Nikita: "After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala."
> Cédric: "Fair enough, but you need to realize that implicits come with their own baggage as well."
>
> i was curious and took a look at their example:
>
> fun List.swap(x : Int, y : Int) {
> val tmp = this[x] // 'this' corresponds to the list
> this[x] = this[y]
> this[y] = tmp
> }
>
> this looks 'easy' but will need to deal with a few problems in the actual implementation, i guess. first of all - "this" suggests that inside that function you are in the context of the pimp'ed class. but i doubt they will allow you to access protected or even private members of that class? although... technically maybe it's possible (i think you can write byte code for the JVM that calls into other classes' private methods)
>
> anyway. i was thinking about how the equivalent in scala looks:
>
> import collection.mutable.{IndexedSeq => MIdxSeq}
>
> object MyPimps {
> implicit def idxPimp[A]( sq: MIdxSeq[A]) = new IdxPimp(sq)
> class IdxPimp[A] private[MyPimps] (sq: MIdxSeq[A]) {
> def swap( x: Int, y: Int ) {
> val tmp = sq(x)
> sq(x) = sq(y)
> sq(y) = tmp
> }
> }
> }
>
> import MyPimps._
> val x = MIdxSeq( 1, 2, 3, 4 )
> x.swap( 0, 3 )
> assert( x == MIdxSeq( 4, 2, 3, 1 ))
>
> and then, even more, a maybe not thought-through idea how that could be liberated from boiler plate:
>
> object MyPimps {
> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
> def swap( x: Int, y: Int ) {
> val tmp = sq(x)
> sq(x) = sq(y)
> sq(y) = tmp
> }
> }
> }
>
> error: `implicit' modifier can be used only for values, variables and methods
> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
> ^
>
> hmmm... so there is actually "space" in the language def :))))
>
> the neat thing here over the kotlin stuff would be that all pimps are grouped together in one class, and that the particular symbol (implicit class) could be imported just like you import other implicits (i _do_ think the need import implicits is a Good Thing).
>
> best, -sciss-
>

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: implicit classes for fun and profit pimping (was: new langu
I believe that was Jorge's proposal which was mentioned in the thread. Josh Seureth is working on another approach which he didn't specify yet.

On Tue, Jul 26, 2011 at 6:07 PM, Sciss <contact [at] sciss [dot] de> wrote:
hi,

( i hadn't been subscribed, so i can't reply to the original thread ('new language "Kotlin" from jetbrains').)

i was just thinking about the two statements

Nikita: "After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala."
Cédric: "Fair enough, but you need to realize that implicits come with their own baggage as well."

i was curious and took a look at their example:

   fun <T> List<T>.swap(x : Int, y : Int) {
     val tmp = this[x] // 'this' corresponds to the list
     this[x] = this[y]
     this[y] = tmp
   }

this looks 'easy' but will need to deal with a few problems in the actual implementation, i guess. first of all - "this" suggests that inside that function you are in the context of the pimp'ed class. but i doubt they will allow you to access protected or even private members of that class? although... technically maybe it's possible (i think you can write byte code for the JVM that calls into other classes' private methods)

anyway. i was thinking about how the equivalent in scala looks:

   import collection.mutable.{IndexedSeq => MIdxSeq}

   object MyPimps {
      implicit def idxPimp[A]( sq: MIdxSeq[A]) = new IdxPimp(sq)
      class IdxPimp[A] private[MyPimps] (sq: MIdxSeq[A]) {
         def swap( x: Int, y: Int ) {
            val tmp = sq(x)
            sq(x)   = sq(y)
            sq(y)   = tmp
         }
      }
   }

   import MyPimps._
   val x = MIdxSeq( 1, 2, 3, 4 )
   x.swap( 0, 3 )
   assert( x == MIdxSeq( 4, 2, 3, 1 ))

and then, even more, a maybe not thought-through idea how that could be liberated from boiler plate:

   object MyPimps {
      implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
         def swap( x: Int, y: Int ) {
            val tmp = sq(x)
            sq(x)   = sq(y)
            sq(y)   = tmp
         }
      }
   }

error: `implicit' modifier can be used only for values, variables and methods
             implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
                            ^

hmmm... so there is actually "space" in the language def :))))

the neat thing here over the kotlin stuff would be that all pimps are grouped together in one class, and that the particular symbol (implicit class) could be imported just like you import other implicits (i _do_ think the need import implicits is a Good Thing).

best, -sciss-


soc
Joined: 2010-02-07,
User offline. Last seen 34 weeks 5 days ago.
Re: implicit classes for fun and profit pimping (was: new langu

Hi,

> object MyPimps {
> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
> def swap( x: Int, y: Int ) {
> val tmp = sq(x)
> sq(x) = sq(y)
> sq(y) = tmp
> }
> }
> }
>
it looks like an interesting idea, but considering that not the class,
but the constructor is implicitly applied, wouldn't

> class IdxPimp[A] implicit ( sq: MIdxSeq[A]) { ... }

be more "correct"? (I'm not saying that it is nicer ...).

> implicit def idxPimp[A]( sq: MIdxSeq[A]) = new { ... }

Wasn't there a performance problem associated with that approach? (I
think that was the reason people actually write the class...)

Thanks and bye,

Simon

Sciss
Joined: 2008-12-17,
User offline. Last seen 28 weeks 5 days ago.
Re: implicit classes for fun and profit pimping (was: new langu

you are right. this was the link:

http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml

looks the same.

i'm undecided now. if new { ... } is just creating an anonymous class with no runtime overhead, i would say that approach is as elegant and doesn't need any language change.

On 26 Jul 2011, at 23:20, Naftoli Gugenheim wrote:

> I believe that was Jorge's proposal which was mentioned in the thread. Josh Seureth is working on another approach which he didn't specify yet.
>
>
> On Tue, Jul 26, 2011 at 6:07 PM, Sciss wrote:
> hi,
>
> ( i hadn't been subscribed, so i can't reply to the original thread ('new language "Kotlin" from jetbrains').)
>
> i was just thinking about the two statements
>
> Nikita: "After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala."
> Cédric: "Fair enough, but you need to realize that implicits come with their own baggage as well."
>
> i was curious and took a look at their example:
>
> fun List.swap(x : Int, y : Int) {
> val tmp = this[x] // 'this' corresponds to the list
> this[x] = this[y]
> this[y] = tmp
> }
>
> this looks 'easy' but will need to deal with a few problems in the actual implementation, i guess. first of all - "this" suggests that inside that function you are in the context of the pimp'ed class. but i doubt they will allow you to access protected or even private members of that class? although... technically maybe it's possible (i think you can write byte code for the JVM that calls into other classes' private methods)
>
> anyway. i was thinking about how the equivalent in scala looks:
>
> import collection.mutable.{IndexedSeq => MIdxSeq}
>
> object MyPimps {
> implicit def idxPimp[A]( sq: MIdxSeq[A]) = new IdxPimp(sq)
> class IdxPimp[A] private[MyPimps] (sq: MIdxSeq[A]) {
> def swap( x: Int, y: Int ) {
> val tmp = sq(x)
> sq(x) = sq(y)
> sq(y) = tmp
> }
> }
> }
>
> import MyPimps._
> val x = MIdxSeq( 1, 2, 3, 4 )
> x.swap( 0, 3 )
> assert( x == MIdxSeq( 4, 2, 3, 1 ))
>
> and then, even more, a maybe not thought-through idea how that could be liberated from boiler plate:
>
> object MyPimps {
> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
> def swap( x: Int, y: Int ) {
> val tmp = sq(x)
> sq(x) = sq(y)
> sq(y) = tmp
> }
> }
> }
>
> error: `implicit' modifier can be used only for values, variables and methods
> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
> ^
>
> hmmm... so there is actually "space" in the language def :))))
>
> the neat thing here over the kotlin stuff would be that all pimps are grouped together in one class, and that the particular symbol (implicit class) could be imported just like you import other implicits (i _do_ think the need import implicits is a Good Thing).
>
> best, -sciss-
>
>

Sciss
Joined: 2008-12-17,
User offline. Last seen 28 weeks 5 days ago.
Re: implicit classes for fun and profit pimping (was: new langu

On 26 Jul 2011, at 23:17, Simon Ochsenreither wrote:

> Hi,
>
>> object MyPimps {
>> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
>> def swap( x: Int, y: Int ) {
>> val tmp = sq(x)
>> sq(x) = sq(y)
>> sq(y) = tmp
>> }
>> }
>> }
>>
> it looks like an interesting idea, but considering that not the class, but the constructor is implicitly applied, wouldn't
>
> > class IdxPimp[A] implicit ( sq: MIdxSeq[A]) { ... }
>
> be more "correct"? (I'm not saying that it is nicer ...).
>
>
> > implicit def idxPimp[A]( sq: MIdxSeq[A]) = new { ... }
>
> Wasn't there a performance problem associated with that approach? (I think that was the reason people actually write the class...)

hmmm. really? if i do

scala> object Test {
| implicit def hasGaga( a: AnyRef ) = new { def gaga = "hallo " + a }
| class HasGogo private[Test] ( a: AnyRef ) { def gogo = "gallo " + a }
| implicit def hasGogo( a: AnyRef ) = new HasGogo( a )
| }

and

scala> :javap -v Test

at least the invocations are practically the same (don't know about the constructor of the anonymous class, though)

>
>
> Thanks and bye,
>
> Simon

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: implicit classes for fun and profit pimping (was: new langu
On the other hand, there is the downside that if the implicit is defined later on in the code it needs an explicit type annotation to work for earlier code.

On Tue, Jul 26, 2011 at 6:29 PM, Sciss <contact [at] sciss [dot] de> wrote:
you are right. this was the link:

http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml

looks the same.

i'm undecided now. if new { ... } is just creating an anonymous class with no runtime overhead, i would say that approach is as elegant and doesn't need any language change.


On 26 Jul 2011, at 23:20, Naftoli Gugenheim wrote:

> I believe that was Jorge's proposal which was mentioned in the thread. Josh Seureth is working on another approach which he didn't specify yet.
>
>
> On Tue, Jul 26, 2011 at 6:07 PM, Sciss <contact [at] sciss [dot] de> wrote:
> hi,
>
> ( i hadn't been subscribed, so i can't reply to the original thread ('new language "Kotlin" from jetbrains').)
>
> i was just thinking about the two statements
>
> Nikita: "After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala."
> Cédric: "Fair enough, but you need to realize that implicits come with their own baggage as well."
>
> i was curious and took a look at their example:
>
>    fun <T> List<T>.swap(x : Int, y : Int) {
>      val tmp = this[x] // 'this' corresponds to the list
>      this[x] = this[y]
>      this[y] = tmp
>    }
>
> this looks 'easy' but will need to deal with a few problems in the actual implementation, i guess. first of all - "this" suggests that inside that function you are in the context of the pimp'ed class. but i doubt they will allow you to access protected or even private members of that class? although... technically maybe it's possible (i think you can write byte code for the JVM that calls into other classes' private methods)
>
> anyway. i was thinking about how the equivalent in scala looks:
>
>    import collection.mutable.{IndexedSeq => MIdxSeq}
>
>    object MyPimps {
>       implicit def idxPimp[A]( sq: MIdxSeq[A]) = new IdxPimp(sq)
>       class IdxPimp[A] private[MyPimps] (sq: MIdxSeq[A]) {
>          def swap( x: Int, y: Int ) {
>             val tmp = sq(x)
>             sq(x)   = sq(y)
>             sq(y)   = tmp
>          }
>       }
>    }
>
>    import MyPimps._
>    val x = MIdxSeq( 1, 2, 3, 4 )
>    x.swap( 0, 3 )
>    assert( x == MIdxSeq( 4, 2, 3, 1 ))
>
> and then, even more, a maybe not thought-through idea how that could be liberated from boiler plate:
>
>    object MyPimps {
>       implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
>          def swap( x: Int, y: Int ) {
>             val tmp = sq(x)
>             sq(x)   = sq(y)
>             sq(y)   = tmp
>          }
>       }
>    }
>
> error: `implicit' modifier can be used only for values, variables and methods
>              implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
>                             ^
>
> hmmm... so there is actually "space" in the language def :))))
>
> the neat thing here over the kotlin stuff would be that all pimps are grouped together in one class, and that the particular symbol (implicit class) could be imported just like you import other implicits (i _do_ think the need import implicits is a Good Thing).
>
> best, -sciss-
>
>


Sciss
Joined: 2008-12-17,
User offline. Last seen 28 weeks 5 days ago.
Re: implicit classes for fun and profit pimping (was: new langu

what i don't understand about it is that it says there are no object creations involved, but then it's strangely calling from companion object into instance back into companion??

class RichInt(n: Int) extends Ordered[Int] {
def min(m: Int): Int = RichInt.methods$.min(n, m)
...
}

object RichInt {
implicit def apply(n: Int): RichInt = new RichInt(n)

object methods$ {
def min(n: Int, m: Int): Int = if (n <= m) n else m
...
}
}

val i = RichInt.methods$.min(3, 5)

shouldn't it be just

object RichInt {
def min( n: Int, m: Int ) = if (n <= m) n else m
}

with the compiler rewriting

import RichInt._
val i = 3 min 5

into

val i = RichInt.min( 3, 5 )

?

on the other hand, as martin has mentioned a few times, the JVM might be anyway be optimizing away the intermediate instantiations

On 26 Jul 2011, at 23:29, Sciss wrote:

> you are right. this was the link:
>
> http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml
>
> looks the same.
>
> i'm undecided now. if new { ... } is just creating an anonymous class with no runtime overhead, i would say that approach is as elegant and doesn't need any language change.
>
>
> On 26 Jul 2011, at 23:20, Naftoli Gugenheim wrote:
>
>> I believe that was Jorge's proposal which was mentioned in the thread. Josh Seureth is working on another approach which he didn't specify yet.
>>
>>
>> On Tue, Jul 26, 2011 at 6:07 PM, Sciss wrote:
>> hi,
>>
>> ( i hadn't been subscribed, so i can't reply to the original thread ('new language "Kotlin" from jetbrains').)
>>
>> i was just thinking about the two statements
>>
>> Nikita: "After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala."
>> Cédric: "Fair enough, but you need to realize that implicits come with their own baggage as well."
>>
>> i was curious and took a look at their example:
>>
>> fun List.swap(x : Int, y : Int) {
>> val tmp = this[x] // 'this' corresponds to the list
>> this[x] = this[y]
>> this[y] = tmp
>> }
>>
>> this looks 'easy' but will need to deal with a few problems in the actual implementation, i guess. first of all - "this" suggests that inside that function you are in the context of the pimp'ed class. but i doubt they will allow you to access protected or even private members of that class? although... technically maybe it's possible (i think you can write byte code for the JVM that calls into other classes' private methods)
>>
>> anyway. i was thinking about how the equivalent in scala looks:
>>
>> import collection.mutable.{IndexedSeq => MIdxSeq}
>>
>> object MyPimps {
>> implicit def idxPimp[A]( sq: MIdxSeq[A]) = new IdxPimp(sq)
>> class IdxPimp[A] private[MyPimps] (sq: MIdxSeq[A]) {
>> def swap( x: Int, y: Int ) {
>> val tmp = sq(x)
>> sq(x) = sq(y)
>> sq(y) = tmp
>> }
>> }
>> }
>>
>> import MyPimps._
>> val x = MIdxSeq( 1, 2, 3, 4 )
>> x.swap( 0, 3 )
>> assert( x == MIdxSeq( 4, 2, 3, 1 ))
>>
>> and then, even more, a maybe not thought-through idea how that could be liberated from boiler plate:
>>
>> object MyPimps {
>> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
>> def swap( x: Int, y: Int ) {
>> val tmp = sq(x)
>> sq(x) = sq(y)
>> sq(y) = tmp
>> }
>> }
>> }
>>
>> error: `implicit' modifier can be used only for values, variables and methods
>> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
>> ^
>>
>> hmmm... so there is actually "space" in the language def :))))
>>
>> the neat thing here over the kotlin stuff would be that all pimps are grouped together in one class, and that the particular symbol (implicit class) could be imported just like you import other implicits (i _do_ think the need import implicits is a Good Thing).
>>
>> best, -sciss-
>>
>>
>

Kris Nuttycombe
Joined: 2009-01-16,
User offline. Last seen 42 years 45 weeks ago.
Re: implicit classes for fun and profit pimping (was: new langu

On Tue, Jul 26, 2011 at 4:17 PM, Simon Ochsenreither
wrote:
> Hi,
>
>>     object MyPimps {
>>        implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
>>           def swap( x: Int, y: Int ) {
>>              val tmp = sq(x)
>>              sq(x)   = sq(y)
>>              sq(y)   = tmp
>>           }
>>        }
>>     }
>>
> it looks like an interesting idea, but considering that not the class, but
> the constructor is implicitly applied, wouldn't
>
>> class IdxPimp[A] implicit ( sq: MIdxSeq[A]) { ... }
>
> be more "correct"? (I'm not saying that it is nicer ...).
>
>
>> implicit def idxPimp[A]( sq: MIdxSeq[A]) = new { ... }
>
> Wasn't there a performance problem associated with that approach? (I think
> that was the reason people actually write the class...)

The reason that people actually write the class is that the new { ...
} syntax creates a structural type, which means that the methods are
invoked via reflection. I don't think that's changed, has it? So, it's
not necessarily object creation, but reflection in the invocation of
the method of the structural type that's a performance problem.

Sciss
Joined: 2008-12-17,
User offline. Last seen 28 weeks 5 days ago.
Re: implicit classes for fun and profit pimping (was: new langu

yes, that's seems to be the case still:

object Test2 {
import Test._
"pimp".gaga
"pimp".gogo
}

...
11: ldc #76; //String pimp
13: invokevirtual #80; //Method Test$.hasGaga:(Ljava/lang/Object;)Ljava/lang/Object;
16: astore_1
17: aconst_null
18: astore_2
19: aload_1
20: invokevirtual #84; //Method java/lang/Object.getClass:()Ljava/lang/Class;
23: invokestatic #86; //Method reflMethod$Method1:(Ljava/lang/Class;)Ljava/lang/reflect/Method;
26: aload_1
27: iconst_0
28: anewarray #66; //class java/lang/Object
31: invokevirtual #92; //Method java/lang/reflect/Method.invoke:(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
34: astore_2
35: aload_2
36: checkcast #94; //class java/lang/String
...
vs
...
43: ldc #76; //String pimp
45: invokevirtual #98; //Method Test$.hasGogo:(Ljava/lang/Object;)LTest$HasGogo;
48: invokevirtual #ccc; //Method Test$HasGogo.gogo:()Ljava/lang/String;
...

hmmm. but is that just the current implementation, or a necessary restriction?
i mean, wouldn't it be technically possible that scalac did away with the structural typing here?

best, -sciss-

On 26 Jul 2011, at 23:48, Kris Nuttycombe wrote:

> On Tue, Jul 26, 2011 at 4:17 PM, Simon Ochsenreither
> wrote:
>> Hi,
>>
>>> object MyPimps {
>>> implicit class IdxPimp[A]( sq: MIdxSeq[A]) {
>>> def swap( x: Int, y: Int ) {
>>> val tmp = sq(x)
>>> sq(x) = sq(y)
>>> sq(y) = tmp
>>> }
>>> }
>>> }
>>>
>> it looks like an interesting idea, but considering that not the class, but
>> the constructor is implicitly applied, wouldn't
>>
>>> class IdxPimp[A] implicit ( sq: MIdxSeq[A]) { ... }
>>
>> be more "correct"? (I'm not saying that it is nicer ...).
>>
>>
>>> implicit def idxPimp[A]( sq: MIdxSeq[A]) = new { ... }
>>
>> Wasn't there a performance problem associated with that approach? (I think
>> that was the reason people actually write the class...)
>
> The reason that people actually write the class is that the new { ...
> } syntax creates a structural type, which means that the methods are
> invoked via reflection. I don't think that's changed, has it? So, it's
> not necessarily object creation, but reflection in the invocation of
> the method of the structural type that's a performance problem.

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: implicit classes for fun and profit pimping (was: new langu
Also, I saw some comments from Martin regarding moving in the direction of requiring annotating the return type of an implicit declaration: https://groups.google.com/d/topic/scala-internals/jbomsgjxhws/discussion
So the 
implicit def idxPimp[A]( sq: MIdxSeq[A]) = new { ... }

declaration is either going to have to move in the direction of using a real type (as opposed to the structural typing as currently used) or be forced into being rather cumbersome:
implicit def fooList(a:List[Int]):{def bar:String} = new {   def bar:String = "BAR Pimp"}
Requiring all the methods of the "anonymous" class to be listed in the return type of the implicit
(Still invoked via reflection though)
--
Jim Powers

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