More Overload Resolution

Have a look at Section 6.25.3 of the scala specification. In your case

(1) def at(index: Int): FOL_Entity
(2) def at(path: Array[Int]): FOL_Entity = to(this, this, path, 0)
(3) def at(path: Int*): FOL_Entity = to(this, this, path.toArray[Int], 0)
(4) def at(path: List[Int]): FOL_Entity = to(this, path, this, path)

>  at(1)

versions (1) and (3) are applicable, and the (1) is the most specific out
of the two. This is because (3) is applicable to the parameter types of (1),
but not the other way round, so (1) is more specific.

Lukas




On Fri, Mar 27, 2009 at 02:42, Randall R Schulz <rschulz@sonic.net> wrote:

Hi,

Consider these methods from a single class:

 def at(index: Int): FOL_Entity

 def at(path: Array[Int]): FOL_Entity = to(this, this, path, 0)
 def at(path: Int*): FOL_Entity = to(this, this, path.toArray[Int], 0)
 def at(path: List[Int]): FOL_Entity = to(this, path, this, path)

I am curious about the resolution of calls with a single integer
argument. It appears from empirical testing to go to the abstract
method, which is what I want, but I am uncertain whether this is
guaranteed / specified behavior or if I'm just getting lucky somehow.

If the part of my understanding about which I am not in doubt is
correct, the other overloads and / or call patterns don't create
ambiguity.

I'd appreciate learning if what ambiguities afoot here and how they're
resolved.


Randall Schulz

On Friday March 27 2009, Lukas Rytz wrote:
> Have a look at Section 6.25.3 of the scala specification. In your
> case
>
> (1) def at(index: Int): FOL_Entity
> (2) def at(path: Array[Int]): FOL_Entity = to(this, this, path, 0)
> (3) def at(path: Int*): FOL_Entity = to(this, this, path.toArray[Int], 0)
> (4) def at(path: List[Int]): FOL_Entity = to(this, path, this, path)
>
> > at(1)
>
> versions (1) and (3) are applicable, and the (1) is the most specific
> out of the two. This is because (3) is applicable to the parameter
> types of (1), but not the other way round, so (1) is more specific.

Excellent. Thank you.

> Lukas

Randall Schulz