> Am 13.07.2015 um 09:42 schrieb John Hewson <[email protected]>: > > >> 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.
The accessors are fine and are the primary API that should be used. If there is a setter/getter missing we should add that. If - for whatever reason - a users decides to use the COS level objects it's beneficial to have these values so one could use dictionary.setFlag. So the (only) use case it to allow using the COS level and have the values at hand with a readable name instead of numeric or string values. Maruan > > — 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
