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@blumenfeld-maso.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"
> }

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@flierl.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.

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

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@sonic.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.

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@gmail.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@sonic.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.

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...

> 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. 

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@gmail.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@gmail.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@sonic.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.

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@gmail.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@gmail.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@gmail.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@sonic.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.