Alternative to implicit?

On Wed, Dec 1, 2010 at 10:57 PM, Bill Back <billback@mac.com> wrote:

I have the following class:

class Field[T](val name : String) {
 var value : T = _
}

object Field {
 implicit fieldToInt[Int](f: Field[Int]) : Int = f.value

This does exactly what my code below will do,
you're confusing the type Int with a type parameter declaration.
 

}

I want to be able to do the following:

val field = new Field[Int]("field")
field.value = 12
val ival : Int = field // equivilant to val ival : Int = field.value

class Field...
{
  def apply() = value
}
 

In the last line, I want to have the value assigned.  I can do this via implicits, but wonder if there isn't an

val i: Int = field() <-- good enuff?
 

easier way so that I don't have to declare every possible conversion.

every possible conversion?

scala> case class Field[T](val value: T)
defined class Field

scala> implicit
     | def field2T[T](field: Field[T]) : T = field.value
field2T: [T](field: Field[T])T

scala> val f = Field[Int](3)
f: Field[Int] = Field(3)

scala> val i:Int = f
i: Int = 3

Thanks for any help.

Bill.

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

On Wed, Dec 1, 2010 at 2:03 PM, √iktor Klang <viktor.klang@gmail.com> wrote:

[...] you're confusing the type Int with a type parameter declaration. [...]

This is a recurring problem.  Would it be desirable and feasible to make the issue throw a warning when a type parameter/member name shadows an in-scope type name?
-0xe1a

So you'd have to do:

def foo[override Int] ?

On Dec 3, 2010 6:56 PM, "Alex Cruise" <alex@cluonflux.com> wrote:

On Wed, Dec 1, 2010 at 2:03 PM, √iktor Klang <viktor.klang@gmail.com> wrote:

[...] you're confusing the type Int with a type parameter declaration. [...]

This is a recurring problem.  Would it be desirable and feasible to make the issue throw a warning when a type parameter/member name shadows an in-scope type name?
-0xe1a

On Fri, Dec 03, 2010 at 09:56:19AM -0800, Alex Cruise wrote:
> This is a recurring problem. Would it be desirable and feasible to
> make the issue throw a warning when a type parameter/member name
> shadows an in-scope type name?

The problem is that it's harder to do than you think without being
noisy. You don't appreciate how much intentional shadowing takes place
until you start writing warnings for it.

I should at least warn when people use primitive type names as type
parameters though, that's always going to be wrong (wrong aesthetically
at the very least.)

I've improved the error messages a lot when this does arise, but when
people manage to structure things such that there's no type mismatch to
give it away they can scratch the head a while. I was going to cite
some examples of improvements and I can't find them, which makes me
think I might have lost track of a whole branch of error message code I
thought I'd checked in. Don't trust me with your kids, anyone.

On Fri, Dec 3, 2010 at 12:20 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Dec 03, 2010 at 09:56:19AM -0800, Alex Cruise wrote:
> This is a recurring problem.  Would it be desirable and feasible to
> make the issue throw a warning when a type parameter/member name
> shadows an in-scope type name?

The problem is that it's harder to do than you think without being
noisy.  You don't appreciate how much intentional shadowing takes place
until you start writing warnings for it.

Interesting.  Just to clarify, are you talking about one *type member/parameter name* (I don't know the term that unifies these) shadowing another *type member/parameter name*, or *type member/parameter names* shadowing a *type name*?  Because the former is commonly done intentionally, but IMO the latter is less likely to be done intentionally.  I'd be happy to be proven wrong with examples though.  

I should at least warn when people use primitive type names as type
parameters though, that's always going to be wrong (wrong aesthetically
at the very least.)

Agreed.

I've improved the error messages a lot when this does arise, but when
people manage to structure things such that there's no type mismatch to
give it away they can scratch the head a while.  I was going to cite
some examples of improvements and I can't find them, which makes me
think I might have lost track of a whole branch of error message code I
thought I'd checked in.  Don't trust me with your kids, anyone.

"Luckily" kids get louder when you leave them alone for awhile, whereas speculative branches seem to jump into a spider-hole at the drop of a hat. ;)
-0xe1a