On Fri, 16 May 1997, Duncan Simpson wrote:
> Why? I fail to see the need, unless somewhere wants a list of references
> refered to in the buffer. I can not see any application of such a list which
> is not infrequent enough to make scanning the document an acceptable
> alternative.
Do not take that literally. I agree that it's ok to scan the document
to obtain these lists. The point is that it's the buffer that provides
the entry-point to this information. Whether it calculates them on
the fly or not is not really the issue.
The issue is that it's only the buffer that can provide the information.
> Which inset needs this information?
The insets need information like this in many situations, not only when
rendering on the screen. When you open the TOC inset, you get a dialog
filled with information about the entire document.
When you export the TOC inset in ASCII, it would be great if it provided
the same information.
When you click on a reference inset, it would be great if the dialog
provided a list of all the potential targets for the reference.
And so on, and so on. A lot of times, insets can make good use of
information from other parts of the data structure.
So, by now it is clear that insets can make good use of this
information, not only when drawing, but in other situations
as well.
This is exactly why I think threading is a bad solution, because you
will be threading many methods, and in some cases, it's suboptimal to
have to go from the top and down the data-structure.
I.e. when you see this:
class Foo {
public:
Foo();
void bar1(Parent *);
void bar2(Parent *);
void bar3(Parent *);
void bar4(Parent *);
};
I think it's a clear sign that you need to consider
class Foo {
public:
Foo(Parent *);
void bar1();
void bar2();
void bar3();
void bar4();
private:
Parent * parent;
};
Now, the best way to settle this discussion would be to go to the
existing code, because it serves as the definition point of what
problem we need to solve.
In other words, how many methods have currently a Parent-pointer
of some kind, and how many insets cheat by using the current_view,
or some other global variable.
In principle, such a data-flow analysis could settle this question:
We should inspect all the methods of the insets, and have a look
at how they get the information from the higher levels of the
tree they need, and what they use it for.
Based on this, decide whether threading as in functional programming,
or maintaining a double-linked data-structure wins.
Regarding the relation between OO, functional programming and
parallel programming: In general, you can not say which method
is the best. Each approach has pros and cons, and sometimes one
is better than the other. In other cases, either is good.
In this case, I think it is better to do the OO thing, but any
other approach could work.
Greets,
Asger
