> On 13 Jul 2015, at 00:57, Maruan Sahyoun <[email protected]> wrote: > > >> 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.
That reason would apply to any COS API though and we know that’s not the purpose of PD. There’s simply isn’t a need for these flags to be public in PD, it’s just a source of confusion. e.g. the user on the mailing list thinks they need these flags to be public to work with forms - but they don’t. I think that proves my point. Keeping flags private is a pretty common pattern in PD, for example PDFontDescriptor does this too. It seems to be that the inconsistency is actually with annotations, they should be providing public accessors (or enums) in PD for the flags e.g. isXYZ(), instead of using integer constants. — John > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
