On Sat, Dec 7, 2013 at 1:39 PM, Maruan Sahyoun <sahy...@fileaffairs.de>wrote:
> > > Question: Can we agree on how objects are instantiated. e.g. > Obj.getInstance(token) or new Obj(token) ... > I am not for using constructors, getInstance pattern looks better What about using a factory ? The idea is to be able to share stuffs between different objects, reducing footprint... why not having more final objects if possible. Using factory could also permit different policies in memory management. As an example, COSStream could be stored in memory or in temporary file depending on the configuration of the factory. > > This only makes sense if the objects themselves like pages or resources > can be fully cloned so that if objects are cloned or imported they no > longer have a dependency to the original object. This could benefit PDF > merging as one could close a no longer needed PDF. This will affect the > current PD Model I think. > > Question: Can we already clone, what needs to be done to fulfill that? > Could we do a importPage() so the imported one is completely independent > (and stored in memory or in a file based cache)? > As the parser parses the PDF I think about firing events e.g. to react on > malformed PDFs. I consider this to be a better approach than overwriting > methods or putting workarounds into the core code. > > > I think I could use the PDF Lexer e.g. to create an FDF parser to fix the > current importFDF() issues and maybe use that as a test suite for the > PDFLexer. > > > > What about setting up a sandbox to share some initial code wo cluttering > the current trunk. > > WDYT? > IMO, as the new parser will replace the old one, making it in a sand box could be a good idea without the constraint of a branch. The merge could be done in a branch when we will be close to the result. > > > BR > Maruan Sahyoun > >
