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

A question about self types

9 replies
Aydjen
Joined: 2009-08-21,
User offline. Last seen 1 year 28 weeks ago.

Hello,

intuitively, I would expect line 4 (cat.identify) of the following program to compile. After all, a "Sleeping" must always be a "Cat", as guaranteed by its self type. Is there anything I am missing or are they just not supposed to work that way?

Thanks for advice :)
Andreas
--

object Main {
def main(args: Array[String]): Unit = {
val cat = Cat.discover
println(cat.identify)
}
}

abstract class Cat {
def identify = "a cat"
def activity: String
}
object Cat {
def discover: Sleeping = new Cat with Sleeping
}

trait Sleeping { this: Cat =>
def describe = identify + ", sleeping, dreaming of food"

def wake: Eating = new Cat with Eating
}

trait Eating { this: Cat =>
def describe = identify + ", eating food"
}

bmaso
Joined: 2009-10-04,
User offline. Last seen 2 years 40 weeks ago.
Re: A question about self types

I think a similar thread went by a few weeks ago -- maybe a couple
months ago. The answer (IIRC) is that self types merely restrict what
classes the trait may be mixed-in to; applicatio of a self type does
not modify the static type of the "this" variable

So event though the trait is guaranteed to be mixed-in to a Cat, it
doesn't mean the Sleeping trait is able to statically assume "this" is
a Cat reference.

Best regards,
Brian Maso
(949) 395-8551
brian [at] blumenfeld-maso [dot] com
twitter: @bmaso
skype: brian.maso
LinkedIn: http://www.linkedin.com/in/brianmaso

On Fri, Mar 12, 2010 at 4:10 PM, Andreas Flierl wrote:
> Hello,
>
> intuitively, I would expect line 4 (cat.identify) of the following program to compile. After all, a "Sleeping" must always be a "Cat", as guaranteed by its self type. Is there anything I am missing or are they just not supposed to work that way?
>
> Thanks for advice :)
> Andreas
> --
>
> object Main {
>  def main(args: Array[String]): Unit = {
>    val cat = Cat.discover
>    println(cat.identify)
>  }
> }
>
> abstract class Cat {
>  def identify = "a cat"
>  def activity: String
> }
> object Cat {
>  def discover: Sleeping = new Cat with Sleeping
> }
>
> trait Sleeping { this: Cat =>
>  def describe = identify + ", sleeping, dreaming of food"
>
>  def wake: Eating = new Cat with Eating
> }
>
> trait Eating { this: Cat =>
>  def describe = identify + ", eating food"
> }

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: A question about self types
That this is not possible is one of the main differences between inheritance and self-types.

On Fri, Mar 12, 2010 at 9:10 PM, Andreas Flierl <andreas [at] flierl [dot] eu> wrote:
Hello,

intuitively, I would expect line 4 (cat.identify) of the following program to compile. After all, a "Sleeping" must always be a "Cat", as guaranteed by its self type. Is there anything I am missing or are they just not supposed to work that way?

Thanks for advice :)
Andreas
--

object Main {
 def main(args: Array[String]): Unit = {
   val cat = Cat.discover
   println(cat.identify)
 }
}

abstract class Cat {
 def identify = "a cat"
 def activity: String
}
object Cat {
 def discover: Sleeping = new Cat with Sleeping
}

trait Sleeping { this: Cat =>
 def describe = identify + ", sleeping, dreaming of food"

 def wake: Eating = new Cat with Eating
}

trait Eating { this: Cat =>
 def describe = identify + ", eating food"
}



--
Daniel C. Sobral

I travel to the future all the time.
Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: A question about self types

On Friday March 12 2010, Daniel Sobral wrote:
> That this is not possible is one of the main differences between
> inheritance and self-types.

That makes me wonder: Is it reasonable to think of it like private
inheritance (of the C++ variety)?

Randall Schulz

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: A question about self types
One can't override methods in it. There's some discussion of making that possible, which would really bring it closer.
I, myself, consider it private inheritance when it fits.

On Fri, Mar 12, 2010 at 9:53 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Friday March 12 2010, Daniel Sobral wrote:
> That this is not possible is one of the main differences between
> inheritance and self-types.

That makes me wonder: Is it reasonable to think of it like private
inheritance (of the C++ variety)?


Randall Schulz



--
Daniel C. Sobral

I travel to the future all the time.
Donna Malayeri
Joined: 2009-10-21,
User offline. Last seen 42 years 45 weeks ago.
Re: A question about self types
You can override methods now, but super calls don't yet work. (I haven't yet updated the spec to reflect the override thing.)

As part of my not-yet-concrete ideas on how to get trait constructors working, I would like to extend self-types to optionally provide subtyping. I'm still working out the best way to do this, however.

At any rate, I think that comparing to C++ private inheritance is a mistake. Private inheritance is needed *only* when you need to override protected virtual methods; in all other cases, object containment is preferred (this is according to Scott Meyers' Effective C++ series). Private inheritance is, IMO, a very strange beast that few people understand. It's also completely unnecessary--you can achieve the same thing with delegation and a private nested class.

Donna


On Sat, Mar 13, 2010 at 2:28 AM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
One can't override methods in it. There's some discussion of making that possible, which would really bring it closer.
I, myself, consider it private inheritance when it fits.

On Fri, Mar 12, 2010 at 9:53 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Friday March 12 2010, Daniel Sobral wrote:
> That this is not possible is one of the main differences between
> inheritance and self-types.

That makes me wonder: Is it reasonable to think of it like private
inheritance (of the C++ variety)?


Randall Schulz



--
Daniel C. Sobral

I travel to the future all the time.

David Hall 4
Joined: 2009-08-21,
User offline. Last seen 42 years 45 weeks ago.
Re: A question about self types

On Sat, Mar 13, 2010 at 10:56 AM, Donna Malayeri wrote:
>
> At any rate, I think that comparing to C++ private inheritance is a mistake.
> Private inheritance is needed *only* when you need to override protected
> virtual methods; in all other cases, object containment is preferred (this
> is according to Scott Meyers' Effective C++ series). Private inheritance is,
> IMO, a very strange beast that few people understand. It's also completely
> unnecessary--you can achieve the same thing with delegation and a private
> nested class.

It's sometimes useful for looping in a c++ metaprogramming context,
but of course that depends on template metaprogramming being useful...

Donna Malayeri
Joined: 2009-10-21,
User offline. Last seen 42 years 45 weeks ago.
Re: A question about self types

> At any rate, I think that comparing to C++ private inheritance is a mistake.
> Private inheritance is needed *only* when you need to override protected
> virtual methods; in all other cases, object containment is preferred (this
> is according to Scott Meyers' Effective C++ series). Private inheritance is,
> IMO, a very strange beast that few people understand. It's also completely
> unnecessary--you can achieve the same thing with delegation and a private
> nested class.

It's sometimes useful for looping in a c++ metaprogramming context,
but of course that depends on template metaprogramming being useful...


Oh dear, I forgot that everything one says about C++ is modulo template metaprogramming. I just pretend that doesn't exist because it is so incomprehensible to me. 
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: A question about self types
Interesting, I didn't notice this going in. I think there was an enhancement ticket open, wasn't there?

On Sat, Mar 13, 2010 at 3:56 PM, Donna Malayeri <lindydonna [at] gmail [dot] com> wrote:
You can override methods now, but super calls don't yet work. (I haven't yet updated the spec to reflect the override thing.)

As part of my not-yet-concrete ideas on how to get trait constructors working, I would like to extend self-types to optionally provide subtyping. I'm still working out the best way to do this, however.

At any rate, I think that comparing to C++ private inheritance is a mistake. Private inheritance is needed *only* when you need to override protected virtual methods; in all other cases, object containment is preferred (this is according to Scott Meyers' Effective C++ series). Private inheritance is, IMO, a very strange beast that few people understand. It's also completely unnecessary--you can achieve the same thing with delegation and a private nested class.

Donna


On Sat, Mar 13, 2010 at 2:28 AM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
One can't override methods in it. There's some discussion of making that possible, which would really bring it closer.
I, myself, consider it private inheritance when it fits.

On Fri, Mar 12, 2010 at 9:53 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Friday March 12 2010, Daniel Sobral wrote:
> That this is not possible is one of the main differences between
> inheritance and self-types.

That makes me wonder: Is it reasonable to think of it like private
inheritance (of the C++ variety)?


Randall Schulz



--
Daniel C. Sobral

I travel to the future all the time.




--
Daniel C. Sobral

I travel to the future all the time.
Donna Malayeri
Joined: 2009-10-21,
User offline. Last seen 42 years 45 weeks ago.
Re: A question about self types
I found this one: https://lampsvn.epfl.ch/trac/scala/ticket/2808, but then I realized that I never closed https://lampsvn.epfl.ch/trac/scala/ticket/2412 (which is an enhancement). Now that I think about it, I was probably keeping it open so that I would remember to update the spec.

Donna

On Sat, Mar 13, 2010 at 11:16 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
Interesting, I didn't notice this going in. I think there was an enhancement ticket open, wasn't there?

On Sat, Mar 13, 2010 at 3:56 PM, Donna Malayeri <lindydonna [at] gmail [dot] com> wrote:
You can override methods now, but super calls don't yet work. (I haven't yet updated the spec to reflect the override thing.)

As part of my not-yet-concrete ideas on how to get trait constructors working, I would like to extend self-types to optionally provide subtyping. I'm still working out the best way to do this, however.

At any rate, I think that comparing to C++ private inheritance is a mistake. Private inheritance is needed *only* when you need to override protected virtual methods; in all other cases, object containment is preferred (this is according to Scott Meyers' Effective C++ series). Private inheritance is, IMO, a very strange beast that few people understand. It's also completely unnecessary--you can achieve the same thing with delegation and a private nested class.

Donna


On Sat, Mar 13, 2010 at 2:28 AM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
One can't override methods in it. There's some discussion of making that possible, which would really bring it closer.
I, myself, consider it private inheritance when it fits.

On Fri, Mar 12, 2010 at 9:53 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Friday March 12 2010, Daniel Sobral wrote:
> That this is not possible is one of the main differences between
> inheritance and self-types.

That makes me wonder: Is it reasonable to think of it like private
inheritance (of the C++ variety)?


Randall Schulz



--
Daniel C. Sobral

I travel to the future all the time.




--
Daniel C. Sobral

I travel to the future all the time.

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