improve scala autotranslation

[scottdraves]

[scottdraves]

<console>:100: error: the result type of an implicit conversion must be more specific than AnyRef
       beakerx.bar(0)
                   ^

[scottdraves]

@jpallas any advice on how to do this right?

[jpallas]

I don't know about "right", but maybe we can try for "more useful". 😀

Seriously, there are a couple of issues. Least of these is the complaint about the implicit conversion, which is somehow due to using AnyRef instead of Any in applyDynamic. Fixing that ends up trying to invoke a method by name on the NamespaceClient, which is not at all useful.

So, a good question to answer might be "What should beakerx.name(params) mean?" A simple answer might be beakerx.name.apply(params). I'm not sure if there's a better answer. We're not expecting to do remote invocations through the auto translation machinery, right? It's just data.

Given that, a fundamental problem is that there is no meaningful return type information for lookups. That lands us in the world of runtime reflection, a world that Scala does not like very well. I think there are two main choices: make the user supply an explicit type (which we can either try to validate or just trust) or wrap the return values of any operations on beakerx in dynamic wrappers that basically do reflective calls for everything and leave the interpreter completely in the dark about the actual type.

My gut says that at some point if we care about importing a value into Scala, we will need to declare a type. The question is when.

There's a secondary problem, which is that the auto translation stuff is mapping all the incoming collections into Java types instead of Scala types. I suspect this is related to the fact that ScalaBeakerXJsonSerializer.fromJson does not involve calling serializer.deserialize but TBH the serialization/deserialization stuff is pretty hard for me to follow.

[scottdraves]

Thanks Joe. I think the last point about using Scala types is a good place to start.
Indeed no plans for remote invocation. Java is similarly clumsy with Json deserialization and we should take that approach.

[jaroslawmalekcodete]

Hi
so far I haven't found a better solution than using asInstanceOf method
look at the examples below

I added implicit class ObjectEnhancement(obj: Any) { def as[T] = obj.asInstanceOf[T]}
so we can use beakerx.bar.as[List[Int]] instead of beakerx.bar.asInstanceOf[List[Int]]

What do you think about this solution?

[jpallas]

I've been thinking about a similar approach, taking advantage of the way that Dynamic works. You can add a type parameter to selectDynamic, which makes it possible to just say beakerx.foo[Int] and specify the type you want. A little bit of implicit magic can make it default to Any if no explicit type is specified.

I wish there were a way to validate the type at runtime, so it would be more than just a shorthand for asInstanceOf and might avoid surprises later on if List[String] turns out to actually be List[Int]. But that's not really possible.

The main thing that bothers me about as is that it might be confused with Spark's as. Applying as to anything might mean that people who misapply Spark's as get an error that steers them in the wrong direction.