> On 13 Jul 2015, at 00:27, Maruan Sahyoun <[email protected]> wrote: > > >> Am 13.07.2015 um 08:55 schrieb John Hewson <[email protected]>: >> >> >>> On 12 Jul 2015, at 22:50, Maruan Sahyoun <[email protected]> wrote: >>> >>> >>>> Am 13.07.2015 um 03:18 schrieb John Hewson <[email protected]>: >>>> >>>> >>>>> On 12 Jul 2015, at 15:17, Maruan Sahyoun <[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>> there are some inconsistencies between the annotation package and the >>>>> form package how static final fields are handled. The classes in the >>>>> annotation package have these public. The classes in the form package >>>>> have these private or package private. I'd propose to make them public in >>>>> the form package. >>>> >>>> I thought the goal for 2.0 was to move from using integer constants to >>>> enums? >>> >>> Good point. Why not change the visibility first and if time permits move to >>> enums? ATM the AP issues for fields are more important. >> >> One reason not to change would be that once it’s public there’s no going >> back if we don’t move to enums before 2.0. > > yes, otoh it would leave us with the inconsitency between annotation and form > which is also not good
True, I suppose the question then is, should these fields be public at all? Given that we have PD accessors for the individual flags which they set, I think the answer is actually “no”. These are COS-level values which PD should hide. — John > Maruan > >> >> — John >> >>>> >>>> — John >>>> >>>>> Furthermore there are some minor differences between method names such as >>>>> setReadOnly() in annotation and setReadonly() in form which I'd like to >>>>> make consistent prior to 2.0.0 >>>> >>>> Yes, that definitely wants to be setReadOnly(). >>> >>> Will change it. >>> >>> BR >>> Maruan >>> >>>> >>>>> WDYT? >>>>> >>>>> BR >>>>> Maruan >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
