practically speaking that will make it very hard to support data and code migration during refactoring.
I have found that all the cases in Jenkins where there is a public field holding data are usually cases where I end up screaming "why KK why" as you need to refactor and want to use a getter to maintain backwards compat. Additionally, every case where you don't have an explicit Descriptor base type for a new API class, even KK now is screaming "why KK why" at himself for those cases where he didn't. It would be different if Java actually supported properties so that you can replace direct field access with a getter if you need to migrate the internal storage, or if you need to put some synchronization constraints. I say quit whining and just do it the "right" way even if that means a little more typing now... for a lot less pain down the road On 2 September 2014 18:16, nicolas de loof <[email protected]> wrote: > What I'd like, for simplest component, is to only have to write : > > > @Described("display name") > public class Foo extends ... { > > @DataBound public String data; > > } > > maybe could be implemented with some Lombok custom code processor > > > 2014-09-02 18:44 GMT+02:00 nicolas de loof <[email protected]>: > > >> >> >> 2014-09-02 18:11 GMT+02:00 Jesse Glick <[email protected]>: >> >> On Tue, Sep 2, 2014 at 8:38 AM, nicolas de loof >>> <[email protected]> wrote: >>> > If a @DataBoundConstructor is required then this new annotation only >>> offer >>> > half the benefit I expected >>> >>> What is the problem? The @DBC can still be used for a couple mandatory >>> fields. By having an empty one you clearly indicate that all fields >>> are optional. >>> >> >> I never considered this to be a way to declare optional attributes, just >> expected @DataBoundSetter to be an alternative to @DataBoundConstructor >> (fully removing it) just like @Inject filed injection in a CDI context. >> >> >>> >>> > I also wonder why the name, not just "@DataBound". >>> >>> Well if the constructor annotation were @DataBound to begin with, then >>> it would make sense to just expand its target types. Since it is not, >>> it is more consistent to name it according to what it is. >>> >> >> @DataBoundSetter applies to fields, so the confusion. a more global >> @DataBound to match them all would be a more generic mechanism >> >> >>> >>> (Yes you can use @DBS on a field, but this is poor style, since you >>> then lose control over data migration if someone in another plugin >>> accesses your field directly. Prefer to use it on a setter method, >>> with a matching getter method that need not be annotated.) >>> >> >> Question of style. I prefer to avoid setters to reduce code verbosity. Or >> Lombock style programming >> >> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
