>> Alejandro Aguilar Sierra writes:
[...]
AAS> This is precisely the idea I disagree with. Matthias wrote his
AAS> original LyX format with that idea in mind, a good temporary
AAS> solution. Actually it's not true that an exact direct mapping
AAS> of the buffer structure guarantees an easier parsing and
AAS> writting. On the contrary, it forces an unnecessary dependence
AAS> between the internal buffer structure and the file format.
I can't see why this is so bad? Unless we want to change internal
structure every week...
AAS> I think a better approach is this:
AAS> - Using STL words, the buffer structure is ultimately a
AAS> container that holds the document's data. The STL way to have
AAS> access to such data, either to get it or to modify it, is by
AAS> iterators.
AAS> - When using an iterator you don't know the internal structure
AAS> of the container, you only use the iterator's methods that let
AAS> you do whatever you want to do with the data.
AAS> - We can have a set of iterators, depending on what we want to
AAS> do with the data. To parse and write, an even to draw on
AAS> screen, a secuential iterator is good. To edit the buffer, we
AAS> need an iterator that can be moved randomly (like the cursor).
AAS> This is rougly my idea about the subject, and nearly what I
AAS> wanted to do with mathed, though in a rudimentary way (there
AAS> was not STL yet).
I am not able to see this having any implictions for the fileformat...
And: reading and writing of containers are special cases, what is
really interesting is modification and insertion, and for that we will
have iterator like objects.
We might even be able to use iterators easily for writing, bur for
reading I think not. (you have nothing to iterate over)
Lgb
