Why are RichInt, RichFloat, ... final?

I guess you have 2 options. 1, convince the maintainers of Rich<Foo> to extend them, or through the beauty of implict, write ScissRichInt that has those methods:

class MyRichInt(val value: Int) {
  def *%*(i: Int): Int = Math.sqrt(value * i) // some crazy op
}

object MyRichInt {
  implicit def intAsMyRichInt(i: Int): MyRichInt = new MyRichInt(i)
}

Now, as well as using all the RichInt methods on an Int, you will also be able to say:

4 *%* 7

and have it work out for you.

Matthew

(disclaimer: I've not put this code through a compiler)

On 27 April 2010 23:57, Sciss <contact@sciss.de> wrote:

hi,

what is the reason that RichInt, RichFloat, etc. are final? i find them rather "poor" and would like to add a few more methods, but obviously cannot subclass them....

best, -sciss-

Extending them would gain you nothing, as the implicit conversion wouldn't apply to subclasses. Meanwhile, having them as final means the method call is static, not virtual, resulting in a small performance gain.

On Tue, Apr 27, 2010 at 7:57 PM, Sciss <contact@sciss.de> wrote:

hi,

what is the reason that RichInt, RichFloat, etc. are final? i find them rather "poor" and would like to add a few more methods, but obviously cannot subclass them....

best, -sciss-

--
Daniel C. Sobral

I travel to the future all the time.

On 28 Apr 2010, at 00:05, Matthew Pocock wrote:
> ... through the beauty of implict, write ScissRichInt ...

Which is exactly what I was asking about here:

http://scala-programming-language.1934581.n4.nabble.com/Extending-Int-tt...

Which, I'm hoping that as nobody responded telling me that I'd got this completely wrong, will work :-)

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

On Tue, Apr 27, 2010 at 10:47 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

Meanwhile, having them as final means the method call is static, not virtual, resulting in a small performance gain.

Non-static method calls, final or not, are always virtual in the byte code. In this case both would be converted to static calls by the JIT.

Indeed. Funny, I could swear I had seen it decompiled differently.

On Wed, Apr 28, 2010 at 10:16 AM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Tue, Apr 27, 2010 at 10:47 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

Meanwhile, having them as final means the method call is static, not virtual, resulting in a small performance gain.

Non-static method calls, final or not, are always virtual in the byte code. In this case both would be converted to static calls by the JIT.

--
Daniel C. Sobral

I travel to the future all the time.