This page is no longer maintained — Please continue to the home page at www.scala-lang.org

.asViewOf[T], .isViewOf[T] for <% relationship

14 replies
Ken Scambler
Joined: 2009-11-07,
User offline. Last seen 42 years 45 weeks ago.

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.

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
How would they be written?

On Tue, Nov 24, 2009 at 6:54 AM, Ken Scambler <ken [dot] scambler [at] gmail [dot] com> 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-tp26492479p26492479.html
Sent from the Scala - User mailing list archive at Nabble.com.




--
Daniel C. Sobral

Veni, vidi, veterni.
Michal Politowski 2
Joined: 2009-09-15,
User offline. Last seen 42 years 45 weeks ago.
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.

Ken Scambler
Joined: 2009-11-07,
User offline. Last seen 42 years 45 weeks ago.
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.
>

Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
isInstanceOf and asInstanceOf are run-time checks on the class of the object.

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:

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
>> <ken [dot] scambler [at] gmail [dot] com>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-tp26492479p26492479.html
>> > 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-tp26492479p26505453.html
Sent from the Scala - User mailing list archive at Nabble.com.


Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
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 <mpol [at] charybda [dot] icm [dot] edu [dot] pl>
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 <ken [dot] scambler [at] gmail [dot] com>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-tp26492479p26492479.html
> > Sent from the Scala - User mailing list archive at Nabble.com.

--
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
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.
>>
>

Ken Scambler
Joined: 2009-11-07,
User offline. Last seen 42 years 45 weeks ago.
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.
>>>
>>
>

Michal Politowski 2
Joined: 2009-09-15,
User offline. Last seen 42 years 45 weeks ago.
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

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
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 <ken [dot] scambler [at] gmail [dot] com> 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
>> <ken [dot] scambler [at] gmail [dot] com>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-tp26492479p26492479.html
>> > 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-tp26492479p26505453.html
Sent from the Scala - User mailing list archive at Nabble.com.




--
Daniel C. Sobral

Veni, vidi, veterni.
Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
Yes... I was thinking it should be called "hasViewOf" and "toViewOf" or some such.   Also, this is completely dependent on static types (as implicits are). It's just a little compiler meta-programming mixed with a silly runtime check.   Ideally if something like this was useful, you wouldn't be resorting to implicit magic, but hey... It was fun to try!

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:
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 <ken [dot] scambler [at] gmail [dot] com> 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
>> <ken [dot] scambler [at] gmail [dot] com>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-tp26492479p26492479.html
>> > 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-tp26492479p26505453.html
Sent from the Scala - User mailing list archive at Nabble.com.




--
Daniel C. Sobral

Veni, vidi, veterni.

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
Yeah. So, it begs the question of whether that is what was intended or not.

On Wed, Nov 25, 2009 at 11:20 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Yes... I was thinking it should be called "hasViewOf" and "toViewOf" or some such.   Also, this is completely dependent on static types (as implicits are). It's just a little compiler meta-programming mixed with a silly runtime check.   Ideally if something like this was useful, you wouldn't be resorting to implicit magic, but hey... It was fun to try!

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:
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 <ken [dot] scambler [at] gmail [dot] com> 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
>> <ken [dot] scambler [at] gmail [dot] com>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-tp26492479p26492479.html
>> > 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-tp26492479p26505453.html
Sent from the Scala - User mailing list archive at Nabble.com.




--
Daniel C. Sobral

Veni, vidi, veterni.




--
Daniel C. Sobral

Veni, vidi, veterni.
Ken Scambler
Joined: 2009-11-07,
User offline. Last seen 42 years 45 weeks ago.
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.
>>
>>
>
>

Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
For fun, I've expanded [1] Josh's technique to work for testing type equivalence, conformance, and view-ability.

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:

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
> <ken [dot] scambler [at] gmail [dot] com>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
>> >> <ken [dot] scambler [at] gmail [dot] com>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-tp26492479p26492479.html
>> >> > 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-tp26492479p26505453.html
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.
>
>

--
View this message in context: http://old.nabble.com/.asViewOf-T-%2C-.isViewOf-T--for-%3C--relationship-tp26492479p26513172.html
Sent from the Scala - User mailing list archive at Nabble.com.


Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: .asViewOf[T], .isViewOf[T] for <% relationship
Very nice!

On Wed, Nov 25, 2009 at 9:02 PM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
For fun, I've expanded [1] Josh's technique to work for testing type equivalence, conformance, and view-ability.

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:

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
> <ken [dot] scambler [at] gmail [dot] com>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
>> >> <ken [dot] scambler [at] gmail [dot] com>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-tp26492479p26492479.html
>> >> > 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-tp26492479p26505453.html
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.
>
>

--
View this message in context: http://old.nabble.com/.asViewOf-T-%2C-.isViewOf-T--for-%3C--relationship-tp26492479p26513172.html
Sent from the Scala - User mailing list archive at Nabble.com.



Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland