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

feature request

3 replies
H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.

hi there,

there's something i'd love to see in scala. it's basically just a bit of
syntactic sugar.
imagine you have a big application which is managing... persons.

you begin with "database.query[Person](5)" which gets you the person by
its sysId.
for your special usecase, you also need its car, which has a lazy
accessor implemented as a trait:

trait CarOfPerson extends Person {
lazy val car = database.query[Car](carId) // carId is stored in Person
}

now imagine there are 20 more traits, but you don't want to create a
huge person class which has everything and you want to avoid to create a
huge class with one method for each possible combination of traits that
is used in the application.

instead, i'd prefer to do something like this:
val personWithNewTrait = proxyOf database.query[Person](5) with CarOfPerson

what i do NOT want is to dynamically attach methods to an existing
instance. to preserve type safety, the expression above could desugar to:

val personWithNewTrait = new ProxyPerson(database.query[Person](5)) with
CarOfPerson

class ProxyPerson(org:Person) extends Person {
//every public method call overridden, the calls are all delegated
to the original person instance
}

as you see, it can all be done without adding new features, cglib or
messing up anything, it's pretty much like groovys @delegate
you could dynamically attach more and more traits on top of the person
instance you already have depending on your needs.

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: feature request


On 10 Feb 2011 20:14, "HamsterofDeath" <h-star [at] gmx [dot] de> wrote:
>
> hi there,
>
> there's something i'd love to see in scala. it's basically just a bit of
> syntactic sugar.
> imagine you have a big application which is managing... persons.
>
> you begin with "database.query[Person](5)" which gets you the person by
> its sysId.
> for your special usecase, you also need its car, which has a lazy
> accessor implemented as a trait:
>
> trait CarOfPerson extends Person {
>   lazy val car = database.query[Car](carId) // carId is stored in Person
> }
>
> now imagine there are 20 more traits, but you don't want to create a
> huge person class which has everything and you want to avoid to create a
> huge class with one method for each possible combination of traits that
> is used in the application.
>
> instead, i'd prefer to do something like this:
> val personWithNewTrait = proxyOf database.query[Person](5) with CarOfPerson
>
> what i do NOT want is to dynamically attach methods to an existing
> instance. to preserve type safety, the expression above could desugar to:
>
> val personWithNewTrait = new ProxyPerson(database.query[Person](5)) with
> CarOfPerson
>
> class ProxyPerson(org:Person) extends Person {
>      //every public method call overridden, the calls are all delegated
> to the original person instance
> }
>
> as you see, it can all be done without adding new features, cglib or
> messing up anything, it's pretty much like groovys @delegate
> you could dynamically attach more and more traits on top of the person
> instance you already have depending on your needs.
>
>

It has come up once or twice in the past, under various names.

http://www.artima.com/weblogs/viewpost.jsp?thread=275135

Also worth pointing out here that you can get 90% of that functionality with the correct use of implicit conversions...

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: feature request
the project seems to be abandoned. does it work?

Am 10.02.2011 22:24, schrieb Kevin Wright:
XHe6wp [at] mail [dot] gmail [dot] com" type="cite">


On 10 Feb 2011 20:14, "HamsterofDeath" <h-star [at] gmx [dot] de" rel="nofollow">h-star [at] gmx [dot] de> wrote:
>
> hi there,
>
> there's something i'd love to see in scala. it's basically just a bit of
> syntactic sugar.
> imagine you have a big application which is managing... persons.
>
> you begin with "database.query[Person](5)" which gets you the person by
> its sysId.
> for your special usecase, you also need its car, which has a lazy
> accessor implemented as a trait:
>
> trait CarOfPerson extends Person {
>   lazy val car = database.query[Car](carId) // carId is stored in Person
> }
>
> now imagine there are 20 more traits, but you don't want to create a
> huge person class which has everything and you want to avoid to create a
> huge class with one method for each possible combination of traits that
> is used in the application.
>
> instead, i'd prefer to do something like this:
> val personWithNewTrait = proxyOf database.query[Person](5) with CarOfPerson
>
> what i do NOT want is to dynamically attach methods to an existing
> instance. to preserve type safety, the expression above could desugar to:
>
> val personWithNewTrait = new ProxyPerson(database.query[Person](5)) with
> CarOfPerson
>
> class ProxyPerson(org:Person) extends Person {
>      //every public method call overridden, the calls are all delegated
> to the original person instance
> }
>
> as you see, it can all be done without adding new features, cglib or
> messing up anything, it's pretty much like groovys @delegate
> you could dynamically attach more and more traits on top of the person
> instance you already have depending on your needs.
>
>

It has come up once or twice in the past, under various names.

http://www.artima.com/weblogs/viewpost.jsp?thread=275135

Also worth pointing out here that you can get 90% of that functionality with the correct use of implicit conversions...


Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: feature request


On 10 Feb 2011 21:43, "HamsterofDeath" <h-star [at] gmx [dot] de> wrote:
>
> the project seems to be abandoned. does it work?
>

I've got a "lite" version coming soon that limits delegates to be traits-only.  I'm also keeping a very close eye on presentation compiler work for 2.9, which looks to contain many of the missing pieces needed to make post-typer method synthesis behave sanely.

> Am 10.02.2011 22:24, schrieb Kevin Wright:
>>
>>
>> On 10 Feb 2011 20:14, "HamsterofDeath" <h-star [at] gmx [dot] de> wrote:
>> >
>> > hi there,
>> >
>> > there's something i'd love to see in scala. it's basically just a bit of
>> > syntactic sugar.
>> > imagine you have a big application which is managing... persons.
>> >
>> > you begin with "database.query[Person](5)" which gets you the person by
>> > its sysId.
>> > for your special usecase, you also need its car, which has a lazy
>> > accessor implemented as a trait:
>> >
>> > trait CarOfPerson extends Person {
>> >   lazy val car = database.query[Car](carId) // carId is stored in Person
>> > }
>> >
>> > now imagine there are 20 more traits, but you don't want to create a
>> > huge person class which has everything and you want to avoid to create a
>> > huge class with one method for each possible combination of traits that
>> > is used in the application.
>> >
>> > instead, i'd prefer to do something like this:
>> > val personWithNewTrait = proxyOf database.query[Person](5) with CarOfPerson
>> >
>> > what i do NOT want is to dynamically attach methods to an existing
>> > instance. to preserve type safety, the expression above could desugar to:
>> >
>> > val personWithNewTrait = new ProxyPerson(database.query[Person](5)) with
>> > CarOfPerson
>> >
>> > class ProxyPerson(org:Person) extends Person {
>> >      //every public method call overridden, the calls are all delegated
>> > to the original person instance
>> > }
>> >
>> > as you see, it can all be done without adding new features, cglib or
>> > messing up anything, it's pretty much like groovys @delegate
>> > you could dynamically attach more and more traits on top of the person
>> > instance you already have depending on your needs.
>> >
>> >
>>
>> It has come up once or twice in the past, under various names.
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=275135
>>
>> Also worth pointing out here that you can get 90% of that functionality with the correct use of implicit conversions...
>
>

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