FYI, there's an interesting discussion going on right now over on groovy-user
about traits.
http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-tt5715831.html#none
-matthew
--
View this message in context:
http://aspectj.2085585.n4.nabble.com/Trait-syntax-sugar-tp4650566p4650981.html
Entered issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=405043 for
tracking this.
--
View this message in context:
http://aspectj.2085585.n4.nabble.com/Trait-syntax-sugar-tp4650566p4650847.html
Sent from the AspectJ - users mailing list archive at Nabble.com.
I would love to do something along these lines to smooth out this very
common use case. I'd also like to revisit the mangled accessors too
(and all the generated code). Much of it was designed to meet a
specific use case but that turns out not to be the way people want to
use (or want to think
On Mon, Oct 8, 2012 at 7:40 PM, Andy Clement andrew.clem...@gmail.comwrote:
I would love to do something along these lines to smooth out this very
common use case. I'd also like to revisit the mangled accessors too
(and all the generated code). [snip]
It seems like the syntax could be a
Hi all,
I've used a common ITD pattern for years now to introduce interface
implementation(s) into existing classes when I have well-encapsulated,
orthogonal state behavior that I want to introduce. Here's a simple
example (hand-written, but gives you the gist): suppose several of my
domain
Cool idea. I would be guessing this might not be the highest priority in
AspectJ development, considering other parts of AspectJ and especially AJDT
that need attention, but still if you ask WDYT: cool. ;-)
--
Alexander Kriegisch
Am 05.10.2012 um 16:56 schrieb Matthew Adams
