> Am 13.07.2015 um 09:42 schrieb John Hewson <j...@jahewson.com>: > > >> On 13 Jul 2015, at 00:27, Maruan Sahyoun <sahy...@fileaffairs.de> wrote: >> >> >>> Am 13.07.2015 um 08:55 schrieb John Hewson <j...@jahewson.com>: >>> >>> >>>> On 12 Jul 2015, at 22:50, Maruan Sahyoun <sahy...@fileaffairs.de> wrote: >>>> >>>> >>>>> Am 13.07.2015 um 03:18 schrieb John Hewson <j...@jahewson.com>: >>>>> >>>>> >>>>>> On 12 Jul 2015, at 15:17, Maruan Sahyoun <sahy...@fileaffairs.de> 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: dev-unsubscr...@pdfbox.apache.org >>>>>> For additional commands, e-mail: dev-h...@pdfbox.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org >>>>> For additional commands, e-mail: dev-h...@pdfbox.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org >>>> For additional commands, e-mail: dev-h...@pdfbox.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org >>> For additional commands, e-mail: dev-h...@pdfbox.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org >> For additional commands, e-mail: dev-h...@pdfbox.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: dev-h...@pdfbox.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
