- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Explicit Pimping / Dynamic Mixins
Sun, 2011-07-10, 19:36
Looking for a CS grad, under-grad or otherwise
capable individual willing to implement
Explicit Pimping / Dynamic Mixins in Scala.
See: https://issues.scala-lang.org/browse/SUGGEST-3
Ultimately, you'd have to end up working with the
Scala Folks to extend the language spec and augment
the compiler. Initially, a prototype extension to
the compiler would have to be created as well as
technical documentation indicating that the idea
is fully baked (at the current time it is rather raw).
As an added incentive, the implementer would get to
name the new language feature and become part of
the Scala language lore.
Regards
Richard Emberson
Sun, 2011-07-10, 21:07
#2
Re: Explicit Pimping / Dynamic Mixins
Oops indeed.
I had looked at autoproxy-lite (a while ago) and scala-roles (having
worked on a Scala RBAC library).
Do not want any additional runtime memory or performance impact.
As I said in the suggestion, I'd like to have no memory usage impact.
I believe that proxies add a level of indirection - an increased
memory usage. What I suggest avoid that.
In addition, some implicits have some, though very small, runtime
performance impact (which, at least for me, is less important).
Again, what I suggest avoid that.
I am not saying that what I've very briefly outlined is possible
nor did I imply that, as an idea, it was fully flushed out.
But, I bet if this was a language feature, new-comers to Scala would
use it much more than implicits, have far fewer questions
concerning its use (as oppose to implicits) and could also understand
code using it much easier than implicits (have to figure out which
implicit is being used and where its located, etc, hence I
referred to them as explicits).
Thanks
Richard
On 07/10/2011 11:45 AM, Kevin Wright wrote:
> Oops!
>
> http://www.scala-lang.org/node/9111
> https://github.com/kevinwright/Autoproxy-Lite
> http://mp.binaervarianz.de/scala_roles_diploma_thesis_slides.pdf
>
>
>
> On 10 July 2011 19:36, richard emberson > wrote:
>
> Looking for a CS grad, under-grad or otherwise
> capable individual willing to implement
> Explicit Pimping / Dynamic Mixins in Scala.
>
> See: https://issues.scala-lang.org/__browse/SUGGEST-3
>
>
> Ultimately, you'd have to end up working with the
> Scala Folks to extend the language spec and augment
> the compiler. Initially, a prototype extension to
> the compiler would have to be created as well as
> technical documentation indicating that the idea
> is fully baked (at the current time it is rather raw).
>
> As an added incentive, the implementer would get to
> name the new language feature and become part of
> the Scala language lore.
>
> Regards
>
> Richard Emberson
> --
> Quis custodiet ipsos custodes
>
>
>
>
> --
> Kevin Wright
>
> gtalk / msn : kev.lee.wright@gmail.com
> google+: http://gplus.to/thecoda
> mail: kevin.wright@scalatechnology.com
>
> vibe / skype: kev.lee.wright
> quora: http://www.quora.com/Kevin-Wright
> twitter: @thecoda
>
> "My point today is that, if we wish to count lines of code, we should
> not regard them as "lines produced" but as "lines spent": the current
> conventional wisdom is so foolish as to book that count on the wrong
> side of the ledger" ~ Dijkstra
>
Sun, 2011-07-10, 21:57
#3
Re: Explicit Pimping / Dynamic Mixins
On Sun, Jul 10, 2011 at 9:57 PM, richard emberson <richard.emberson@gmail.com> wrote:
Oops indeed.
I had looked at autoproxy-lite (a while ago) and scala-roles (having
worked on a Scala RBAC library).
Do not want any additional runtime memory or performance impact.
Could you explain how you think you can have runtime behavior without runtime cost?
As I said in the suggestion, I'd like to have no memory usage impact.
I believe that proxies add a level of indirection - an increased
memory usage. What I suggest avoid that.
In addition, some implicits have some, though very small, runtime
performance impact (which, at least for me, is less important).
Again, what I suggest avoid that.
I am not saying that what I've very briefly outlined is possible
nor did I imply that, as an idea, it was fully flushed out.
But, I bet if this was a language feature, new-comers to Scala would
use it much more than implicits, have far fewer questions
concerning its use (as oppose to implicits) and could also understand
code using it much easier than implicits (have to figure out which
implicit is being used and where its located, etc, hence I
referred to them as explicits).
Thanks
Richard
On 07/10/2011 11:45 AM, Kevin Wright wrote:
Oops!
http://www.scala-lang.org/node/9111
https://github.com/kevinwright/Autoproxy-Lite
http://mp.binaervarianz.de/scala_roles_diploma_thesis_slides.pdf
On 10 July 2011 19:36, richard emberson <richard.emberson@gmail.com
<mailto:richard.emberson@gmail.com>> wrote:
Looking for a CS grad, under-grad or otherwise
capable individual willing to implement
Explicit Pimping / Dynamic Mixins in Scala.
See: https://issues.scala-lang.org/__browse/SUGGEST-3
<https://issues.scala-lang.org/browse/SUGGEST-3>
Ultimately, you'd have to end up working with the
Scala Folks to extend the language spec and augment
the compiler. Initially, a prototype extension to
the compiler would have to be created as well as
technical documentation indicating that the idea
is fully baked (at the current time it is rather raw).
As an added incentive, the implementer would get to
name the new language feature and become part of
the Scala language lore.
Regards
Richard Emberson
--
Quis custodiet ipsos custodes
--
Kevin Wright
gtalk / msn : kev.lee.wright@gmail.com <mailto:kev.lee.wright@gmail.com>
google+: http://gplus.to/thecoda
<mailto:kev.lee.wright@gmail.com>mail: kevin.wright@scalatechnology.com
<mailto:kevin.wright@scalatechnology.com>
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we should
not regard them as "lines produced" but as "lines spent": the current
conventional wisdom is so foolish as to book that count on the wrong
side of the ledger" ~ Dijkstra
Sun, 2011-07-10, 22:17
#4
Re: Explicit Pimping / Dynamic Mixins
On Sunday 10 July 2011, √iktor Ҡlang wrote:
> On Sun, Jul 10, 2011 at 9:57 PM, richard emberson <
>
> richard.emberson@gmail.com> wrote:
> > Oops indeed.
> >
> > I had looked at autoproxy-lite (a while ago) and scala-roles
> > (having worked on a Scala RBAC library).
> >
> > Do not want any additional runtime memory or performance impact.
>
> Could you explain how you think you can have runtime behavior without
> runtime cost?
Duh...
Magic, of course.
> > ...
RRS
Sun, 2011-07-10, 22:17
#5
Re: Explicit Pimping / Dynamic Mixins
On 07/10/2011 01:50 PM, Randall R Schulz wrote:
> On Sunday 10 July 2011, √iktor Ҡlang wrote:
>> On Sun, Jul 10, 2011 at 9:57 PM, richard emberson<
>>
>> richard.emberson@gmail.com> wrote:
>>> Oops indeed.
>>>
>>> I had looked at autoproxy-lite (a while ago) and scala-roles
>>> (having worked on a Scala RBAC library).
>>>
>>> Do not want any additional runtime memory or performance impact.
>>
>> Could you explain how you think you can have runtime behavior without
>> runtime cost?
>
> Duh...
>
> Magic, of course.
There was a mis-quote which I responded to: "*additional* runtime"
"Any sufficiently advanced technology is indistinguishable from magic"
Technology to some but magic to others.
>
>
>>> ...
>
>
> RRS
>
Sun, 2011-07-10, 22:27
#6
Re: Explicit Pimping / Dynamic Mixins
On 07/10/2011 01:46 PM, √iktor Ҡlang wrote:
>
>
> On Sun, Jul 10, 2011 at 9:57 PM, richard emberson
> > wrote:
>
> Oops indeed.
>
> I had looked at autoproxy-lite (a while ago) and scala-roles (having
> worked on a Scala RBAC library).
>
> Do not want any additional runtime memory or performance impact.
>
>
> Could you explain how you think you can have runtime behavior without
> runtime cost?
Should I respond to a mis-quote? The phrase was "additional runtime"
not "runtime".
So, lots of implicits that I have seen allocate a new object that
then has the additional pimping method.
With what I tossed out there has additional compile-time cost and
an additional class in the jar file, but does not allocate a new
object. So, it does not pay the implicits' cost of an additional
allocation and gc.
>
> As I said in the suggestion, I'd like to have no memory usage impact.
> I believe that proxies add a level of indirection - an increased
> memory usage. What I suggest avoid that.
>
> In addition, some implicits have some, though very small, runtime
> performance impact (which, at least for me, is less important).
> Again, what I suggest avoid that.
>
> I am not saying that what I've very briefly outlined is possible
> nor did I imply that, as an idea, it was fully flushed out.
>
> But, I bet if this was a language feature, new-comers to Scala would
> use it much more than implicits, have far fewer questions
> concerning its use (as oppose to implicits) and could also understand
> code using it much easier than implicits (have to figure out which
> implicit is being used and where its located, etc, hence I
> referred to them as explicits).
>
> Thanks
> Richard
>
>
>
> On 07/10/2011 11:45 AM, Kevin Wright wrote:
>
> Oops!
>
> http://www.scala-lang.org/__node/9111
>
> https://github.com/__kevinwright/Autoproxy-Lite
>
> http://mp.binaervarianz.de/__scala_roles_diploma_thesis___slides.pdf
>
>
>
>
> On 10 July 2011 19:36, richard emberson
>
> >> wrote:
>
> Looking for a CS grad, under-grad or otherwise
> capable individual willing to implement
> Explicit Pimping / Dynamic Mixins in Scala.
>
> See: https://issues.scala-lang.org/____browse/SUGGEST-3
>
> >
>
> Ultimately, you'd have to end up working with the
> Scala Folks to extend the language spec and augment
> the compiler. Initially, a prototype extension to
> the compiler would have to be created as well as
> technical documentation indicating that the idea
> is fully baked (at the current time it is rather raw).
>
> As an added incentive, the implementer would get to
> name the new language feature and become part of
> the Scala language lore.
>
> Regards
>
> Richard Emberson
> --
> Quis custodiet ipsos custodes
>
>
>
>
> --
> Kevin Wright
>
> gtalk / msn : kev.lee.wright@gmail.com
>
> >
>
> google+: http://gplus.to/thecoda
> >mail:
> kevin.wright@scalatechnology.__com
>
> >
>
> vibe / skype: kev.lee.wright
> quora: http://www.quora.com/Kevin-__Wright
>
> twitter: @thecoda
>
> "My point today is that, if we wish to count lines of code, we
> should
> not regard them as "lines produced" but as "lines spent": the
> current
> conventional wisdom is so foolish as to book that count on the wrong
> side of the ledger" ~ Dijkstra
>
>
> --
> Quis custodiet ipsos custodes
>
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe - Enterprise-Grade Scala from the Experts
>
> Twitter: @viktorklang
>
Sun, 2011-07-10, 22:27
#7
Re: Explicit Pimping / Dynamic Mixins
There was a mis-quote which I responded to: "*additional* runtime"
"Any sufficiently advanced technology is indistinguishable from magic"
This is also a mis-quote
As we all know, Gehm's Corollary to Clarke's 3rd law is correctly written: "Any technology distingushable from magic is insufficiently advanced"
Sun, 2011-07-10, 22:37
#8
Re: Explicit Pimping / Dynamic Mixins
On Sun, Jul 10, 2011 at 11:02 PM, richard emberson <richard.emberson@gmail.com> wrote:
On 07/10/2011 01:46 PM, √iktor Ҡlang wrote:
Should I respond to a mis-quote? The phrase was "additional runtime"
On Sun, Jul 10, 2011 at 9:57 PM, richard emberson
<richard.emberson@gmail.com <mailto:richard.emberson@gmail.com>> wrote:
Oops indeed.
I had looked at autoproxy-lite (a while ago) and scala-roles (having
worked on a Scala RBAC library).
Do not want any additional runtime memory or performance impact.
Could you explain how you think you can have runtime behavior without
runtime cost?
not "runtime".
Alright, lemme correct myself:
Could you explain how you think you can have "additional runtime" behavior without
"additional runtime" cost?
So, lots of implicits that I have seen allocate a new object that
then has the additional pimping method.
With what I tossed out there has additional compile-time cost and
an additional class in the jar file, but does not allocate a new
object. So, it does not pay the implicits' cost of an additional
allocation and gc.
Are you referring to allocation elision? (-XX:+DoEscapeAnalysis) ?
If so, then it's not really a predicatable optimization (if available).
As I said in the suggestion, I'd like to have no memory usage impact.
I believe that proxies add a level of indirection - an increased
memory usage. What I suggest avoid that.
In addition, some implicits have some, though very small, runtime
performance impact (which, at least for me, is less important).
Again, what I suggest avoid that.
I am not saying that what I've very briefly outlined is possible
nor did I imply that, as an idea, it was fully flushed out.
But, I bet if this was a language feature, new-comers to Scala would
use it much more than implicits, have far fewer questions
concerning its use (as oppose to implicits) and could also understand
code using it much easier than implicits (have to figure out which
implicit is being used and where its located, etc, hence I
referred to them as explicits).
Thanks
Richard
On 07/10/2011 11:45 AM, Kevin Wright wrote:
Oops!
http://www.scala-lang.org/__node/9111
<http://www.scala-lang.org/node/9111>
https://github.com/__kevinwright/Autoproxy-Lite
<https://github.com/kevinwright/Autoproxy-Lite>
http://mp.binaervarianz.de/__scala_roles_diploma_thesis___slides.pdf
<http://mp.binaervarianz.de/scala_roles_diploma_thesis_slides.pdf>
On 10 July 2011 19:36, richard emberson
<richard.emberson@gmail.com <mailto:richard.emberson@gmail.com>
<mailto:richard.emberson@__gmail.com
<mailto:richard.emberson@gmail.com>>> wrote:
Looking for a CS grad, under-grad or otherwise
capable individual willing to implement
Explicit Pimping / Dynamic Mixins in Scala.
See: https://issues.scala-lang.org/____browse/SUGGEST-3
<https://issues.scala-lang.org/__browse/SUGGEST-3>
<https://issues.scala-lang.__org/browse/SUGGEST-3
<https://issues.scala-lang.org/browse/SUGGEST-3>>
Ultimately, you'd have to end up working with the
Scala Folks to extend the language spec and augment
the compiler. Initially, a prototype extension to
the compiler would have to be created as well as
technical documentation indicating that the idea
is fully baked (at the current time it is rather raw).
As an added incentive, the implementer would get to
name the new language feature and become part of
the Scala language lore.
Regards
Richard Emberson
--
Quis custodiet ipsos custodes
--
Kevin Wright
gtalk / msn : kev.lee.wright@gmail.com
<mailto:kev.lee.wright@gmail.com>
<mailto:kev.lee.wright@gmail.__com
<mailto:kev.lee.wright@gmail.com>>
google+: http://gplus.to/thecoda
<mailto:kev.lee.wright@gmail.__com
<mailto:kev.lee.wright@gmail.com>>mail:
kevin.wright@scalatechnology.__com
<mailto:kevin.wright@scalatechnology.com>
<mailto:kevin.wright@__scalatechnology.com
<mailto:kevin.wright@scalatechnology.com>>
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-__Wright
<http://www.quora.com/Kevin-Wright>
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we
should
not regard them as "lines produced" but as "lines spent": the
current
conventional wisdom is so foolish as to book that count on the wrong
side of the ledger" ~ Dijkstra
--
Quis custodiet ipsos custodes
--
Viktor Klang
Akka Tech Lead
Typesafe <http://www.typesafe.com/>- Enterprise-Grade Scala from the Experts
Twitter: @viktorklang
Sun, 2011-07-10, 22:37
#9
Re: Explicit Pimping / Dynamic Mixins
I was quoting a Wikipedia article please take up your
concerns with them.
On 07/10/2011 02:15 PM, Kevin Wright wrote:
> There was a mis-quote which I responded to: "*additional* runtime"
>
> "Any sufficiently advanced technology is indistinguishable from magic"
>
>
> This is also a mis-quote
>
> As we all know, Gehm's Corollary to Clarke's 3rd law is correctly written:
> "Any technology distingushable from magic is insufficiently advanced"
>
>
Sun, 2011-07-10, 23:07
#10
Re: Explicit Pimping / Dynamic Mixins
On 07/10/2011 02:08 PM, √iktor Ҡlang wrote:
>
>
> On Sun, Jul 10, 2011 at 11:02 PM, richard emberson
> > wrote:
>
>
>
> On 07/10/2011 01:46 PM, √iktor Ҡlang wrote:
>
>
>
> On Sun, Jul 10, 2011 at 9:57 PM, richard emberson
>
> >> wrote:
>
> Oops indeed.
>
> I had looked at autoproxy-lite (a while ago) and scala-roles
> (having
> worked on a Scala RBAC library).
>
> Do not want any additional runtime memory or performance impact.
>
>
> Could you explain how you think you can have runtime behavior
> without
> runtime cost?
>
> Should I respond to a mis-quote? The phrase was "additional runtime"
> not "runtime".
>
>
> Alright, lemme correct myself:
>
> Could you explain how you think you can have "additional runtime"
> behavior without
> "additional runtime" cost?
See below.
>
> So, lots of implicits that I have seen allocate a new object that
> then has the additional pimping method.
> With what I tossed out there has additional compile-time cost and
> an additional class in the jar file, but does not allocate a new
> object. So, it does not pay the implicits' cost of an additional
> allocation and gc.
>
>
> Are you referring to allocation elision? (-XX:+/DoEscapeAnalysis) ?/
> If so, then it's not really a predicatable optimization (if available).
Allocating an object costs more than not allocating an object. At
a minimum you have to check to see if there's enough space
left, more the pointer and return the old pointer (copy collector).
Yes? No?
>
>
> As I said in the suggestion, I'd like to have no memory
> usage impact.
> I believe that proxies add a level of indirection - an increased
> memory usage. What I suggest avoid that.
>
> In addition, some implicits have some, though very small,
> runtime
> performance impact (which, at least for me, is less important).
> Again, what I suggest avoid that.
>
> I am not saying that what I've very briefly outlined is possible
> nor did I imply that, as an idea, it was fully flushed out.
>
> But, I bet if this was a language feature, new-comers to
> Scala would
> use it much more than implicits, have far fewer questions
> concerning its use (as oppose to implicits) and could also
> understand
> code using it much easier than implicits (have to figure out
> which
> implicit is being used and where its located, etc, hence I
> referred to them as explicits).
>
> Thanks
> Richard
>
>
>
> On 07/10/2011 11:45 AM, Kevin Wright wrote:
>
> Oops!
>
> http://www.scala-lang.org/____node/9111
>
> >
> https://github.com/____kevinwright/Autoproxy-Lite
>
> >
> http://mp.binaervarianz.de/____scala_roles_diploma_thesis_____slides.pdf
>
> >
>
>
>
> On 10 July 2011 19:36, richard emberson
>
> >
> __gma__il.com
> >>> wrote:
>
> Looking for a CS grad, under-grad or otherwise
> capable individual willing to implement
> Explicit Pimping / Dynamic Mixins in Scala.
>
> See:
> https://issues.scala-lang.org/______browse/SUGGEST-3
>
> >
> >>
>
> Ultimately, you'd have to end up working with the
> Scala Folks to extend the language spec and augment
> the compiler. Initially, a prototype extension to
> the compiler would have to be created as well as
> technical documentation indicating that the idea
> is fully baked (at the current time it is rather raw).
>
> As an added incentive, the implementer would get to
> name the new language feature and become part of
> the Scala language lore.
>
> Regards
>
> Richard Emberson
> --
> Quis custodiet ipsos custodes
>
>
>
>
> --
> Kevin Wright
>
> gtalk / msn : kev.lee.wright@gmail.com
>
> >
> ____com
> >>
>
> google+: http://gplus.to/thecoda
> ____com
> >>mail:
> kevin.wright@scalatechnology.____com
> >
> __scalate__chnology.com
>
> >>
>
> vibe / skype: kev.lee.wright
> quora: http://www.quora.com/Kevin-____Wright
>
> >
> twitter: @thecoda
>
> "My point today is that, if we wish to count lines of code, we
> should
> not regard them as "lines produced" but as "lines
> spent": the
> current
> conventional wisdom is so foolish as to book that count
> on the wrong
> side of the ledger" ~ Dijkstra
>
>
> --
> Quis custodiet ipsos custodes
>
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe - Enterprise-Grade Scala from
> the Experts
>
> Twitter: @viktorklang
>
>
> --
> Quis custodiet ipsos custodes
>
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe - Enterprise-Grade Scala from the Experts
>
> Twitter: @viktorklang
>
Sun, 2011-07-10, 23:07
#11
Re: Explicit Pimping / Dynamic Mixins
2011/7/10 richard emberson <richard.emberson@gmail.com>
On 07/10/2011 02:08 PM, √iktor Ҡlang wrote:
On Sun, Jul 10, 2011 at 11:02 PM, richard emberson
<richard.emberson@gmail.com <mailto:richard.emberson@gmail.com>> wrote:
On 07/10/2011 01:46 PM, √iktor Ҡlang wrote:
On Sun, Jul 10, 2011 at 9:57 PM, richard emberson
<richard.emberson@gmail.com <mailto:richard.emberson@gmail.com>
<mailto:richard.emberson@__gmail.com
<mailto:richard.emberson@gmail.com>>> wrote:
Oops indeed.
I had looked at autoproxy-lite (a while ago) and scala-roles
(having
worked on a Scala RBAC library).
Do not want any additional runtime memory or performance impact.
Could you explain how you think you can have runtime behavior
without
runtime cost?
Should I respond to a mis-quote? The phrase was "additional runtime"
not "runtime".
Alright, lemme correct myself:
Could you explain how you think you can have "additional runtime"
behavior without
"additional runtime" cost?
See below.
So, lots of implicits that I have seen allocate a new object that
then has the additional pimping method.
With what I tossed out there has additional compile-time cost and
an additional class in the jar file, but does not allocate a new
object. So, it does not pay the implicits' cost of an additional
allocation and gc.
Are you referring to allocation elision? (-XX:+/DoEscapeAnalysis) ?/
If so, then it's not really a predicatable optimization (if available).
Allocating an object costs more than not allocating an object.
Which is why my questions above are interesting in this context, care to answer them?
And yes, for high performance you really want to avoid allocations (especially in a highly parallel system).
At
a minimum you have to check to see if there's enough space
left, more the pointer and return the old pointer (copy collector).
Yes? No?
As I said in the suggestion, I'd like to have no memory
usage impact.
I believe that proxies add a level of indirection - an increased
memory usage. What I suggest avoid that.
In addition, some implicits have some, though very small,
runtime
performance impact (which, at least for me, is less important).
Again, what I suggest avoid that.
I am not saying that what I've very briefly outlined is possible
nor did I imply that, as an idea, it was fully flushed out.
But, I bet if this was a language feature, new-comers to
Scala would
use it much more than implicits, have far fewer questions
concerning its use (as oppose to implicits) and could also
understand
code using it much easier than implicits (have to figure out
which
implicit is being used and where its located, etc, hence I
referred to them as explicits).
Thanks
Richard
On 07/10/2011 11:45 AM, Kevin Wright wrote:
Oops!
http://www.scala-lang.org/____node/9111
<http://www.scala-lang.org/__node/9111>
<http://www.scala-lang.org/__node/9111
<http://www.scala-lang.org/node/9111>>
https://github.com/____kevinwright/Autoproxy-Lite
<https://github.com/__kevinwright/Autoproxy-Lite>
<https://github.com/__kevinwright/Autoproxy-Lite
<https://github.com/kevinwright/Autoproxy-Lite>>
http://mp.binaervarianz.de/____scala_roles_diploma_thesis_____slides.pdf
<http://mp.binaervarianz.de/__scala_roles_diploma_thesis___slides.pdf>
<http://mp.binaervarianz.de/__scala_roles_diploma_thesis___slides.pdf
<http://mp.binaervarianz.de/scala_roles_diploma_thesis_slides.pdf>>
On 10 July 2011 19:36, richard emberson
<richard.emberson@gmail.com <mailto:richard.emberson@gmail.com>
<mailto:richard.emberson@__gmail.com
<mailto:richard.emberson@gmail.com>>
<mailto:richard.emberson@
<mailto:richard.emberson@>__gma__il.com <http://gmail.com>
<mailto:richard.emberson@__gmail.com
<mailto:richard.emberson@gmail.com>>>> wrote:
Looking for a CS grad, under-grad or otherwise
capable individual willing to implement
Explicit Pimping / Dynamic Mixins in Scala.
See:
https://issues.scala-lang.org/______browse/SUGGEST-3
<https://issues.scala-lang.org/____browse/SUGGEST-3>
<https://issues.scala-lang.__org/__browse/SUGGEST-3
<https://issues.scala-lang.org/__browse/SUGGEST-3>>
<https://issues.scala-lang.____org/browse/SUGGEST-3
<https://issues.scala-lang.__org/browse/SUGGEST-3
<https://issues.scala-lang.org/browse/SUGGEST-3>>>
Ultimately, you'd have to end up working with the
Scala Folks to extend the language spec and augment
the compiler. Initially, a prototype extension to
the compiler would have to be created as well as
technical documentation indicating that the idea
is fully baked (at the current time it is rather raw).
As an added incentive, the implementer would get to
name the new language feature and become part of
the Scala language lore.
Regards
Richard Emberson
--
Quis custodiet ipsos custodes
--
Kevin Wright
gtalk / msn : kev.lee.wright@gmail.com
<mailto:kev.lee.wright@gmail.com>
<mailto:kev.lee.wright@gmail.__com
<mailto:kev.lee.wright@gmail.com>>
<mailto:kev.lee.wright@gmail. <mailto:kev.lee.wright@gmail.>____com
<mailto:kev.lee.wright@gmail.__com
<mailto:kev.lee.wright@gmail.com>>>
google+: http://gplus.to/thecoda
<mailto:kev.lee.wright@gmail. <mailto:kev.lee.wright@gmail.>____com
<mailto:kev.lee.wright@gmail.__com
<mailto:kev.lee.wright@gmail.com>>>mail:
kevin.wright@scalatechnology.____com
<mailto:kevin.wright@__scalatechnology.com
<mailto:kevin.wright@scalatechnology.com>>
<mailto:kevin.wright@
<mailto:kevin.wright@>__scalate__chnology.com
<http://scalatechnology.com>
<mailto:kevin.wright@__scalatechnology.com
<mailto:kevin.wright@scalatechnology.com>>>
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-____Wright
<http://www.quora.com/Kevin-__Wright>
<http://www.quora.com/Kevin-__Wright
<http://www.quora.com/Kevin-Wright>>
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we
should
not regard them as "lines produced" but as "lines
spent": the
current
conventional wisdom is so foolish as to book that count
on the wrong
side of the ledger" ~ Dijkstra
--
Quis custodiet ipsos custodes
--
Viktor Klang
Akka Tech Lead
Typesafe <http://www.typesafe.com/>- Enterprise-Grade Scala from
the Experts
Twitter: @viktorklang
--
Quis custodiet ipsos custodes
--
Viktor Klang
Akka Tech Lead
Typesafe <http://www.typesafe.com/>- Enterprise-Grade Scala from the Experts
Twitter: @viktorklang
Sun, 2011-07-10, 23:37
#12
Re: Explicit Pimping / Dynamic Mixins
richard emberson skrev 2011-07-10 23:50:
> Allocating an object costs more than not allocating an object. At
> a minimum you have to check to see if there's enough space
> left, more the pointer and return the old pointer (copy collector).
> Yes? No?
Could please explain how you will implement this instance runtime type
change on the JVM?
/Jesper Nordenberg
Mon, 2011-07-11, 01:27
#13
Re: Explicit Pimping / Dynamic Mixins
Woops, forgot to reply all. My post and Richard's response:
On Jul 10, 2011 5:19 PM, "richard emberson" <richard.emberson@gmail.com> wrote:
>
>
>
> On 07/10/2011 03:58 PM, Derek Williams wrote:
>>
>> The suggested naming would be confusing I think, as any implicit can
>> already be done explicitly.
>>
>> I also have some questions:
>>
>> Are you interested in only adding methods, or are you wanting to add
>> variables to an object as well?
>
>
> Basically, the idea is to associate one or more traits (fully
> implemented traits, not Java-interface-like traits) with an object.
> As such, traits can have both methods and variables.
>
>
>>
>> Are you wanting the mixin to affect all references to an object, or only
>> where the inferred (or explicit) type includes the mixin?
>
>
> Once an object is pimped,... well I guess its a new object with the
> additional methods and/or variables. An Int pimped with trait Foo,
> could be passed around as an Int, but then to access a Foo member
> it would have to be cast (isInstanceOf/asInstanceOf or a match
> statement) to Foo.
> Just like classes with traits, a mixin trait with a self type of
> the object, could then access the methods (public and protected)
> of the object.
>
>
>>
>> If variables aren't going to be added, and the mixin only applies where
>> the mixin is included in the type, isn't this just a different syntax
>> for type classes? Phantom types should allow you to specify which type
>> class should be used with an object. The only thing a type class
>> wouldn't be able to do is access protected methods, but that seems like
>> it might be an unsafe use of your idea anyways.
>
>
> For user new to Scala, I think that the notion on an Explicit is much
> easier to understand than Implicits. Its also easier to see where
> the action takes place and there are no new keywords added to the
> Scala language (where as Implicits added two new keywords??).
> I would bet if this was a feature of the language many uses and all
> beginners would use it rather than Implicits.
> Of course, implicits are more powerful since they can also deal with
> types. But, Explicits lets one access protected methods/variables
> which Implicits can not do (I thinks thats true at any rate).
>
>
>>
>> If you expect the mixin to affect all instances of an object, or you
>> want to add variables, wouldn't there need to be some kind of
>> allocation? If not, it seems like this technique would work great with
>> adding a Manifest to an object with minimal extra overhead. It just
>> doesn't seem very possible though.
>
>
> An Explicit only affects an instance which is explicitly pimped.
> Since it really becomes a new instance of the class implied by
> the instance and the pimping traits.
>
> And, yes, writing this to you I realize that if the Explicit contained
> a variable, then there would have to be an allocation (all my examples
> dealt with method-only Explicits).
>
> The Persister example in the Suggestions webpage, is my primary
> motivation for Explicits. I create a library with an API and user
> can then extend the objects returned by my factory methods.
>
>>
>> Derek Williams
>>
>
> --
> Quis custodiet ipsos custodes
Mon, 2011-07-11, 01:37
#14
Re: Explicit Pimping / Dynamic Mixins
On Jul 10, 2011 5:19 PM, "richard emberson" <richard.emberson@gmail.com> wrote:
>
> Basically, the idea is to associate one or more traits (fully
> implemented traits, not Java-interface-like traits) with an object.
> As such, traits can have both methods and variables.
>
Where would the variable be stored in that case? Wouldn't a new object need to be created to store it and associate it with the original object?
> An Explicit only affects an instance which is explicitly pimped.
> Since it really becomes a new instance of the class implied by
> the instance and the pimping traits.
When you say "becomes a new instance" do you mean that literally? Or in other words, allocates a new instance?
>
> And, yes, writing this to you I realize that if the Explicit contained
> a variable, then there would have to be an allocation (all my examples
> dealt with method-only Explicits).
Do you mean an allocation of an object to hold the variable, or the allocation of the variable itself?
> The Persister example in the Suggestions webpage, is my primary
> motivation for Explicits. I create a library with an API and user
> can then extend the objects returned by my factory methods.
That is why I wanted clarification, that example looked like it could easily be implemented with type classes. I wanted to see if you were suggesting just new syntax, or if there was deeper semantic changes suggested (which I am still not 100% sure of).
I'm getting way over my head here I think. My knowledge of how the jvm works and what is possible is limited, so my questions might be invalid. I'm also unsure of your own knowledge, is this something that you have a good idea how to implement? Or is it something you need someone else to figure out? Just wondering if my questions are relevant or not, as you might not have answers for them yet. I also have questions regarding reflection, conflicting method names, java interoperability, use with primitives... but I think I am digging into details too much. But there does seem to be a lot of possible unexpected behavior for the target audience of this change.
Mon, 2011-07-11, 02:37
#15
Re: Explicit Pimping / Dynamic Mixins
> That is why I wanted clarification, that example looked like it could
> easily be implemented with type classes. I wanted to see if you were
> suggesting just new syntax, or if there was deeper semantic changes
> suggested (which I am still not 100% sure of).
>
I'd be very happy if you (or someone) could show me how to do
the following with type classes (and implicits).
There is a third-party library with a trait Foo and a factory
object, 3rdPartyLib, with the method "def getFoo: Foo".
The Foo trait has a public and a protected method.
The coder using the library want to wrap Foo's methods with
her own code.
// In third-party library
trait Foo {
def opOne: Unit
protected def opTwo: Boolean
}
// How Foo is to be pimped
PimpedFoo extends Foo { self: Foo =>
// around method
def opOne: Unit = {
logger.trace("Before calling opOne")
super.opOne
logger.trace("After calling opOne")
}
// before method
protected def opTwo: Boolean =
if (someCondition) false
else super.opTwo
}
// User code using the third-party library
{
// block of code ...
// Pimp f1
val f1 = 3rdPartyLib.getFoo
// Do not Pimp f2
val f2 = 3rdPartyLib.getFoo
// use f1 and f2
}
Here, within the same block of code, one call to get Foo returns
a Foo that is pimped while the next does not.
With the proposed Explicits, one would do the following:
{
// block of code ...
// Pimp f1
val f1 = 3rdPartyLib.getFoo with PimpedFoo
// Do not Pimp f2
val f2 = 3rdPartyLib.getFoo
// use f1 and f2
}
which at the end coders level is very simple syntax with no new
Scala keywords.
If this can currently be done with Scala 9.0x with type classes
and implicits, I'd be very happy to be shown how to do it.
Also, I had not considered traits with variables until your email and, it
would seem, that with Explicits one would have to do an allocation
to enhance an existing object with a new variable.
So, for extra credit, using type classes (and implicits)
I'd also like to be shown how to augment and existing object of
type Foo returned by the library with
an additional instance variable if its possible.
Thanks
Richard
Mon, 2011-07-11, 06:17
#16
Re: Explicit Pimping / Dynamic Mixins
On Sun, Jul 10, 2011 at 7:30 PM, richard emberson
wrote:
> I'd be very happy if you (or someone) could show me how to do
> the following with type classes (and implicits).
Not exactly how you wanted, but here is a simple runnable example.
case class Foo(bar: String)
trait Logger[-A] { def log(a: Any): Unit }
object Logger {
sealed trait PlainLogger
sealed trait FancyLogger
val nolog = new Logger[Any] { def log(a: Any) = println("no logging") }
implicit val plainLogger = new Logger[PlainLogger] { def log(a: Any)
= println(a.toString) }
implicit val fancyLogger = new Logger[FancyLogger] { def log(a: Any)
= println("LOG: " + a.toString) }
def log[A](a: A)(implicit logger: Logger[A] = nolog) = logger log a
def plain[A](a: A) = a.asInstanceOf[A with PlainLogger]
def fancy[A](a: A) = a.asInstanceOf[A with FancyLogger]
}
val f1 = Foo("Hello")
val f2 = Logger plain Foo("World")
val f3 = Logger fancy Foo("Bar")
println("Logging f1...")
Logger log f1
println("Logging f2...")
Logger log f2
println("Logging f3...")
Logger log f3
Output:
Logging f1...
no logging
Logging f2...
Foo(World)
Logging f3...
LOG: Foo(Bar)
This only gives different behavior depending on the type. Nothing is
associated with the actual object, and no new variables can be added.
To do either of those an implicit conversion to a pimped type would be
needed (which you are trying to avoid). This can also be changed to
only be usable with a specific type instead of Any so you can call
other methods defined for that type. No access to protected methods
either.
There is of course more boilerplate then with your suggested syntax,
and there is room for improvement as I didn't have much time to work
on it and I haven't done this kind of thing before.
--
Derek Williams
Mon, 2011-07-11, 08:57
#17
Re: Explicit Pimping / Dynamic Mixins
Derek Williams skrev 2011-07-11 07:15:
> def plain[A](a: A) = a.asInstanceOf[A with PlainLogger]
> def fancy[A](a: A) = a.asInstanceOf[A with FancyLogger]
Would you seriously use that code in production?
/Jesper Nordenberg
Mon, 2011-07-11, 13:17
#18
Re: Re: Explicit Pimping / Dynamic Mixins
Nope. I personally don't see the need for this.
Derek Williams
On Jul 11, 2011 1:56 AM, "Jesper Nordenberg" <megagurka@yahoo.com> wrote:> Derek Williams skrev 2011-07-11 07:15:
>> def plain[A](a: A) = a.asInstanceOf[A with PlainLogger]
>> def fancy[A](a: A) = a.asInstanceOf[A with FancyLogger]
>
> Would you seriously use that code in production?
>
> /Jesper Nordenberg
>
Mon, 2011-07-11, 15:17
#19
Re: Explicit Pimping / Dynamic Mixins
The requested capabilities I described in the previous
email were very specific. Yes, one can write code that
addresses other things but I wanted a demonstration that
the capabilities of the proposed Explicits extension to Scala
could be done with existing Scala, e.g., wrapping an existing objects
public and protected methods, adding methods (which implicits can
do), selectively pimping some objects in a code block but not
others of the same type in the same code block, possibly,
adding additional instance variables to objects, don't use
a wrapper or proxy objects which adds to memory usage, and that the pimping
of an object is a persistent part of the object that can then be used
throughout an application (even through a serialization/de-serialization
cycle - talking about enterprise use).
If they could be addressed, then there is no need for Explicits.
If they can not be duplicate in current Scala, then, at least,
Explicits brings new capabilities.
Of course, whether or not one chooses to use them is a different issue.
Per your example, it seems, at least to me, that it takes a lot
more work and complexity with your approach to do a lot less than
what I have proposed in my Explicits example in the previous email.
If the goal is to make it easier to get things done, for pimping
objects Explicits are a lot simpler and clearer than Implicits.
I do appreciate your work in crafting the code in your email - thanks.
Richard
On 07/10/2011 10:15 PM, Derek Williams wrote:
> On Sun, Jul 10, 2011 at 7:30 PM, richard emberson
> wrote:
>> I'd be very happy if you (or someone) could show me how to do
>> the following with type classes (and implicits).
>
> Not exactly how you wanted, but here is a simple runnable example.
>
> case class Foo(bar: String)
>
> trait Logger[-A] { def log(a: Any): Unit }
>
> object Logger {
>
> sealed trait PlainLogger
> sealed trait FancyLogger
>
> val nolog = new Logger[Any] { def log(a: Any) = println("no logging") }
>
> implicit val plainLogger = new Logger[PlainLogger] { def log(a: Any)
> = println(a.toString) }
> implicit val fancyLogger = new Logger[FancyLogger] { def log(a: Any)
> = println("LOG: " + a.toString) }
>
> def log[A](a: A)(implicit logger: Logger[A] = nolog) = logger log a
>
> def plain[A](a: A) = a.asInstanceOf[A with PlainLogger]
> def fancy[A](a: A) = a.asInstanceOf[A with FancyLogger]
>
> }
>
> val f1 = Foo("Hello")
> val f2 = Logger plain Foo("World")
> val f3 = Logger fancy Foo("Bar")
>
> println("Logging f1...")
> Logger log f1
>
> println("Logging f2...")
> Logger log f2
>
> println("Logging f3...")
> Logger log f3
>
> Output:
> Logging f1...
> no logging
> Logging f2...
> Foo(World)
> Logging f3...
> LOG: Foo(Bar)
>
> This only gives different behavior depending on the type. Nothing is
> associated with the actual object, and no new variables can be added.
> To do either of those an implicit conversion to a pimped type would be
> needed (which you are trying to avoid). This can also be changed to
> only be usable with a specific type instead of Any so you can call
> other methods defined for that type. No access to protected methods
> either.
>
> There is of course more boilerplate then with your suggested syntax,
> and there is room for improvement as I didn't have much time to work
> on it and I haven't done this kind of thing before.
>
> --
> Derek Williams
>
Mon, 2011-07-11, 15:57
#20
Re: Explicit Pimping / Dynamic Mixins
Of course any example I could give you would have the same limitations that I previously mentioned. I just wasn't 100% sure what it was you were actually proposing. I think I understand now, and it is far enough beyond my abilities that it does seem like magic (or not possible).
I personally would be happy with a cleaner way of creating type classes, as I find that they do a good enough job when I want to add additional methods to objects without extra allocations. I wouldn't actually use them like I did in my example though.
Good luck!
Derek Williams
On Jul 11, 2011 8:01 AM, "richard emberson" <richard.emberson@gmail.com> wrote:> The requested capabilities I described in the previous
> email were very specific. Yes, one can write code that
> addresses other things but I wanted a demonstration that
> the capabilities of the proposed Explicits extension to Scala
> could be done with existing Scala, e.g., wrapping an existing objects
> public and protected methods, adding methods (which implicits can
> do), selectively pimping some objects in a code block but not
> others of the same type in the same code block, possibly,
> adding additional instance variables to objects, don't use
> a wrapper or proxy objects which adds to memory usage, and that the pimping
> of an object is a persistent part of the object that can then be used
> throughout an application (even through a serialization/de-serialization
> cycle - talking about enterprise use).
> If they could be addressed, then there is no need for Explicits.
> If they can not be duplicate in current Scala, then, at least,
> Explicits brings new capabilities.
>
> Of course, whether or not one chooses to use them is a different issue.
>
> Per your example, it seems, at least to me, that it takes a lot
> more work and complexity with your approach to do a lot less than
> what I have proposed in my Explicits example in the previous email.
> If the goal is to make it easier to get things done, for pimping
> objects Explicits are a lot simpler and clearer than Implicits.
>
> I do appreciate your work in crafting the code in your email - thanks.
>
> Richard
>
> On 07/10/2011 10:15 PM, Derek Williams wrote:
>> On Sun, Jul 10, 2011 at 7:30 PM, richard emberson
>> <richard.emberson@gmail.com> wrote:
>>> I'd be very happy if you (or someone) could show me how to do
>>> the following with type classes (and implicits).
>>
>> Not exactly how you wanted, but here is a simple runnable example.
>>
>> case class Foo(bar: String)
>>
>> trait Logger[-A] { def log(a: Any): Unit }
>>
>> object Logger {
>>
>> sealed trait PlainLogger
>> sealed trait FancyLogger
>>
>> val nolog = new Logger[Any] { def log(a: Any) = println("no logging") }
>>
>> implicit val plainLogger = new Logger[PlainLogger] { def log(a: Any)
>> = println(a.toString) }
>> implicit val fancyLogger = new Logger[FancyLogger] { def log(a: Any)
>> = println("LOG: " + a.toString) }
>>
>> def log[A](a: A)(implicit logger: Logger[A] = nolog) = logger log a
>>
>> def plain[A](a: A) = a.asInstanceOf[A with PlainLogger]
>> def fancy[A](a: A) = a.asInstanceOf[A with FancyLogger]
>>
>> }
>>
>> val f1 = Foo("Hello")
>> val f2 = Logger plain Foo("World")
>> val f3 = Logger fancy Foo("Bar")
>>
>> println("Logging f1...")
>> Logger log f1
>>
>> println("Logging f2...")
>> Logger log f2
>>
>> println("Logging f3...")
>> Logger log f3
>>
>> Output:
>> Logging f1...
>> no logging
>> Logging f2...
>> Foo(World)
>> Logging f3...
>> LOG: Foo(Bar)
>>
>> This only gives different behavior depending on the type. Nothing is
>> associated with the actual object, and no new variables can be added.
>> To do either of those an implicit conversion to a pimped type would be
>> needed (which you are trying to avoid). This can also be changed to
>> only be usable with a specific type instead of Any so you can call
>> other methods defined for that type. No access to protected methods
>> either.
>>
>> There is of course more boilerplate then with your suggested syntax,
>> and there is room for improvement as I didn't have much time to work
>> on it and I haven't done this kind of thing before.
>>
>> --
>> Derek Williams
>>
>
> --
> Quis custodiet ipsos custodes
http://www.scala-lang.org/node/9111https://github.com/kevinwright/Autoproxy-Lite http://mp.binaervarianz.de/scala_roles_diploma_thesis_slides.pdf
On 10 July 2011 19:36, richard emberson <richard.emberson@gmail.com> wrote: