ghudson@tigris.org writes:
> I feel like our edit_fns interface now has "too much rope."
> dir_batons are now redundant (there is only one allowable value for
> the dir_baton argument for any call which takes one), and there is no
> explicit call made when a text delta is being deferred to the end of
> the call sequence. In general, the tree structure of an editing
> operation is enforced through documentation rather than through the
> interface, and it doesn't have to be that way. However, I don't feel
> comfortable unilaterally instituting a major design change at the
> moment, so for the moment I am just documenting the restrictions on
> the call sequence.
There's more than just documentation enforcing the tree structure of
the call sequence: there's the fact that the dir and file batons
values must be obtained before further ("descending") calls can be
made.
That's why the dir batons aren't redundant (IMHO) -- parents need to
pass certain information to their children, and the user of the editor
cannot know the nature of this information. Therefore, obtaining a
baton and passing it along blindly seems to be a very natural way to
do things.
(Clearly, there might be other ways to arrange all this; I'm not
trying to convince you to change your tastes or anything. But I think
the interface does in fact have the properties you say you want.)
Received on Sat Oct 21 14:36:09 2006