[The Java Posse] Re: Lombok and Mixins

2009-08-29 Thread James Iry
For various practical reasons it's usually better to not define fields in Scala traits, but Scala does allow it scala> trait Foo { var x = 42 } defined trait Foo scala> class Bar extends Foo defined class Bar scala> val b = new Bar b: Bar = b...@8be1c9 scala> b.x res2: Int = 42 scala> b.x = 13

[The Java Posse] Re: Lombok and Mixins

2009-08-28 Thread Reinier Zwitserloot
I think you're mixing two different (but similar) concepts together. The basic traits feature of scala allows you to define default implementations in interfaces, which any implementing classes automatically pick up on unless you override them. It's very similar to multiple inheritance, except tha

[The Java Posse] Re: Lombok and Mixins

2009-08-27 Thread Graham Allan
> If someone has a better idea I'd love to hear it. I don't proclaim that, but I have a suggestion. This seems to be such a similar idea to traits* that it may be worth making the leap to them if you consider them to be more powerful. One thing with the delegates idea is that they don't allow

[The Java Posse] Re: Lombok and Mixins

2009-08-27 Thread Reinier Zwitserloot
You're going to get a bunch of errors if you attempt to edit lombok code in a smart editor that doesn't have lombok support installed, yes. It's unavoidable. On Aug 27, 5:31 am, Mark Derricutt wrote: > For javac maybe, but not for IDEA or Netbeans, or eclipse without the lombok > plugin (thats m

[The Java Posse] Re: Lombok and Mixins

2009-08-26 Thread Mark Derricutt
For javac maybe, but not for IDEA or Netbeans, or eclipse without the lombok plugin (thats more what I was meaning). On Thu, Aug 27, 2009 at 2:30 PM, Reinier Zwitserloot wrote: > Nope; lombok injects those methods well before the latter stages of > the error finding process runs - which is where

[The Java Posse] Re: Lombok and Mixins

2009-08-26 Thread Reinier Zwitserloot
Nope; lombok injects those methods well before the latter stages of the error finding process runs - which is where problematic typing relations, such as missing methods that you ought to implement due to an interface, are found. It's just like using "getFoo();" in your own method when getFoo() is

[The Java Posse] Re: Lombok and Mixins

2009-08-26 Thread Mark Derricutt
Without being abstract, and without IDE support this would throw errors as the class/source doesn't implement the List interface, but lombok could (if possible) drop the abstract bytecode marker, and use an implementation mentioned in the annotation. public abstract class Something extends Whateve

[The Java Posse] Re: Lombok and Mixins

2009-08-26 Thread Reinier Zwitserloot
Simple. public class Something extends Whatever implements List { private @Delegate List listDelegate = new ArrayList(); } lombok would add all methods that exist in List.java (as that is the type of 'listDelegate' - arraylist is merely what's assigned to it, it's about the type of the field