Self type constructors (OOPSLA 2009 paper)

This is where I mention my virtual constructor Sip and the difficulty with generating methods from a plug-in. And then Kevin will show there is some hope but its not a solved problem.

On May 26, 2010 8:17 PM, "Alex Cruise" <alex@cluonflux.com> wrote:

Any comments on this paper from OOPSLA 2009 on self type constructors?  (Not the same as Scala's self-type annotations/aliases)

Sometimes it would be nice to declare that a method returns "a this, where this is the concrete type" without mentioning the abstract type.  In Scala we have this.type, but it's too specific, and there's also  self-bounded generics, but that's just too nasty.  ;)

ACM URL is http://portal.acm.org/beta/citation.cfm?id=1640109 , full text is http://www.sato.kuis.kyoto-u.ac.jp/~igarashi/papers/pdf/stc-OOPSLA09.pdf

Here's a snippet from the paper to whet your appetite: http://paste.pocoo.org/show/218600/

-0xe1a

On Wed, May 26, 2010 at 8:36 PM, Chris Twiner <chris.twiner@gmail.com> wrote:

Any comments on this paper from OOPSLA 2009 on self type constructors?  (Not the same as Scala's self-type annotations/aliases)

Sometimes it would be nice to declare that a method returns "a this, where this is the concrete type" without mentioning the abstract type.  In Scala we have this.type, but it's too specific, and there's also  self-bounded generics, but that's just too nasty.  

I'm not a fan: 

• as it stands, the self type would slavishly follow the class hierarchy, thus exposing implementation subclasses -- with abstract members it's your call when to "tie the knot"
• the self type is necessarily covariant, so that you need to jump through very tight, radioactive & flaming hoops to use it in interesting places (if you interpret it as an abstract type member whose bound varies covariantly, this is mitigated at the expense of precision; another way out would be to also introduce precise types so you know when it's safe to use a covariant type in a non-covariant position, much like our current private[this] escape hatch)
• there's definitely a third disadvantage, but I can't think of it -- anyone else care to pitch in? this discussion comes up once and a while at lunch, and we always seem to conclude it's too much hassle for too little gain

cheersadriaan

Maybe, just maybe, in theory.  But it's a tough one.
Not could this far exceed specialisation in terms of complexity, but it also completely changes many semantics of the language and cuts deep into the type system.  Not sure how hopeful I feel about using a plugin.

For now you're better off with factory methods (such as apply defined on a companion object) or the Builder approach as used by 2.8 collections.  In the future we may have virtual classes too, that should be fun!


On 26 May 2010 19:36, Chris Twiner <chris.twiner@gmail.com> wrote:

This is where I mention my virtual constructor Sip and the difficulty with generating methods from a plug-in. And then Kevin will show there is some hope but its not a solved problem.

On May 26, 2010 8:17 PM, "Alex Cruise" <alex@cluonflux.com> wrote:

Any comments on this paper from OOPSLA 2009 on self type constructors?  (Not the same as Scala's self-type annotations/aliases)

Sometimes it would be nice to declare that a method returns "a this, where this is the concrete type" without mentioning the abstract type.  In Scala we have this.type, but it's too specific, and there's also  self-bounded generics, but that's just too nasty.  ;)

ACM URL is http://portal.acm.org/beta/citation.cfm?id=1640109 , full text is http://www.sato.kuis.kyoto-u.ac.jp/~igarashi/papers/pdf/stc-OOPSLA09.pdf

Here's a snippet from the paper to whet your appetite: http://paste.pocoo.org/show/218600/

-0xe1a

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

In the proposal I made, and the code its based on, I use abstract type members not adjusting the self type.

The only actual problem with that approach is default parameters, as derived classes / traits cannot expand the virtual constructors parameter list and retain the same 'new this' member name.

The fully typed result is worth the boiler plate however. It would just be nice to do the heavy lifting elsewhere.

On May 26, 2010 8:54 PM, "Adriaan Moors" <adriaan.moors@epfl.ch> wrote:

On Wed, May 26, 2010 at 8:36 PM, Chris Twiner <chris.twiner@gmail.com> wrote: >> >> Any comments on ...

I'm not a fan: 

• as it stands, the self type would slavishly follow the class hierarchy, thus exposing implementation subclasses -- with abstract members it's your call when to "tie the knot"
• the self type is necessarily covariant, so that you need to jump through very tight, radioactive & flaming hoops to use it in interesting places (if you interpret it as an abstract type member whose bound varies covariantly, this is mitigated at the expense of precision; another way out would be to also introduce precise types so you know when it's safe to use a covariant type in a non-covariant position, much like our current private[this] escape hatch)
• there's definitely a third disadvantage, but I can't think of it -- anyone else care to pitch in? this discussion comes up once and a while at lunch, and we always seem to conclude it's too much hassle for too little gain

cheersadriaan