Re: Java nested static classes

Carlos Pita wrote:
> Hi all,

Hi Carlos,

> I'm having trouble when trying to access nested static classes from a
> java lib (lucene). Namely Field.Index and Field.Store as documented
> here:
> 
> file:///data1/install/java5-packages/docs/lucene-2.0.0/api/index.html
> 
> I guess scala maps these static classes to singleton objects or
> something, but anyway Field.Index and Field.Store are not working. Are
> java nested static classes supported? Which is the way to deal with
> them?

In what way it's not working? This program compiles (using scala's 
latest release):

import org.apache.lucene.document._

object Main extends Application {
   val i: Field.Index = new Field.Index
}

For java nested/inner classes, Scala creates type aliases in their 
enclosing class, so Field (as seen from Scala programs) looks like 
having a 'type Index = Field$Index' inside it. Note that for Java inner 
classes the outer instance is not passed automatically when 
instantiated. A more complete scheme which handles Java inner classes 

Re: Java nested static classes

On Wed, Nov 01, 2006 at 10:58:26AM +0100, Iulian Dragos wrote:
> In what way it's not working? This program compiles (using scala's latest release):

Try accessing a static member of Field.Index, e.g. Field.Index.NO. In
that case you have to use Field$Index, which seems at least inconsistent.

-- Jamie Webb

Re: Java nested static classes

> In what way it's not working? This program compiles (using scala's 
> latest release):
> 
> import org.apache.lucene.document._
> 
> object Main extends Application {
>    val i: Field.Index = new Field.Index
> }

It's true. But val index = Field.Index.YES (which was the line that
initially motivated my question) still fails to compile complaining
that:

value Index is not a member of object org.apache.lucene.document.Field	

Regards,
Carlos

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Re: Java nested static classes

View not applied

Can someone tell me why the following does not work?

object CoerceTest1 {
   implicit def int2string(s:Int):String = ""

   trait T
   class Bla[A](a:A)
   def f(m:Bla[String]) = ()

   val s:String = 42
   f(new Bla(42))
   f(new Bla(int2string(42)) with T)
   f(new Bla(42) with T) // error
}

Only the last line with the mixin and without explicit conversion gives 
an error:
type mismatch;
  found: CoerceTest1.this.Bla[scala.Int] with CoerceTest1.this.T{ ... }
  required: CoerceTest1.this.Bla[java.lang.String]	

It works with a non-generic Bla:

object CoerceTest2 {
   implicit def int2string(s:Int):String = ""

   trait T
   class Bla(s:String)
   def f(m:Bla) = ()

   f(new Bla(42) with T)
}

Seems to be a bug to me.

Ingo

Re: View not applied

On Wed, Nov 01, 2006 at 06:23:23PM +0100, Ingo Maier wrote:
> Only the last line with the mixin and without explicit conversion gives an error:
> type mismatch;
>  found: CoerceTest1.this.Bla[scala.Int] with CoerceTest1.this.T{ ... }
>  required: CoerceTest1.this.Bla[java.lang.String]	

It's not really a bug, just a limitation. The type system will not
backtrack to solve arbitrary constraints. Since it already managed to
construct a Bla[Int], it will never try the implicit coercion.

Essentially, with Scala type inference should be regarded as a
privilege, not a right. If it doesn't work, add type annotations.

Unfortunately, AIUI complete type inference is computationally
infeasible. Fortunately, Scala's partial type inference works most of
the time.

-- Jamie Webb

Re: View not applied

Ingo Maier wrote:
> Can someone tell me why the following does not work?
> 
> object CoerceTest1 {
>   implicit def int2string(s:Int):String = ""
> 
>   trait T
>   class Bla[A](a:A)
>   def f(m:Bla[String]) = ()
> 
>   val s:String = 42
>   f(new Bla(42))
>   f(new Bla(int2string(42)) with T)
>   f(new Bla(42) with T) // error
> }
> 
> Only the last line with the mixin and without explicit conversion gives 
> an error:
> type mismatch;
>  found: CoerceTest1.this.Bla[scala.Int] with CoerceTest1.this.T{ ... }
>  required: CoerceTest1.this.Bla[java.lang.String]   
> 
> It works with a non-generic Bla:
> 
> object CoerceTest2 {
>   implicit def int2string(s:Int):String = ""
> 
>   trait T
>   class Bla(s:String)
>   def f(m:Bla) = ()
> 
>   f(new Bla(42) with T)
> }
> 
 > Seems to be a bug to me.
 >
This would probably be very tricky to achieve. I was mildly surprised 
that the first case went through!

  -- Martin

Re: View not applied

Thanks Martin and Jamie,

I see your point. I reread the specs section about views:

"If an expression e is of type T, and T does not conform to the 
expression's expected type pt. In this case an implicit v is searched 
which is applicable to e and whose result type conforms to pt."

So, subexpressions of e aren't considered for coercions so that the type 
of e would change. It seems that I silently assumed that this is the 
case. That's why I wasn't surprised that the first one

f(new Bla(42))

works. According to the rule 42 won't be coerced, as it's fine to pass 
an Int to Bla's constructor. Type annotations work here, however, as 
Jamie pointed out.

Ingo

Martin Odersky wrote:
> Ingo Maier wrote:
>> Can someone tell me why the following does not work?
>>
>> object CoerceTest1 {
>>   implicit def int2string(s:Int):String = ""
>>
>>   trait T
>>   class Bla[A](a:A)
>>   def f(m:Bla[String]) = ()
>>
>>   val s:String = 42
>>   f(new Bla(42))
>>   f(new Bla(int2string(42)) with T)
>>   f(new Bla(42) with T) // error
>> }
>>
>> Only the last line with the mixin and without explicit conversion 
>> gives an error:
>> type mismatch;
>>  found: CoerceTest1.this.Bla[scala.Int] with CoerceTest1.this.T{ ... }
>>  required: CoerceTest1.this.Bla[java.lang.String]  
>> It works with a non-generic Bla:
>>
>> object CoerceTest2 {
>>   implicit def int2string(s:Int):String = ""
>>
>>   trait T
>>   class Bla(s:String)
>>   def f(m:Bla) = ()
>>
>>   f(new Bla(42) with T)
>> }
>>
>  > Seems to be a bug to me.
>  >
> This would probably be very tricky to achieve. I was mildly surprised 
> that the first case went through!
> 
>  -- Martin
> 
> 

Re: Java nested static classes

Jamie Webb wrote:
> On Wed, Nov 01, 2006 at 10:58:26AM +0100, Iulian Dragos wrote:
> 
>>In what way it's not working? This program compiles (using scala's latest release):
> 
> 
> Try accessing a static member of Field.Index, e.g. Field.Index.NO. In
> that case you have to use Field$Index, which seems at least inconsistent.

Thanks for the clarification. It has been entered as a bug, and a fix is 
already in, so the next release should fix this problem.

Iulian

Re: a note on the impact of type erasure

Hi Ross,

This is an old trick I used to use in Java. It breaks down really  
quickly whenever type parameters are bound indirectly, e.g.,

def foo[a,b] = new HashMap[a,b];
val x = foo[String,Int];

or

def foo[a,b](x : Any, key : a) : b = x match {
case x : Map[a,b] => x(key)
}

Sean

On Oct 26, 2006, at 6:55 PM, Judson, Ross wrote:

> If you have a case where you really need to be able to differentiate
> between a two parameterized types that have the same erasure, you can
> use this workaround:
>
>   trait StringStringMap extends scala.collection.Map[String,String];
>   trait IntStringMap extends scala.collection.Map[Int,String];
>
>   val ss = new scala.collection.mutable.HashMap[String,String] with
> StringStringMap;
>   val is = new scala.collection.immutable.ListMap[Int,String] with
> IntStringMap;
>
>   def checker[K,V](map: scala.collection.Map[K,V]) = map match {
>     case x: StringStringMap => "StringStringMap"
>     case y: IntStringMap => "IntStringMap"
>   }
>
>   Console.println(checker(ss) + ' ' + checker(is));
>
> By making a trait that exhibits the characteristics you are looking  
> for,
> you are creating a classfile that will exist at runtime, and that  
> can be
> explicitly checked with instanceof. In the JVM it manifests as another
> interface that the map class is implementing.
>
> RJ