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

package naming and implicit conversion

6 replies
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
I was really looking forward to learning Scala, but I am getting very frustrated. Part of the problem is probably that I don't know Java (I'm an aerospace engineer who has been using Python for a few years). I have a couple of beginner questions.

Does it make sense to label an entire file with a package name that is the same as the main class in the file, as in

package MoonRocket
class MoonRocket() ....

or is that just asking for trouble?

As for implicit conversions, I am flummoxed. I am reading page 441 of the Odersky book, the section Rules for Implicits. It says plain as day that if you put an implicit definition in the companion object, "The compiler will find such an associated conversion every time it needs to convert ..." But I am discovering otherwise. What gives? Is the book lying?

--
http://RussP.us
Detering Dirk
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
RE: package naming and implicit conversion

> It says plain as day that if you put an implicit
> definition in the companion object, "The compiler will find
> such an associated conversion every time it needs to convert
> ..." But I am discovering otherwise. What gives? Is the book lying?

Truth is sometimes a relatively flexible thing dwelling somewhere
in an analogous continuum, especially if manifested in spoken
prosa language...

But back from philosophical expeditions to empirical research:

What do you mean with "discovering"?

What is the experiment's setting?
What is the observed behaviour?

Given that, perhaps someone can specify the overlapping parts
of the text interpretation and the factual results.

(Hmm. That's weird... after all it *isn't* monday today)

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: package naming and implicit conversion
Russ,

The usual package naming convention is all lowercase - moonrocket or moon.rocket.  I have no idea what will happen if you do what you asked instead, as I've never done that.

Can you give an example of the implicit lies?

Ricky.

2009/2/4 Russ Paielli <russ [dot] paielli [at] gmail [dot] com>
I was really looking forward to learning Scala, but I am getting very frustrated. Part of the problem is probably that I don't know Java (I'm an aerospace engineer who has been using Python for a few years). I have a couple of beginner questions.

Does it make sense to label an entire file with a package name that is the same as the main class in the file, as in

package MoonRocket
class MoonRocket() ....

or is that just asking for trouble?

As for implicit conversions, I am flummoxed. I am reading page 441 of the Odersky book, the section Rules for Implicits. It says plain as day that if you put an implicit definition in the companion object, "The compiler will find such an associated conversion every time it needs to convert ..." But I am discovering otherwise. What gives? Is the book lying?

--
http://RussP.us

Jon Pretty
Joined: 2009-02-02,
User offline. Last seen 42 years 45 weeks ago.
Re: package naming and implicit conversion

Hi Russ,

Russ Paielli wrote:
> Does it make sense to label an entire file with a package name that is
> the same as the main class in the file, as in

It only makes sense to name the file after its contents in that it's a
strong suggestion as to which file you might want to edit, and I've
noticed some Scala developers follow this convention, but it's not
required by Scala (but is by Java).

For a project (e.g. an application, i.e. a collection of related
classes), choose a single package name which encompasses the project.
This will probably not be the same as the class name, and it is
conventionally a reversed domain name (in lower case).

As an example, it would be perfectly reasonable to structure your Moon
Rocket project as follows:

directory src:
file main.scala:
package com.paielli.moonrocket:
class Main
file space.scala:
package com.paielli.moonrocket:
trait LargeBody
class Moon
class Sun
file rocket.scala:
package com.paielli.moonrocket:
object Physics
class Rocket

etc

> As for implicit conversions, I am flummoxed. I am reading page 441 of
> the Odersky book, the section Rules for Implicits. It says plain as day
> that if you put an implicit definition in the companion object, "The
> compiler will find such an associated conversion every time it needs to
> convert ..." But I am discovering otherwise. What gives? Is the book lying?

Hmmm. I didn't expect this to work, and it doesn't, and I don't have a
copy of the book to hand to check. You should import your implicit
method, e.g.:

object Foo {
implicit def view(x : A) : B = ...
}

// Anywhere else
import Foo._
def foo(a : A) : Z = ...
foo(instanceOfB) // implicit gets applied here

You can substitute A or B for Foo, and the above holds.

Cheers,
Jon

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: package naming and implicit conversion
ricky@ricky-desktop:~$ cat test.scala
case class Foo(x: Int)
object Foo { implicit def foo2Int(foo: Foo) = foo.x }

object Main { def main(args: Array[String]) = {
 val y: Int = Foo(10);
 println(y) } }
                                                                                                                                                                                                                    
ricky@ricky-desktop:~$ scalac test.scala
ricky@ricky-desktop:~$ scala Main
10

2009/2/4 Jon Pretty <jon [dot] pretty [at] sygneca [dot] com>
Hi Russ,

Russ Paielli wrote:
> Does it make sense to label an entire file with a package name that is
> the same as the main class in the file, as in

It only makes sense to name the file after its contents in that it's a
strong suggestion as to which file you might want to edit, and I've
noticed some Scala developers follow this convention, but it's not
required by Scala (but is by Java).

For a project (e.g. an application, i.e. a collection of related
classes), choose a single package name which encompasses the project.
This will probably not be the same as the class name, and it is
conventionally a reversed domain name (in lower case).

As an example, it would be perfectly reasonable to structure your Moon
Rocket project as follows:

 directory src:
   file main.scala:
     package com.paielli.moonrocket:
       class Main
   file space.scala:
     package com.paielli.moonrocket:
       trait LargeBody
       class Moon
       class Sun
   file rocket.scala:
     package com.paielli.moonrocket:
       object Physics
       class Rocket

etc

> As for implicit conversions, I am flummoxed. I am reading page 441 of
> the Odersky book, the section Rules for Implicits. It says plain as day
> that if you put an implicit definition in the companion object, "The
> compiler will find such an associated conversion every time it needs to
> convert ..." But I am discovering otherwise. What gives? Is the book lying?

Hmmm.  I didn't expect this to work, and it doesn't, and I don't have a
copy of the book to hand to check.  You should import your implicit
method, e.g.:

 object Foo {
    implicit def view(x : A) : B = ...
 }

 // Anywhere else
 import Foo._
 def foo(a : A) : Z = ...
 foo(instanceOfB)  // implicit gets applied here

You can substitute A or B for Foo, and the above holds.

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.


DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: package naming and implicit conversion
On Wed, Feb 4, 2009 at 12:12 PM, Jon Pretty <jon [dot] pretty [at] sygneca [dot] com> wrote:
> As for implicit conversions, I am flummoxed. I am reading page 441 of
> the Odersky book, the section Rules for Implicits. It says plain as day
> that if you put an implicit definition in the companion object, "The
> compiler will find such an associated conversion every time it needs to
> convert ..." But I am discovering otherwise. What gives? Is the book lying?

Hmmm.  I didn't expect this to work, and it doesn't, and I don't have a
copy of the book to hand to check.  You should import your implicit
method, e.g.:

Actually it does.

What can cause confusion is that normally an implicit conversion on x will be picked up if you do x.foo and it doesn't type check. However if you have

class Foo{
   def foo = "foo"
}

object Foo{
   implicit def fooOfInt(i : Int) = new Foo;
}

1.foo

will not compile

but

(1 : Foo).foo

will.

This is probably neccessary behaviour, but now that I think about I'm not sure it's specced. I'd have to take a look again.
Stuart Cook
Joined: 2008-12-24,
User offline. Last seen 42 years 45 weeks ago.
Re: package naming and implicit conversion

On Wed, Feb 4, 2009 at 11:39 PM, David MacIver wrote:
> 1.foo
>
> will not compile

That's a pretty serious restriction to be left unstated. I don't think
I've ever written an implicit conversion for any reason other than
adding new methods to an existing class, so I had always assumed that
the book was just flat-out wrong.

Stuart

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