On Fri, 15 Mar 2002, Andre Poenitz wrote: > My point is: > > THERE IS NO NEED TO STORE REFERENCES TO BUFFERWIDE DATA IN THE INSET.
Yes, maybe the bibliographic entry is a string, and just that. However, the semantics of this string is defined by the buffer wide database, and in some cases, this can be relevant to have, in order to for instance display the inset in a more intelligent way that just the string. Also, it could be relevant for an inset to access this database for other reasons. Suppose that it wants to present a dialog with all the keys in the database. Then it has to know the buffer, or the database, or something. Now, please do not explain how you want to solve this problem once more. I understand perfectly well how you want to solve this problem with the top-down approach. I'm just saying once more: We have the need for leaves to acces information higher in the tree. Can we agree on that? Your approach requires impose this need of information into the source code by threading all the methods down to the leaves in the data-structure. With the other approach, you do not need to do this. Well, I guess you understand this, and we simply disagree. > Whenever something "interesting" should happen (like looking whether this > key exists in some .bib file), the function gets passed a ref to the > file/database/whatever. You do not need to explain how it could work in a one-way system again and again. I understand how it could work, and have all the way in the discussion. I am not disputing that it would not work. I just think that it's a suboptimal design, because it skews the responsibility, and complicates the code. > It is the job of every inset to pass down to its children stuff it can't > handle by itself... This structure implies that each inset has to know what N kinds of insets needs. The other way, each inset only needs to know how to handle it's own business. I think maybe you overestimate the amount of work involved in keeping back-links alive. It is really no big deal, and IMO it gives you better code and more possibilities. Well, it's Friday, so I suppose it's allowed to keep this discussion going for hours. I just wish it could take a turn at some point. Can we agree to switch sides at 16.00, and then suddenly turn around on a plate, and argue the other part's case? Greets, Asger
