Re: package naming and implicit conversion

>>>>> "Stuart" == Stuart Cook writes:

>> 1.foo
>>
>> will not compile

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

This thread began when Russ said:

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 ..."

In the book example, the conversion is from Dollar to Euro, and the
conversion method is in the Dollar companion object. If the method were
in the Euro object instead, it wouldn't automatically be picked up.

That's why "1.foo" doesn't compile; there's no conversion from Int to
Foo in Int's companion object (I don't think Int even has a companion
object). It's irrelevant that one exists in Foo's companion object.

It seems to me that the claim the book actually makes is in fact true,
as Ricky Clarkson already showed in his reply.

On Thu, Feb 5, 2009 at 3:41 PM, Seth Tisue wrote:
> In the book example, the conversion is from Dollar to Euro, and the
> conversion method is in the Dollar companion object. If the method were
> in the Euro object instead, it wouldn't automatically be picked up.
>
> That's why "1.foo" doesn't compile; there's no conversion from Int to
> Foo in Int's companion object (I don't think Int even has a companion
> object). It's irrelevant that one exists in Foo's companion object.

Funny, the book says precisely the opposite:

"The compiler will also look for implicit definitions in the companion
object of the source or expected target types of the conversion."
(Under "Scope Rule" in "Rules for implicits")

> It seems to me that the claim the book actually makes is in fact true,
> as Ricky Clarkson already showed in his reply.

The book gives no indication that the special rule does not apply when
converting the receiver of a method call. In fact, the paragraph
before the quoted statement discusses converted-receiver methods quite
happily.

Stuart

On Thu, Feb 05, 2009 at 04:31:16PM +1100, Stuart Cook wrote:
> Funny, the book says precisely the opposite:
>
> "The compiler will also look for implicit definitions in the companion
> object of the source or expected target types of the conversion."
> (Under "Scope Rule" in "Rules for implicits")

Here is what the specification says:

The implicit scope of a type T consists of all companion modules (§5.4) of classes
that are associated with the implicit parameter’s type. Here, we say a class C is asso-
ciated with a type T , if it is a base class (§5.1.2) of some part of T .

(That is about implicit parameter scope, but for implicit conversions "search proceeds as in the case of implicit parameters.")

All companion modules associated with the parameter's type, but nothing about the expected target type. I would think the book is
wrong, at least as I read that excerpt with no additional context, except that drm's example works:

object drm {
class Foo { def foo = "foo" }
object Foo { implicit def fooOfInt(i : Int) = new Foo }

// def go() = 1.foo // doesn't compile
def go2 = (1: Foo).foo // does
}

Now as to why go2 works and go doesn't, I think it's because the inferred type of 1 in go() is something like { def foo(): ? }
whereas in go2() it's Foo since you told it. And in that case it does look in the companion object of the target type. But I can't
find any mention of it in the spec, maybe someone could point it out if it's in there?

On Thu, Feb 5, 2009 at 5:08 PM, Paul Phillips wrote:
> Now as to why go2 works and go doesn't, I think it's because the inferred type of 1 in go() is something like { def foo(): ? }
> whereas in go2() it's Foo since you told it. And in that case it does look in the companion object of the target type. But I can't
> find any mention of it in the spec, maybe someone could point it out if it's in there?

After re-reading the book more carefully I came to the same
conclusion, but only because I now know the actual behaviour (from
David's message). There's no way I would have interpreted the book
"correctly" if I didn't already know what the "correct" behaviour was.

Stuart

>>>>> "Stuart" == Stuart Cook writes:

>> That's why "1.foo" doesn't compile; there's no conversion from Int
>> to Foo in Int's companion object (I don't think Int even has a
>> companion object). It's irrelevant that one exists in Foo's
>> companion object.

Stuart> Funny, the book says precisely the opposite:
Stuart> "The compiler will also look for implicit definitions in the
Stuart> companion object of the source or expected target types of the
Stuart> conversion." (Under "Scope Rule" in "Rules for implicits")

Doh, sorry! I should have read backwards from the sentence Russ quoted,
as well as forwards...