Re: The new GEDCOM parser

I think you missed my point: The parser's job should not be to store 
anything in memory. You deal with all the nitty-gritty of handling 
different formats, understanding the grammar, etc, then provide a rich 
set of callbacks so a client can implement whatever they need on top of 
it. Parser != model.


Jeremy


On 11/6/2012 12:14 AM, Ron Savage wrote:
> Hi Jeremy
>
> On 06/11/12 17:54, Jeremy Slade wrote:
>> You seem to be mixing two paradigms here: a stream parsing engine
>> (having all the callbacks per entity) and a document model builder. I
>> recommend to focus on making a solid GEDCOM stream parser (handling
>> UTF-8, well-defined grammar). There are many applications that don't
>> need to hold all the data in memory.
>>
>> Once you have a solid *parser*, it's another matter to build object
>> models on top of that. The parser is universal functionality. Defining a
>> single object model that all consumers will be happy with is an
>> impossible task, so you'll be much better served in separating them.
>
> Agreed.
>
> I've tried to clarify that with my last post:
>
> > I should say that I think storing a GEDCOM file's content, sort of
> > literally, in a tree ought to work, because of the nested nature of
> > the defined structure of such file.
> >
> > Creating another data structure to represent the linkage between
> > people, etc will be a separate issue.
>