Implicit conversion not applied because of generic method?

On Wed, May 19, 2010 at 11:42:31PM +0200, Peter Lietz wrote:
> class A[+V] {
> def + [W >: V] (a: A[W]): A[W] = new A[W]
> }
> class B[+V] {
> def + [W >: V] (b: B[W]): B[W] = new B[W]
> }
>
> implicit def aToB [T](a: A[T]): B[T] = new B[T]

With a setup like this you are "overloading across implicit boundaries"
and as with everything to do with overloading, it struggles. In this
case it seems the additional burden of covariance made it angry. It
works if they're invariant.

On Thu, May 20, 2010 at 3:22 AM, Paul Phillips wrote:
> On Wed, May 19, 2010 at 11:42:31PM +0200, Peter Lietz wrote:
>>     class A[+V] {
>>       def + [W >: V] (a: A[W]): A[W] = new A[W]
>>     }
>>     class B[+V] {
>>       def + [W >: V] (b: B[W]): B[W] = new B[W]
>>     }
>>
>>     implicit def aToB [T](a: A[T]): B[T] = new B[T]
>
> With a setup like this you are "overloading across implicit boundaries"
> and as with everything to do with overloading, it struggles.  In this
> case it seems the additional burden of covariance made it angry.  It
> works if they're invariant.

To explain that further: Scala tries to find a implicit conversion so
that B[Int] matches, but because of covariance and the additional
burden of W >: V as type parameter it can't find a direct match.

Another workaround would be to provide an implicit conversion the
other way round. That works even with covariance. This works because
in that case the type parameters of A.+ are determined before an
implicit conversion is searched for.

Dear Paul and Johannes,

On Thu, 2010-05-20 at 08:19 +0200, Johannes Rudolph wrote:
> On Thu, May 20, 2010 at 3:22 AM, Paul Phillips wrote:
> >
> > With a setup like this you are "overloading across implicit boundaries"
> > and as with everything to do with overloading, it struggles. In this
> > case it seems the additional burden of covariance made it angry. It
> > works if they're invariant.

No doubt scalac is struggling, it may even be angry. Nevertheless,
either the scala language specification draws a line somewhere between
the former and the latter case (which I did not find), or this is a
compiler bug. Which one is it?

> To explain that further: Scala tries to find a implicit conversion so
> that B[Int] matches, but because of covariance and the additional
> burden of W >: V as type parameter it can't find a direct match.
>
> Another workaround would be to provide an implicit conversion the
> other way round. That works even with covariance. This works because
> in that case the type parameters of A.+ are determined before an
> implicit conversion is searched for.

yes, but then (by symmetry) the addition won't work the other way
around.

On Thu, May 20, 2010 at 06:55:12PM +0200, Peter Lietz wrote:
> No doubt scalac is struggling, it may even be angry. Nevertheless,
> either the scala language specification draws a line somewhere between
> the former and the latter case (which I did not find), or this is a
> compiler bug. Which one is it?

False dichotomy: there is a (very large) third category of things which
we call "underspecified". I've got many other things to be doing but
you can get an up to the minute copy of the spec and decide for yourself.

http://www.scala-lang.org/node/212/pdfs

If it is indeed specified and the specification doesn't match the
implementation and there isn't already a ticket in trac, then I
encourage you to open one.

And, to complement Paul's answer, as far as I know type inference is intentionally unspecified.

On Thu, May 20, 2010 at 1:55 PM, Peter Lietz <p.lietz@gmx.de> wrote:

Dear Paul and Johannes,

On Thu, 2010-05-20 at 08:19 +0200, Johannes Rudolph wrote:
> On Thu, May 20, 2010 at 3:22 AM, Paul Phillips <paulp@improving.org> wrote:
> >
> > With a setup like this you are "overloading across implicit boundaries"
> > and as with everything to do with overloading, it struggles.  In this
> > case it seems the additional burden of covariance made it angry.  It
> > works if they're invariant.

No doubt scalac is struggling, it may even be angry. Nevertheless,
either the scala language specification draws a line somewhere between
the former and the latter case (which I did not find), or this is a
compiler bug. Which one is it?

> To explain that further: Scala tries to find a implicit conversion so
> that B[Int] matches, but because of covariance and the additional
> burden of W >: V as type parameter it can't find a direct match.
>
> Another workaround would be to provide an implicit conversion the
> other way round. That works even with covariance. This works because
> in that case the type parameters of A.+ are determined before an
> implicit conversion is searched for.

yes, but then (by symmetry) the addition won't work the other way
around.

--
Daniel C. Sobral

I travel to the future all the time.

Thank you all for your answers, you are of course right. No programming
language (other than Standard ML) is completely specified. Thanks for
the pointer to the 2.8 language specification, incidentally I was
looking for that!

Peter

I'd think a language like Agda, for example, would be completely specified.

On Thu, May 20, 2010 at 3:08 PM, Peter Lietz <p.lietz@gmx.de> wrote:

Thank you all for your answers, you are of course right. No programming
language (other than Standard ML) is completely specified. Thanks for
the pointer to the 2.8 language specification, incidentally I was
looking for that!

Peter

--
Daniel C. Sobral

I travel to the future all the time.

this is my code:
val tmpDummy = new ListBuffer[Position]
val removedDuplicates = suggested.collect({
case e if !tmpDummy.exists(_.linearDistanceTo(e)<7) => e
})

the tmpDummy is ugly. how could i get rid of it? i clearly belongs into
the partial function.
>
>
>

What's the purpose of tmpDummy there? You created it empty, so exists will always return false and, therefore, !tmpDummy.exists(...) will always return true.

On Thu, May 20, 2010 at 5:11 PM, HamsterofDeath <h-star@gmx.de> wrote:

this is my code:
     val tmpDummy = new ListBuffer[Position]
     val removedDuplicates = suggested.collect({
       case e if !tmpDummy.exists(_.linearDistanceTo(e)<7) => e
     })

the tmpDummy is ugly. how could i get rid of it? i clearly belongs into
the partial function.
>
>
>

--
Daniel C. Sobral

I travel to the future all the time.

Hi. I have a similar situation.
private val buffer = new HashMap[Int,Expr]()
private def buildExpr(i: Int): Expr = {...}
def getExpr(i: Int): Expr = buffer.getOrElseUpdate(i, buildExpr(i))
I think it works fine the way it is, but maybe it would be better if there was a way to declare buffer inside getExpr since it is used nowhere else.
Jeff.


On Thu, May 20, 2010 at 8:14 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

What's the purpose of tmpDummy there? You created it empty, so exists will always return false and, therefore, !tmpDummy.exists(...) will always return true.

On Thu, May 20, 2010 at 5:11 PM, HamsterofDeath <h-star@gmx.de> wrote:

this is my code:
     val tmpDummy = new ListBuffer[Position]
     val removedDuplicates = suggested.collect({
       case e if !tmpDummy.exists(_.linearDistanceTo(e)<7) => e
     })

the tmpDummy is ugly. how could i get rid of it? i clearly belongs into
the partial function.
>
>
>

--
Daniel C. Sobral

I travel to the future all the time.

--
"You question the worthiness of my Code? I should kill you where you stand!"

On Thu, May 20, 2010 at 08:58:35PM -0300, Jefferson Andrade wrote:
> private val buffer = new HashMap[Int,Expr]()
>
> private def buildExpr(i: Int): Expr = {...}
>
> def getExpr(i: Int): Expr = buffer.getOrElseUpdate(i, buildExpr(i))
>
> I think it works fine the way it is, but maybe it would be better if
> there was a way to declare buffer inside getExpr since it is used
> nowhere else.

scala> def foo(x: Int) = { println("calculating " + x) ; x }
foo: (x: Int)Int

scala> val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int] ; (x: Int) => buffer.getOrElseUpdate(x, foo(x)) }
getExpr: (Int) => Int =

scala> getExpr(5)
calculating 5
res0: Int = 5

scala> getExpr(5)
res1: Int = 5

scala> getExpr(6)
calculating 6
res2: Int = 6

scala> getExpr(6)
res3: Int = 6

Nice,
But in that way, getExpr would be a function and not a method, isn't it?
Just to confirm my understanding.
Thanks,Jeff.

On Thu, May 20, 2010 at 10:09 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, May 20, 2010 at 08:58:35PM -0300, Jefferson Andrade wrote:
> private val buffer = new HashMap[Int,Expr]()
>
> private def buildExpr(i: Int): Expr = {...}
>
> def getExpr(i: Int): Expr = buffer.getOrElseUpdate(i, buildExpr(i))
>
> I think it works fine the way it is, but maybe it would be better if
> there was a way to declare buffer inside getExpr since it is used
> nowhere else.

scala> def foo(x: Int) = { println("calculating " + x) ; x }
foo: (x: Int)Int

scala> val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int] ;  (x: Int) => buffer.getOrElseUpdate(x, foo(x)) }
getExpr: (Int) => Int = <function1>

scala> getExpr(5)
calculating 5
res0: Int = 5

scala> getExpr(5)
res1: Int = 5

scala> getExpr(6)
calculating 6
res2: Int = 6

scala> getExpr(6)
res3: Int = 6

--
Paul Phillips      | The important thing here is that the music is not in
Stickler           | the piano.  And knowledge and edification is not in the
Empiricist         | computer.  The computer is simply an instrument whose
pull his pi pal!   | music is ideas.  -- Alan Kay

--
"You question the worthiness of my Code? I should kill you where you stand!"

whoopsy, you found a bug. it should be:

val tmpDummy = new ListBuffer[Position]
val removedDuplicates = suggested.flatMap({ e =>
if !tmpDummy.exists(_.linearDistanceTo(e)<7)
{
tmpDummy+=e
Some(e)
} else None
})

i need to know which elements i already collected to make sure i don't
collect positions that are near to an already collected one

Daniel Sobral schrieb:
> What's the purpose of tmpDummy there? You created it empty, so exists
> will always return false and, therefore, !tmpDummy.exists(...) will
> always return true.
>
> On Thu, May 20, 2010 at 5:11 PM, HamsterofDeath > wrote:
>
> this is my code:
> val tmpDummy = new ListBuffer[Position]
> val removedDuplicates = suggested.collect({
> case e if !tmpDummy.exists(_.linearDistanceTo(e)<7) => e
> })
>
> the tmpDummy is ugly. how could i get rid of it? i clearly belongs
> into
> the partial function.
> >
> >
> >
>
>
>
>

The following code avoids polluting the scope and is more readable
(inspired by the famous sieve of Eratosthenes):

def sparseCollect(l: List[Position]): List[Position] = l match {
case Nil => Nil
case x :: xs => x :: sparseCollect(xs filter (x.linearDistanceTo(_) >= 7))
}

val removedDuplicates = sparseCollect(suggested)

Best,
Peter

On Fri, 2010-05-21 at 08:15 +0200, HamsterofDeath wrote:
> whoopsy, you found a bug. it should be:
>
> val tmpDummy = new ListBuffer[Position]
> val removedDuplicates = suggested.flatMap({ e =>
> if !tmpDummy.exists(_.linearDistanceTo(e)<7)
> {
> tmpDummy+=e
> Some(e)
> } else None
> })
>
> i need to know which elements i already collected to make sure i don't
> collect positions that are near to an already collected one
>
>
> Daniel Sobral schrieb:
> > What's the purpose of tmpDummy there? You created it empty, so exists
> > will always return false and, therefore, !tmpDummy.exists(...) will
> > always return true.
> >
> > On Thu, May 20, 2010 at 5:11 PM, HamsterofDeath > > wrote:
> >
> > this is my code:
> > val tmpDummy = new ListBuffer[Position]
> > val removedDuplicates = suggested.collect({
> > case e if !tmpDummy.exists(_.linearDistanceTo(e)<7) => e
> > })
> >
> > the tmpDummy is ugly. how could i get rid of it? i clearly belongs
> > into
> > the partial function.
> > >
> > >
> > >
> >
> >
> >
> >
> > --
> > Daniel C. Sobral
> >
> > I travel to the future all the time.

On Fri, 2010-05-21 at 17:13 +0200, Peter Lietz wrote:
> The following code avoids polluting the scope and is more readable
> (inspired by the famous sieve of Eratosthenes):
>
>
> def sparseCollect(l: List[Position]): List[Position] = l match {
> case Nil => Nil
> case x :: xs => x :: sparseCollect(xs filter (x.linearDistanceTo(_) >= 7))
> }
>
> val removedDuplicates = sparseCollect(suggested)

PS:

However, only do this if your collection is not very large, since the
method is not tail-recursive.

looks a bit like a cheat. i like it :D
-------- Original-Nachricht --------
> Datum: Fri, 21 May 2010 17:13:44 +0200
> Von: Peter Lietz

> An: HamsterofDeath
> CC: Daniel Sobral , scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] partial function using a tmp listbuffer

>
> The following code avoids polluting the scope and is more readable
> (inspired by the famous sieve of Eratosthenes):
>
>
> def sparseCollect(l: List[Position]): List[Position] = l match {
> case Nil => Nil
> case x :: xs => x :: sparseCollect(xs filter (x.linearDistanceTo(_) >=
> 7))
> }
>
> val removedDuplicates = sparseCollect(suggested)
>
>
> Best,
> Peter
>
>
> On Fri, 2010-05-21 at 08:15 +0200, HamsterofDeath wrote:
> > whoopsy, you found a bug. it should be:
> >
> > val tmpDummy = new ListBuffer[Position]
> > val removedDuplicates = suggested.flatMap({ e =>
> > if !tmpDummy.exists(_.linearDistanceTo(e)<7)
> > {
> > tmpDummy+=e
> > Some(e)
> > } else None
> > })
> >
> > i need to know which elements i already collected to make sure i don't
> > collect positions that are near to an already collected one
> >
> >
> > Daniel Sobral schrieb:
> > > What's the purpose of tmpDummy there? You created it empty, so exists
> > > will always return false and, therefore, !tmpDummy.exists(...) will
> > > always return true.
> > >
> > > On Thu, May 20, 2010 at 5:11 PM, HamsterofDeath > > > wrote:
> > >
> > > this is my code:
> > > val tmpDummy = new ListBuffer[Position]
> > > val removedDuplicates = suggested.collect({
> > > case e if !tmpDummy.exists(_.linearDistanceTo(e)<7) => e
> > > })
> > >
> > > the tmpDummy is ugly. how could i get rid of it? i clearly belongs
> > > into
> > > the partial function.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > Daniel C. Sobral
> > >
> > > I travel to the future all the time.
>

>   def sparseCollect(l: List[Position]): List[Position] = l match {
>     case Nil => Nil
>     case x :: xs => x :: sparseCollect(xs filter (x.linearDistanceTo(_) >= 7))
>   }
>
>   val removedDuplicates = sparseCollect(suggested)


PS:

However, only do this if your collection is not very large, since the
method is not tail-recursive.

Easily fixed with an accumulator:

def sparseCollect(list: List[Position]): List[Position] = {
  @tailrec def sc(rem: List[Position], acc: List[Position]): List[Position] = rem match {
    case Nil => Nil
    case x :: xs => sc(xs.filter(x.linearDistanceTo(_) >= 7), x :: acc)
  }
  sc(list, Nil).reverse
}
 
- Colin

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}

Distinction is syntactically irrelevant…it’s a member! you can override it in derived classes too

 

scala> class Mine {

     | def foo(x: Int) = { println("calculating " + x) ; x }

     |

     | val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int] ;

(x: Int) => buffer.getOrElseUpdate(x, foo(x)) }

     |

     | }

defined class Mine

 

scala> val m = new Mine()

m: Mine = Mine@1bc93a7

 

scala> m getExpr 5

calculating 5

res3: Int = 5

 

scala> m getExpr 5

res4: Int = 5

 

scala> val mm = new Mine()

mm: Mine = Mine@1be3d02

 

scala> mm getExpr 5

calculating 5

res5: Int = 5

 

scala>

 

From: Jefferson Andrade [mailto:joandrade@gmail.com]
Sent: Friday, May 21, 2010 12:10 AM
To: Paul Phillips
Cc: Daniel Sobral; HamsterofDeath; scala-user@listes.epfl.ch
Subject: Re: [scala-user] partial function using a tmp listbuffer

 

Nice,

 

But in that way, getExpr would be a function and not a method, isn't it?

 

Just to confirm my understanding.

 

Thanks,

Jeff.

 

On Thu, May 20, 2010 at 10:09 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, May 20, 2010 at 08:58:35PM -0300, Jefferson Andrade wrote:
> private val buffer = new HashMap[Int,Expr]()
>
> private def buildExpr(i: Int): Expr = {...}
>
> def getExpr(i: Int): Expr = buffer.getOrElseUpdate(i, buildExpr(i))
>
> I think it works fine the way it is, but maybe it would be better if
> there was a way to declare buffer inside getExpr since it is used
> nowhere else.

scala> def foo(x: Int) = { println("calculating " + x) ; x }
foo: (x: Int)Int

scala> val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int] ;  (x: Int) => buffer.getOrElseUpdate(x, foo(x)) }
getExpr: (Int) => Int = <function1>

scala> getExpr(5)
calculating 5
res0: Int = 5

scala> getExpr(5)
res1: Int = 5

scala> getExpr(6)
calculating 6
res2: Int = 6

scala> getExpr(6)
res3: Int = 6

--
Paul Phillips      | The important thing here is that the music is not in
Stickler           | the piano.  And knowledge and edification is not in the
Empiricist         | computer.  The computer is simply an instrument whose
pull his pi pal!   | music is ideas.  -- Alan Kay

Hi. I'm not sure of what "syntactically irrelevant" means. I am not saying it is a bad solution. I just whant to understand.

Lets say I need to use reflection, will the function be returned by getMethod, for example?

Jeff.

Em 21/05/2010 14:46, "razie" <razie@razie.com>escreveu:

Distinction is syntactically irrelevant…it’s a member! you can override it in derived classes too

 

scala> class Mine {

     | def foo(x: Int) = { println("calculating " + x) ; x }

     |

     | val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int] ;

(x: Int) => buffer.getOrElseUpdate(x, foo(x)) }

     |

     | }

defined class Mine

 

scala> val m = new Mine()

m: Mine = Mine@1bc93a7

 

scala> m getExpr 5

calculating 5

res3: Int = 5

 

scala> m getExpr 5

res4: Int = 5

 

scala> val mm = new Mine()

mm: Mine = Mine@1be3d02

 

scala> mm getExpr 5

calculating 5

res5: Int = 5

 

scala>

 

From: Jefferson Andrade [mailto:joandrade@gmail.com]
Sent: Friday, May 21, 2010 12:10 AM
To: Paul Phillips
Cc: Daniel Sobral; HamsterofDeath; scala-user@listes.epfl.ch
Subject: Re: [scala-user] partial function using a tmp listbuffer

 

Nice,

 

But in that way, getExpr would be a function and not a method, isn't it?

 

Just to ...

On 05/21/2010 01:32 PM, Jefferson Andrade wrote:
> Hi. I'm not sure of what "syntactically irrelevant" means. I am not saying
> it is a bad solution. I just whant to understand.
>
> Lets say I need to use reflection, will the function be returned by
> getMethod, for example?
>

scala> class Mine {
| def foo(x: Int) = { println("calculating " + x) ; x }
| val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int];
| (x: Int) => buffer.getOrElseUpdate(x, foo(x)) }
| }
defined class Mine

scala> classOf[Mine].getMethods.find(_.getName == "getExpr")
res9: Option[java.lang.reflect.Method] = Some(public scala.Function1
Mine.getExpr())

> Jeff.
>
> Em 21/05/2010 14:46, "razie"escreveu:
>
> Distinction is syntactically irrelevant…it’s a *member*! you can override
> it in derived classes too
>
>
>
> scala> class Mine {
>
>
>
> | def foo(x: Int) = { println("calculating " + x) ; x }
>
> |
>
> | val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int]
> ;
>
>
>
> (x: Int) => buffer.getOrElseUpdate(x, foo(x)) }
>
> |
>
> | }
>
> defined class Mine
>
>
>
> scala> val m = new Mine()
>
> m: Mine = Mine@1bc93a7
>
>
>
> scala> m getExpr 5
>
> calculating 5
>
> res3: Int = 5
>
>
>
> scala> m getExpr 5
>
> res4: Int = 5
>
>
>
> scala> val mm = new Mine()
>
> mm: Mine = Mine@1be3d02
>
>
>
> scala> mm getExpr 5
>
> calculating 5
>
> res5: Int = 5
>
>
>
> scala>
>
>
> ------------------------------
>
> *From:* Jefferson Andrade [mailto:joandrade@gmail.com]
> *Sent:* Friday, May 21, 2010 12:10 AM
> *To:* Paul Phillips
> *Cc:* Daniel Sobral; HamsterofDeath; scala-user@listes.epfl.ch
> *Subject:* Re: [scala-user] partial function using a tmp listbuffer
>
>
>
>
>
> Nice,
>
>
>
> But in that way, getExpr would be a function and not a method, isn't it?
>
>
>
> Just to ...
>
>

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}

What I meant is that you invoke it like a method, you can override it like a method…from a syntax perspective at least, it is a method.

 

It actually turns into a method, like MonkeeSage showed.

 

In scala, remember that a val can be thought of as a combination of an accessor method and an internal private field. You could explore these things in either the scala repl or the eclipse debugger…

 

From: Jefferson Andrade [mailto:joandrade@gmail.com]
Sent: Friday, May 21, 2010 2:33 PM
To: razie
Cc: scala-user@listes.epfl.ch
Subject: Re: RE: [scala-user] partial function using a tmp listbuffer

 

Hi. I'm not sure of what "syntactically irrelevant" means. I am not saying it is a bad solution. I just whant to understand.

Lets say I need to use reflection, will the function be returned by getMethod, for example?

Jeff.

Em 21/05/2010 14:46, "razie" <razie@razie.com>escreveu:

Distinction is syntactically irrelevant…it’s a member! you can override it in derived classes too

 

scala> class Mine {

     | def foo(x: Int) = { println("calculating " + x) ; x }

     |

     | val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int] ;

(x: Int) => buffer.getOrElseUpdate(x, foo(x)) }

     |

     | }

defined class Mine

 

scala> val m = new Mine()

m: Mine = Mine@1bc93a7

 

scala> m getExpr 5

calculating 5

res3: Int = 5

 

scala> m getExpr 5

res4: Int = 5

 

scala> val mm = new Mine()

mm: Mine = Mine@1be3d02

 

scala> mm getExpr 5

calculating 5

res5: Int = 5

 

scala>

 

From: Jefferson Andrade [mailto:joandrade@gmail.com]
Sent: Friday, May 21, 2010 12:10 AM
To: Paul Phillips
Cc: Daniel Sobral; HamsterofDeath; scala-user@listes.epfl.ch
Subject: Re: [scala-user] partial function using a tmp listbuffer

 

Nice,

 

But in that way, getExpr would be a function and not a method, isn't it?

 

Just to ...

OK. Thanks.

On Fri, May 21, 2010 at 5:26 PM, razie <razie@razie.com> wrote:

What I meant is that you invoke it like a method, you can override it like a method…from a syntax perspective at least, it is a method.

 

It actually turns into a method, like MonkeeSage showed.

 

In scala, remember that a val can be thought of as a combination of an accessor method and an internal private field. You could explore these things in either the scala repl or the eclipse debugger…

 

From: Jefferson Andrade [mailto:joandrade@gmail.com]
Sent: Friday, May 21, 2010 2:33 PM
To: razie
Cc: scala-user@listes.epfl.ch
Subject: Re: RE: [scala-user] partial function using a tmp listbuffer

 

Hi. I'm not sure of what "syntactically irrelevant" means. I am not saying it is a bad solution. I just whant to understand.

Lets say I need to use reflection, will the function be returned by getMethod, for example?

Jeff.

Em 21/05/2010 14:46, "razie" <razie@razie.com>escreveu:

Distinction is syntactically irrelevant…it’s a member! you can override it in derived classes too

 

scala> class Mine {

     | def foo(x: Int) = { println("calculating " + x) ; x }

     |

     | val getExpr = { val buffer = new collection.mutable.HashMap[Int, Int] ;

(x: Int) => buffer.getOrElseUpdate(x, foo(x)) }

     |

     | }

defined class Mine

 

scala> val m = new Mine()

m: Mine = Mine@1bc93a7

 

scala> m getExpr 5

calculating 5

res3: Int = 5

 

scala> m getExpr 5

res4: Int = 5

 

scala> val mm = new Mine()

mm: Mine = Mine@1be3d02

 

scala> mm getExpr 5

calculating 5

res5: Int = 5

 

scala>

 

From: Jefferson Andrade [mailto:joandrade@gmail.com]
Sent: Friday, May 21, 2010 12:10 AM
To: Paul Phillips
Cc: Daniel Sobral; HamsterofDeath; scala-user@listes.epfl.ch
Subject: Re: [scala-user] partial function using a tmp listbuffer

 

Nice,

 

But in that way, getExpr would be a function and not a method, isn't it?

 

Just to ...

--
"You question the worthiness of my Code? I should kill you where you stand!"