dynamic mixins

Kevin,

How about type-parameterized traits? Can you create reified method
definitions in place of the type-erased method definitions in the trait?

I would like to be able to define Foo like this:

trait Foo[T] {
def foometh(t: T) = ...
}

Then use two (or more) of them like this:

class Bar {
@With val fooA = new Foo[A]
@With val fooB = new Foo[B]
}

What I want as a result is this:
class Bar {
def foometh(t:A) = fooA.foometh(t)
def foometh(t:B) = fooB.foometh(t)
}

I can't do this with "class Bar with Foo[A] with Foo[B]" because
type erasure makes this look like inheriting from the same trait twice.

I can see that in some cases you might want to use the type-erased
method definitions, and in other reified definitions. Perhaps a
different annotation could indicate that preference.

The specific use case I have for the above request is to be able to
include my ListenerManager multiple times with different traits:
.

--
Jim

On Tue, Sep 15, 2009 at 11:28:34PM +0100, Kevin Wright wrote:
> Date: Tue, 15 Sep 2009 23:28:34 +0100
> From: Kevin Wright
> To: Scala list
> Subject: [scala] dynamic mixins
>
> I'm currently working on a compiler plugin to allow a form of dynamic
> mixins (applied to a pre-existing object instance instead of to a
> class)
>
> I think that I've come up with a clean and high-performance solution
> that can help with a few issues I've seen on this list recently.
>
> I'd like to take you on a brief tour and share some of my thinking, if
> I may...
>
> Please keep all extremities inside while the email is moving;Â I'm also
> looking for some feedback about how useful everyone thinks this might
> be, and any problems you anticipate with my approach.  Criticism is
> gratefully accepted, just so long as it leads to something better :)
>
> .
> .
> .
> The journey begins with just a single annotation. Â In line with
> existing notation for mixins, I've named this "@With". Â When used to
> annotate a val, or var, or inner object, or constructor parameter, this
> will cause all public members of the annotated value to be re-exposed
> as public members on the class containing the annotated value. Â It's
> easier to explain with an example:
> trait Foo {
> Â Â val fooval = "a string in foo"
> Â Â def foometh(p: String) = println("hello "+ p +"!")
> }
> class Bar {
> Â Â @With val foo = new Foo
> }
> ...this is expanded to:....
> class Bar {
> Â Â val foo = new Foo
> Â Â def fooval = foo.fooval
> Â Â def foometh(p: String) = foo.foometh(p)
> }
> Note that the accessor method for fooval must be delegated and not the
> underlying field, which is totally hidden anyway. Â This means that
> "val foometh" in Foo becomes "def foometh" in Bar, it isn't a typo
> @With can also be used in other places:
> Constructor parameters:
> Â Â class Bar(@With foo: Foo)
> Case class constructor parameters:
> Â Â case class Bar(@With foo: Foo)
> vars:
> Â Â class Bar { @With var foo : Foo = new Foo }
> methods:
> Â Â class Bar { @With def foo : Foo = ... }
> objects:
> Â Â class Bar { @With object foo extends Foo }
> The var and method variants are interesting, in both of these scenarios
> the underlying implementation of Foo can be changed between successive
> accesses; yet another good reason why vals are mixed-in as defs.
> Another nice feature is that the delegated methods can be restricted to
> just a subtype of the mixed-in object instance:
> trait RichFoo extends Foo {
> Â Â val richfooval = 42
> Â Â def richfoometh(p: String) = println("bye "+ p +"!")
> }
> class Bar {
> Â Â @With val myVal: Foo = new RichFoo
> }
> By explicitly specifying the type Foo for myVal, only methods from Foo
> will be mixed in, richfooval and richfoometh will NOT exist on the
> class Bar
> Also, a delegate method won't be generated if the class already
> contains a method with the same signature, this includes inherited
> methods
> ...and the best part? Â It's already implemented. Â I'm successfully
> generating these synthetic delegates and calling them and they behave
> exactly as expected.
> My only real outstanding problem is that these methods seem to be
> invisible from Scala, although I can quite happily import the class
> file into a Java project and it's all good.
> I'm seriously pushing to get this problem solved before the Scala
> incubator goes live, which is where I hope to publish it. Â In the
> meantime, I'll be dumping the source on GitHub any day now!
> Thanks for your time :)
> Planned enhancements:
> If it's possible - interfaces of mixed-in instances should also be
> re-exposed:
> val myVal : Foo = new Bar
> This works because the trait Foo is internally handled by the compiler
> as an interface Foo and a separate implementation class holding the
> concrete methods defined in Foo. Â So it should be possible to add
> Foo's interfaces (but not implementation) to Bar when they aren't
> already present.
> I also want to add special behaviour for getXXX and setXXX methods as
> generated by the @BeanProperty annotation. Â These shouldn't be
> delegated to the mixed-in instance, but should instead call the
> already-delegated Scala accessor methods.

Kevin,

How about type-parameterized traits?  Can you create reified method
definitions in place of the type-erased method definitions in the trait?

I would like to be able to define Foo like this:

trait Foo[T] {
   def foometh(t: T) = ...
}

Then use two (or more) of them like this:

class Bar {
   @With val fooA = new Foo[A]
   @With val fooB = new Foo[B]
}

What I want as a result is this:
class Bar {
   def foometh(t:A) = fooA.foometh(t)
   def foometh(t:B) = fooB.foometh(t)
}

I can't do this with "class Bar with Foo[A] with Foo[B]" because
type erasure makes this look like inheriting from the same trait twice.

I can see that in some cases you might want to use the type-erased
method definitions, and in other reified definitions.  Perhaps a
different annotation could indicate that preference.

The specific use case I have for the above request is to be able to
include my ListenerManager multiple times with different traits:
<http://jim-mcbeath.blogspot.com/2009/04/scala-listener-manager.html>.

--
Jim

> trait Foo {
> val fooval = "a string in foo"
> def foometh(p: String) = println("hello "+ p +"!")
> }
>
> class Bar {
> @With val foo = new Foo
> }
>
> ...this is expanded to:....
>
> class Bar {
> val foo = new Foo
> def fooval = foo.fooval
> def foometh(p: String) = foo.foometh(p)
> }

Looks pretty cool. Almost like something that could grow/morph into
compiler-generated delegates.

E.g. keep what you've got, but if you could optionally/also have Bar
extend Foo, you've made a type-safe delegate/proxy.

Good job; I'll look forward to reading the source for your plugin.

- Stephen

> trait Foo {
>   val fooval = "a string in foo"
>   def foometh(p: String) = println("hello "+ p +"!")
> }
>
> class Bar {
>   @With val foo = new Foo
> }
>
> ...this is expanded to:....
>
> class Bar {
>   val foo = new Foo
>   def fooval = foo.fooval
>   def foometh(p: String) = foo.foometh(p)
> }

Looks pretty cool. Almost like something that could grow/morph into
compiler-generated delegates.

E.g. keep what you've got, but if you could optionally/also have Bar
extend Foo, you've made a type-safe delegate/proxy.

Good job; I'll look forward to reading the source for your plugin.

- Stephen

On Wed, Sep 16, 2009 at 12:55 AM, Stephen Haberman <stephen [at] exigencecorp [dot] com> wrote:

> trait Foo {
>   val fooval = "a string in foo"
>   def foometh(p: String) = println("hello "+ p +"!")
> }
>
> class Bar {
>   @With val foo = new Foo
> }
>
> ...this is expanded to:....
>
> class Bar {
>   val foo = new Foo
>   def fooval = foo.fooval
>   def foometh(p: String) = foo.foometh(p)
> }

Looks pretty cool. Almost like something that could grow/morph into
compiler-generated delegates.

E.g. keep what you've got, but if you could optionally/also have Bar
extend Foo, you've made a type-safe delegate/proxy.

Good job; I'll look forward to reading the source for your plugin.

- Stephen

Top priority has absolutely got to be getting the scala signature working.  Without it, this is plugin is pretty much useless.
But after that, getting the "interface lift" (as I'm calling it) is definitely next on my todo list, this will allow constructs like foo.asInstanceOf[Bar], or passing a Foo to a parameter that expects a Bar.  Several of the design patterns I have in mind rely on having the delegates interfaces re-exposed in this manner.
As for reading the code, I'm going to have to polish it a little before I can take it out in public without shame :)

On Sep 16, 2009, at 9:28 AM, Viktor Klang wrote:
> I'd like something like:
>
> trait Foo
>
> object Baz
> {
> def booz[T](t : T) = t with Foo
> }

Besides Kevin's initial suggestions --- which I like very much (!) ---
I would also love to have this.

Cheers,
--
Normen Müller

On Sep 16, 2009, at 9:28 AM, Viktor Klang wrote:

I'd like something like:

trait Foo

object Baz
{
  def booz[T](t : T) = t with Foo
}

Besides Kevin's initial suggestions --- which I like very much (!) --- I would also love to have this.

Cheers,
--
Normen Müller

> I'd like to call them Bolt-ons, because it sounds cool and it's a tribute to
> the best singer the world has ever known (not to mention his awesome curly
> hair)

But also a tribute to the worst town the world has ever known.

Oh definitely! That was my first idea too. Use-site declaration really
does look more flexible the the definition-site approach that I've
taken.

Catch is that the meaning of 'with' then has to be overloaded, so a
lot more work is needed in the compiler. I'm already struggling with
the status of compiler plugins as second-class citzens and don't think
this notation could be handled without directly patching at least one
of the existing compiler phases (right now, I'm working in my very own
plugin-supplied phase)

I'm hoping I struck the right balance between dev time and
power/flexibility. Later today, I'll
try and post a list of some of the use cases I
considered, let you be the judge :)

On Wednesday, September 16, 2009, Viktor Klang wrote:
> I'd like something like:
>
> trait Foo
>
> object Baz
> {
>    def booz[T](t : T) = t with Foo
> }
>
> On Wed, Sep 16, 2009 at 2:23 AM, Kevin Wright wrote:
>
>
> On Wed, Sep 16, 2009 at 12:55 AM, Stephen Haberman wrote:
>
>
>> trait Foo {
>>   val fooval = "a string in foo"
>>   def foometh(p: String) = println("hello "+ p +"!")
>> }
>>
>> class Bar {
>>   @With val foo = new Foo
>> }
>>
>> ...this is expanded to:....
>>
>> class Bar {
>>   val foo = new Foo
>>   def fooval = foo.fooval
>>   def foometh(p: String) = foo.foometh(p)
>> }
>
> Looks pretty cool. Almost like something that could grow/morph into
> compiler-generated delegates.
>
> E.g. keep what you've got, but if you could optionally/also have Bar
> extend Foo, you've made a type-safe delegate/proxy.
>
> Good job; I'll look forward to reading the source for your plugin.
>
> - Stephen
>
>
> Top priority has absolutely got to be getting the scala signature working.  Without it, this is plugin is pretty much useless.
> But after that, getting the "interface lift" (as I'm calling it) is definitely next on my todo list, this will allow constructs like foo.asInstanceOf[Bar], or passing a Foo to a parameter that expects a Bar.  Several of the design patterns I have in mind rely on having the delegates interfaces re-exposed in this manner.
>
>
> As for reading the code, I'm going to have to polish it a little before I can take it out in public without shame :)
>
>
>
> --
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder: http://groups.google.com/group/softpub
>

Viktor Klang wrote:
>
> I'd like something like:
>
> trait Foo
>
> object Baz
> {
> def booz[T](t : T) = t with Foo
> }
>

I was thinking about something along those lines the other week. It takes
you about a third of the way to covering the use cases of aspect-oriented
programming, while retaining strong typing and avoiding explicit reflection.
The syntax I was thinking of was "proxy t with Foo" instead, making it clear
that you're creating a new, extended delegate object, rather than somehow
mutating t.

--Dave Griffith

Viktor Klang wrote:
>
> I'd like something like:
>
> trait Foo
>
> object Baz
> {
>    def booz[T](t : T) = t with Foo
> }
>

I was thinking about something along those lines the other week.  It takes
you about a third of the way to covering the use cases of aspect-oriented
programming, while retaining strong typing and avoiding explicit reflection.
The syntax I was thinking of was "proxy t with Foo" instead, making it clear
that you're creating a new, extended delegate object, rather than somehow
mutating t.

--Dave Griffith
--
View this message in context: http://www.nabble.com/-scala--dynamic-mixins-tp25462933p25469732.html
Sent from the Scala mailing list archive at Nabble.com.

In this case, there is still the requirement that Foo must be aware of
t in order to proxy it, so some way will still be required to handle
the injection of t -> Foo

I guess the real advantage of this approach is that you make it very
clear what's happening at the use site. Perhaps I can do something
with factory methods to duplicate that functionality

On Wednesday, September 16, 2009, Dave Griffith
wrote:
>
>
>
> Viktor Klang wrote:
>>
>> I'd like something like:
>>
>> trait Foo
>>
>> object Baz
>> {
>>    def booz[T](t : T) = t with Foo
>> }
>>
>
> I was thinking about something along those lines the other week.  It takes
> you about a third of the way to covering the use cases of aspect-oriented
> programming, while retaining strong typing and avoiding explicit reflection.
> The syntax I was thinking of was "proxy t with Foo" instead, making it clear
> that you're creating a new, extended delegate object, rather than somehow
> mutating t.
>
> --Dave Griffith
> --
> View this message in context: http://www.nabble.com/-scala--dynamic-mixins-tp25462933p25469732.html
> Sent from the Scala mailing list archive at Nabble.com.
>
>

Kevin Wright-4 wrote:
>
> In this case, there is still the requirement that Foo must be aware of
> t in order to proxy it, so some way will still be required to handle
> the injection of t -> Foo
>

Much of this is handled just with a self-type, but I'm not sure if that
covers all of what's necessary.

--Dave Griffith

On Wed, Sep 16, 2009 at 12:29 PM, Dave Griffith <dave [dot] l [dot] griffith [at] gmail [dot] com> wrote:

Viktor Klang wrote:
>
> I'd like something like:
>
> trait Foo
>
> object Baz
> {
>    def booz[T](t : T) = t with Foo
> }
>

I was thinking about something along those lines the other week.  It takes
you about a third of the way to covering the use cases of aspect-oriented
programming, while retaining strong typing and avoiding explicit reflection.
The syntax I was thinking of was "proxy t with Foo" instead, making it clear
that you're creating a new, extended delegate object, rather than somehow
mutating t.

how about:

new t with Foo
 

--Dave Griffith
--
View this message in context: http://www.nabble.com/-scala--dynamic-mixins-tp25462933p25469732.html
Sent from the Scala mailing list archive at Nabble.com.

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

Kevin Wright-4 wrote:
>
> In this case, there is still the requirement that Foo must be aware of
> t in order to proxy it, so some way will still be required to handle
> the injection of t -> Foo
>

Much of this is handled just with a self-type, but I'm not sure if that
covers all of what's necessary.

--Dave Griffith


--
View this message in context: http://www.nabble.com/-scala--dynamic-mixins-tp25462933p25470572.html
Sent from the Scala mailing list archive at Nabble.com.

It isn't quite there.  What we have is self-type, but what we need is self-instance

On Wed, Sep 16, 2009 at 12:37 PM, Dave Griffith <dave [dot] l [dot] griffith [at] gmail [dot] com> wrote:

Kevin Wright-4 wrote:
>
> In this case, there is still the requirement that Foo must be aware of
> t in order to proxy it, so some way will still be required to handle
> the injection of t -> Foo
>

Much of this is handled just with a self-type, but I'm not sure if that
covers all of what's necessary.

--Dave Griffith


--
View this message in context: http://www.nabble.com/-scala--dynamic-mixins-tp25462933p25470572.html
Sent from the Scala mailing list archive at Nabble.com.