- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
.asViewOf[T], .isViewOf[T] for <% relationship
It seems very strange to me that there are no methods on the Any class
corresponding to the <% type relationship, ie. def asViewOf[T]:T and def
isViewOf[T]:Boolean, in the same manner as the .isInstanceOf[T] and
.asInstanceOf[T] methods.
I've run into a few situations where it would have been handy -- does anyone
else agree? It seems a glaring omission.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
On Tue, Nov 24, 2009 at 6:54 AM, Ken Scambler <ken [dot] scambler [at] gmail [dot] com> wrote:
--
Daniel C. Sobral
Veni, vidi, veterni.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
On Tue, 24 Nov 2009 10:54:28 -0200, Daniel Sobral wrote:
> How would they be written?
isViewOf would have to be magical, I think.
Any is magical anyway.
def asViewOf[T](implicit view: this.type => T): T = view(this)
seems to work in ref types.
But when would these be handy?
> On Tue, Nov 24, 2009 at 6:54 AM, Ken Scambler wrote:
>
> >
> > It seems very strange to me that there are no methods on the Any class
> > corresponding to the <% type relationship, ie. def asViewOf[T]:T and def
> > isViewOf[T]:Boolean, in the same manner as the .isInstanceOf[T] and
> > .asInstanceOf[T] methods.
> >
> > I've run into a few situations where it would have been handy -- does
> > anyone
> > else agree? It seems a glaring omission.
> > --
> > View this message in context:
> > http://old.nabble.com/.asViewOf-T-%2C-.isViewOf-T--for-%3C--relationship...
> > Sent from the Scala - User mailing list archive at Nabble.com.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
The real question is would the runtime check eventually hotspot away so that only the logic you want runs? I'm not sure this is the most optimal approach, but it was a fun creative excercise!
---------- File: test/IsViewOf.scala ----------------------
package test
case class IsViewOf[T,V](value: Boolean)
class IsViewOfHelper[T](x : T) {
def isViewOf[V](implicit check : IsViewOf[T,V]) = check.value
def asViewOf[V](implicit view : T => V) = view(x)
}
trait LowPrirorityImplicits {
implicit def default[V,T] =IsViewOf[T,V](false)
}
object IsViewOfHelper extends LowPrirorityImplicits {
implicit def hasView[V, T <% V] =IsViewOf[T,V](true)
implicit def any2IsViewOf[T](x : T) = new IsViewOfHelper(x)
}
----------- End of File --------------------------
Now the fun:
scala> import test.IsViewOfHelper._
import IsViewOfHelper._
scala> val x = 5
x: Int = 5
scala> x.isViewOf[String]
res0: Boolean = false
scala> implicit def int2String(x : Int) = x.toString
int2String: (x: Int)java.lang.String
scala> x.isViewOf[String]
res1: Boolean = true
scala> x.asViewOf[String]
res2: String = 5
2009/11/24 Michal Politowski <mpol [at] charybda [dot] icm [dot] edu [dot] pl>
Re: .asViewOf[T], .isViewOf[T] for <% relationship
On Tue, 24 Nov 2009 22:12:31 -0500, Josh Suereth wrote:
> You can accomplish this yourself in the 2.8 beta. See below.
Ah, I see. Very nice trick, the prioritisation of implicits. I didn't think
of that.
> The real question is would the runtime check eventually hotspot away so that
> only the logic you want runs? I'm not sure this is the most optimal
> approach, but it was a fun creative excercise!
>
> ---------- File: test/IsViewOf.scala ----------------------
> package test
>
> case class IsViewOf[T,V](value: Boolean)
>
> class IsViewOfHelper[T](x : T) {
> def isViewOf[V](implicit check : IsViewOf[T,V]) = check.value
> def asViewOf[V](implicit view : T => V) = view(x)
> }
>
> trait LowPrirorityImplicits {
> implicit def default[V,T] =IsViewOf[T,V](false)
> }
>
> object IsViewOfHelper extends LowPrirorityImplicits {
> implicit def hasView[V, T <% V] =IsViewOf[T,V](true)
>
> implicit def any2IsViewOf[T](x : T) = new IsViewOfHelper(x)
> }
> ----------- End of File --------------------------
>
>
> Now the fun:
>
> scala> import test.IsViewOfHelper._
> import IsViewOfHelper._
>
> scala> val x = 5
> x: Int = 5
>
> scala> x.isViewOf[String]
> res0: Boolean = false
>
> scala> implicit def int2String(x : Int) = x.toString
> int2String: (x: Int)java.lang.String
>
> scala> x.isViewOf[String]
> res1: Boolean = true
>
> scala> x.asViewOf[String]
> res2: String = 5
Re: .asViewOf[T], .isViewOf[T] for <% relationship
Unlike isInstanceOf, this isViewOf is (necessarily) based on the
static type of the reference rather than the dynamic type of the
object. But it's a very creative use of implicit prioritization
indeed!
-jason
On 11/25/09, Josh Suereth wrote:
> You can accomplish this yourself in the 2.8 beta. See below.
>
> The real question is would the runtime check eventually hotspot away so that
> only the logic you want runs? I'm not sure this is the most optimal
> approach, but it was a fun creative excercise!
>
> ---------- File: test/IsViewOf.scala ----------------------
> package test
>
> case class IsViewOf[T,V](value: Boolean)
>
> class IsViewOfHelper[T](x : T) {
> def isViewOf[V](implicit check : IsViewOf[T,V]) = check.value
> def asViewOf[V](implicit view : T => V) = view(x)
> }
>
> trait LowPrirorityImplicits {
> implicit def default[V,T] =IsViewOf[T,V](false)
> }
>
> object IsViewOfHelper extends LowPrirorityImplicits {
> implicit def hasView[V, T <% V] =IsViewOf[T,V](true)
>
> implicit def any2IsViewOf[T](x : T) = new IsViewOfHelper(x)
> }
> ----------- End of File --------------------------
>
>
> Now the fun:
>
> scala> import test.IsViewOfHelper._
> import IsViewOfHelper._
>
> scala> val x = 5
> x: Int = 5
>
> scala> x.isViewOf[String]
> res0: Boolean = false
>
> scala> implicit def int2String(x : Int) = x.toString
> int2String: (x: Int)java.lang.String
>
> scala> x.isViewOf[String]
> res1: Boolean = true
>
> scala> x.asViewOf[String]
> res2: String = 5
>
>
>
> 2009/11/24 Michal Politowski
>
>> On Tue, 24 Nov 2009 10:54:28 -0200, Daniel Sobral wrote:
>> > How would they be written?
>>
>> isViewOf would have to be magical, I think.
>> Any is magical anyway.
>>
>> def asViewOf[T](implicit view: this.type => T): T = view(this)
>> seems to work in ref types.
>>
>> But when would these be handy?
>>
>> > On Tue, Nov 24, 2009 at 6:54 AM, Ken Scambler > >wrote:
>> >
>> > >
>> > > It seems very strange to me that there are no methods on the Any class
>> > > corresponding to the <% type relationship, ie. def asViewOf[T]:T and
>> def
>> > > isViewOf[T]:Boolean, in the same manner as the .isInstanceOf[T] and
>> > > .asInstanceOf[T] methods.
>> > >
>> > > I've run into a few situations where it would have been handy -- does
>> > > anyone
>> > > else agree? It seems a glaring omission.
>> > > --
>> > > View this message in context:
>> > >
>> http://old.nabble.com/.asViewOf-T-%2C-.isViewOf-T--for-%3C--relationship...
>> > > Sent from the Scala - User mailing list archive at Nabble.com.
>>
>> --
>> Michał Politowski
>> Talking has been known to lead to communication if practiced carelessly.
>>
>
Re: .asViewOf[T], .isViewOf[T] for <% relationship
Hmm, I see that now -- and of course there is no point having a method that
executes at runtime to tell you something you already knew at compile time!
Josh, great trick, ha! I'm constantly surprised by the clever things that
are possible with implicits and the type system in Scala ;)
_retronym wrote:
>
> Unlike isInstanceOf, this isViewOf is (necessarily) based on the
> static type of the reference rather than the dynamic type of the
> object. But it's a very creative use of implicit prioritization
> indeed!
>
> -jason
>
> On 11/25/09, Josh Suereth wrote:
>> You can accomplish this yourself in the 2.8 beta. See below.
>>
>> The real question is would the runtime check eventually hotspot away so
>> that
>> only the logic you want runs? I'm not sure this is the most optimal
>> approach, but it was a fun creative excercise!
>>
>> ---------- File: test/IsViewOf.scala ----------------------
>> package test
>>
>> case class IsViewOf[T,V](value: Boolean)
>>
>> class IsViewOfHelper[T](x : T) {
>> def isViewOf[V](implicit check : IsViewOf[T,V]) = check.value
>> def asViewOf[V](implicit view : T => V) = view(x)
>> }
>>
>> trait LowPrirorityImplicits {
>> implicit def default[V,T] =IsViewOf[T,V](false)
>> }
>>
>> object IsViewOfHelper extends LowPrirorityImplicits {
>> implicit def hasView[V, T <% V] =IsViewOf[T,V](true)
>>
>> implicit def any2IsViewOf[T](x : T) = new IsViewOfHelper(x)
>> }
>> ----------- End of File --------------------------
>>
>>
>> Now the fun:
>>
>> scala> import test.IsViewOfHelper._
>> import IsViewOfHelper._
>>
>> scala> val x = 5
>> x: Int = 5
>>
>> scala> x.isViewOf[String]
>> res0: Boolean = false
>>
>> scala> implicit def int2String(x : Int) = x.toString
>> int2String: (x: Int)java.lang.String
>>
>> scala> x.isViewOf[String]
>> res1: Boolean = true
>>
>> scala> x.asViewOf[String]
>> res2: String = 5
>>
>>
>>
>> 2009/11/24 Michal Politowski
>>
>>> On Tue, 24 Nov 2009 10:54:28 -0200, Daniel Sobral wrote:
>>> > How would they be written?
>>>
>>> isViewOf would have to be magical, I think.
>>> Any is magical anyway.
>>>
>>> def asViewOf[T](implicit view: this.type => T): T = view(this)
>>> seems to work in ref types.
>>>
>>> But when would these be handy?
>>>
>>> > On Tue, Nov 24, 2009 at 6:54 AM, Ken Scambler >> >wrote:
>>> >
>>> > >
>>> > > It seems very strange to me that there are no methods on the Any
>>> class
>>> > > corresponding to the <% type relationship, ie. def asViewOf[T]:T and
>>> def
>>> > > isViewOf[T]:Boolean, in the same manner as the .isInstanceOf[T] and
>>> > > .asInstanceOf[T] methods.
>>> > >
>>> > > I've run into a few situations where it would have been handy --
>>> does
>>> > > anyone
>>> > > else agree? It seems a glaring omission.
>>> > > --
>>> > > View this message in context:
>>> > >
>>> http://old.nabble.com/.asViewOf-T-%2C-.isViewOf-T--for-%3C--relationship...
>>> > > Sent from the Scala - User mailing list archive at Nabble.com.
>>>
>>> --
>>> Michał Politowski
>>> Talking has been known to lead to communication if practiced carelessly.
>>>
>>
>
Re: .asViewOf[T], .isViewOf[T] for <% relationship
I would assume they would have to be magical, like isInstanceOf/asInstanceOf.
I can't imagine they would get used very often (again, like the iIO/aIO
methods), but surely it's indispensable on rare occasions for the same
reasons: determining at runtime whether an object with unknown properties
can be coerced into a given type. I'll post a more concrete example if I
can think of one.
The technique you posted is pretty nifty, I didn't think of that!
Ken
Michal Politowski wrote:
>
> On Tue, 24 Nov 2009 10:54:28 -0200, Daniel Sobral wrote:
>> How would they be written?
>
> isViewOf would have to be magical, I think.
> Any is magical anyway.
>
> def asViewOf[T](implicit view: this.type => T): T = view(this)
> seems to work in ref types.
>
> But when would these be handy?
>
>> On Tue, Nov 24, 2009 at 6:54 AM, Ken Scambler
>> wrote:
>>
>> >
>> > It seems very strange to me that there are no methods on the Any class
>> > corresponding to the <% type relationship, ie. def asViewOf[T]:T and
>> def
>> > isViewOf[T]:Boolean, in the same manner as the .isInstanceOf[T] and
>> > .asInstanceOf[T] methods.
>> >
>> > I've run into a few situations where it would have been handy -- does
>> > anyone
>> > else agree? It seems a glaring omission.
>> > --
>> > View this message in context:
>> >
>> http://old.nabble.com/.asViewOf-T-%2C-.isViewOf-T--for-%3C--relationship...
>> > Sent from the Scala - User mailing list archive at Nabble.com.
>
Re: .asViewOf[T], .isViewOf[T] for <% relationship
A <% B means there is an implicit A => B defined. So, .isViewOf[B] could really be defined as .isInstanceOf[? => B], which misses one type. That much, however, can be accomplished. After all, you could just write the correct isInstanceOf to begin with.
The problem, I think, is asViewOf. What does it mean? What does o.asViewOf[T] means? Does it mean to "magically" create a function of type o.type => T? Or does it mean to create a function T => o.type? If the compiler could create functions like that, one really wouldn't need to write programs.
Josh has created an "hasViewOf" and called it "isViewOf". Maybe that is what you want?
On Tue, Nov 24, 2009 at 10:01 PM, Ken Scambler <ken [dot] scambler [at] gmail [dot] com> wrote:
--
Daniel C. Sobral
Veni, vidi, veterni.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
My idea was that the <% relationship between types should be queriable at
runtime in the same way as the <: relationship -- this was based on the
mistaken assumption that an active set of implicit conversions is knowable
at a given point during runtime.
I thought an asViewOf() method might coerce the object to type with a known
implicit conversion, and throw some sort of ClassCastException if there was
no known conversion from the object's runtime type.
In light of this thread's discussion, I don't think either of my suggestions
make any sense. :)
The comments have been very educational, though.
Ken
Daniel Sobral wrote:
>
> Nothing can be entirely "magical". Even if one can't code it, one should
> be
> able to explain it.
>
> A <% B means there is an implicit A => B defined. So, .isViewOf[B] could
> really be defined as .isInstanceOf[? => B], which misses one type. That
> much, however, can be accomplished. After all, you could just write the
> correct isInstanceOf to begin with.
>
> The problem, I think, is asViewOf. What does it mean? What does
> o.asViewOf[T] means? Does it mean to "magically" create a function of type
> o.type => T? Or does it mean to create a function T => o.type? If the
> compiler could create functions like that, one really wouldn't need to
> write
> programs.
>
> Josh has created an "hasViewOf" and called it "isViewOf". Maybe that is
> what you want?
>
>
> On Tue, Nov 24, 2009 at 10:01 PM, Ken Scambler
> wrote:
>
>>
>> I would assume they would have to be magical, like
>> isInstanceOf/asInstanceOf.
>> I can't imagine they would get used very often (again, like the iIO/aIO
>> methods), but surely it's indispensable on rare occasions for the same
>> reasons: determining at runtime whether an object with unknown properties
>> can be coerced into a given type. I'll post a more concrete example if I
>> can think of one.
>>
>> The technique you posted is pretty nifty, I didn't think of that!
>> Ken
>>
>>
>>
>>
>> Michal Politowski wrote:
>> >
>> > On Tue, 24 Nov 2009 10:54:28 -0200, Daniel Sobral wrote:
>> >> How would they be written?
>> >
>> > isViewOf would have to be magical, I think.
>> > Any is magical anyway.
>> >
>> > def asViewOf[T](implicit view: this.type => T): T = view(this)
>> > seems to work in ref types.
>> >
>> > But when would these be handy?
>> >
>> >> On Tue, Nov 24, 2009 at 6:54 AM, Ken Scambler
>> >> wrote:
>> >>
>> >> >
>> >> > It seems very strange to me that there are no methods on the Any
>> class
>> >> > corresponding to the <% type relationship, ie. def asViewOf[T]:T and
>> >> def
>> >> > isViewOf[T]:Boolean, in the same manner as the .isInstanceOf[T] and
>> >> > .asInstanceOf[T] methods.
>> >> >
>> >> > I've run into a few situations where it would have been handy --
>> does
>> >> > anyone
>> >> > else agree? It seems a glaring omission.
>> >> > --
>> >> > View this message in context:
>> >> >
>> >>
>> http://old.nabble.com/.asViewOf-T-%2C-.isViewOf-T--for-%3C--relationship...
>> >> > Sent from the Scala - User mailing list archive at Nabble.com.
>> >
>> > --
>> > Michał Politowski
>> > Talking has been known to lead to communication if practiced
>> carelessly.
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/.asViewOf-T-%2C-.isViewOf-T--for-%3C--relationship...
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>>
>
>
Re: .asViewOf[T], .isViewOf[T] for <% relationship
I can imagine a compiler extension that captured a manifest of all implicit conversions available at a point in the program, and made this available at runtime as an implicit parameter, roughly as per the code below. With this, you could query if a conversion is available and execute it. Not sure of the use case at this point :)
There is some overlap with this thread [2] , and also an in-progress bug with TupleN.zippped [3].
-jason
[1] http://gist.github.com/242689
[2] http://thread.gmane.org/gmane.comp.lang.scala/18251/focus=18256
[3] https://lampsvn.epfl.ch/trac/scala/ticket/2673
class ImplicitScopeManifest[T] {
def findView[From](from: ClassManifest[From])(implicit to: Manifest[T]): Option[From => T] = {
// search list of implicits for matching function, as per Implicits.scala in the compiler.
None
}
}
// The compiler would capture a manifest of all implicit conversions in scope at the call site, including conversions provided by type T
def view[From <: AnyRef, T](a: From)(implicit to: Manifest[T], implicitScopeManifest: ImplicitScopeManifest[T]): Option[(From => T)] = {
val classManifest = scala.reflect.ClassManifest.fromClass[From](a.getClass().asInstanceOf[Class[From]])
implicitScopeManifest.findView[From](classManifest)
}
On Thu, Nov 26, 2009 at 12:04 AM, Ken Scambler <ken [dot] scambler [at] gmail [dot] com> wrote:
Re: .asViewOf[T], .isViewOf[T] for <% relationship
On Wed, Nov 25, 2009 at 9:02 PM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
Re: .asViewOf[T], .isViewOf[T] for <% relationship
As for the prioritized implicit technique, thank Paul Phillips who clued me into that for another issue I was having. It opens a whole new realm of possibilities from things I used to do with C++ parital-template-specialization. I'm curious if this could be combined with @inline to make generic algortihms efficient in specific corner cases...
- Josh
On Wed, Nov 25, 2009 at 6:12 AM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
Re: .asViewOf[T], .isViewOf[T] for <% relationship
On Wed, Nov 25, 2009 at 11:20 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
--
Daniel C. Sobral
Veni, vidi, veterni.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
Implicit views are applied at compile-time. There's generally no way to know at run-time whether an implicit view would have been in the compile-time scope or not.
--j
On Tue, Nov 24, 2009 at 4:01 PM, Ken Scambler <ken [dot] scambler [at] gmail [dot] com> wrote: