On 22 Oct 1998, Lars Gullik Bj�nnes wrote:
> I can't see why this is so bad? Unless we want to change internal
> structure every week...
When we start to change seriously the internal structure, we will be doing
changes several times a week (we have done things like that), at least for
a while. That should not affect the file format.
> I am not able to see this having any implictions for the fileformat...
We would not need to map the internal buffer structure. Moreover using
(well designed) iterators would clean big slices of the code cake and it
would be much more understable and maintainable, IMO.
> 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.
Modification, insertion, searching, replacing, etc.
> We might even be able to use iterators easily for writing, bur for
> reading I think not. (you have nothing to iterate over)
Maybe it's the simplest case; while reading and feeding with data a new
buffer, you have the iterator moving always at the end of the container.
What is important is that the parser should not have direct access to the
data. This way would be substantially easier in the future to implement
filters or plugins to import different document structure language
formats, or simply modify our file format according to new requirements.
Just think on how much code we would have to modify if we change the
internal structure right now. With iterators acting as the interface, to
the external clients (writer, parser, cursor, screen, etc) it's not
important the internal, hidden, buffer structure.
I'm not trying to claim that mathed is the perfect model to follow for
the internal buffer structure (after all I wrote it almost 3 years ago).
But part of the idea is rougly there, and it seems to work, isn't it?
Alejandro
