rbmetacode-list

[RBMetacode] Need some code design help

[Thomas T. <tt...@te...>]

So, you know, I'm working on this editor...

It can now open a RB file (binary only so far), load it into a tree that
consists of classes representing the different types (module, class,
control, method, property etc.), most of which have common properties (a
name or label, parent and children) while some have special properties
(source code, method declaration, variable declaration, note, icon, external
file reference and so on). Saving works as well, of course.

The editor provides an interface that looks similar to the RB IDE, where the
user can already edit source and declarations.

Now I like to add Find & Replace functionality and I am looking for
suggestions on how to do this best.

To search, I need to iterate over all items. Currently, not every text item
of interest has its own node in the tree. Instead, as explained above, the
name/label is a property of any node's base class, and some classes have
accessor methods for reading and settings source, declaration and notes.

To iterate over these, I'd currently have to iterate over the nodes, then
add special handling for the special properties. But how would the iterator
remember where it's at? If I code it so that it uses a callback (delegate)
function to handle the finding, it would implicitly remember where it's at,
but what if the callback function decides to alter the tree so that the
iteration loop is now working on obsolete items?

Therefore, I believe it's better to have a "smarter" iterator that one calls
from one's own loop, getting the next found item, then process this item,
then proceed in the loop to get the next item from the iterator. But then,
the iterator has to know where it's at. See the problem?

So, one problem might be to change my tree design so that every item,
including the source, declaration and name, are tree nodes as well. Then the
iterator has to deal only with remembering nodes.

Would that be the best solution or are there other approaches that come to
mind?

Thomas

Re: [RBMetacode] Need some code design help

[Joe S. <jo...@st...>]

On Mar 14, 2008, at 8:38 AM, Thomas Tempelmann wrote:

> Now I like to add Find & Replace functionality and I am looking for
> suggestions on how to do this best.
>
> To search, I need to iterate over all items. Currently, not every  
> text item
> of interest has its own node in the tree. Instead, as explained  
> above, the
> name/label is a property of any node's base class, and some classes  
> have
> accessor methods for reading and settings source, declaration and  
> notes.
>
> To iterate over these, I'd currently have to iterate over the  
> nodes, then
> add special handling for the special properties. But how would the  
> iterator
> remember where it's at? If I code it so that it uses a callback  
> (delegate)
> function to handle the finding, it would implicitly remember where  
> it's at,
> but what if the callback function decides to alter the tree so that  
> the
> iteration loop is now working on obsolete items?
>
> Therefore, I believe it's better to have a "smarter" iterator that  
> one calls
> from one's own loop, getting the next found item, then process this  
> item,
> then proceed in the loop to get the next item from the iterator.  
> But then,
> the iterator has to know where it's at. See the problem?

If I understand you properly, I think the find/replace functionality  
should be a visitor (see SyntaxVisitor and its subclasses in  
ParserProto for an example).  And to avoid the problem of the tree  
changing while you're traversing it, do it in two stages: first,  
gather a list of all the matches; and second (if the user wants to  
replace all without seeing them first), do the replacements.

HTH,
- Joe

Re: [RBMetacode] Need some code design help

[Thomas T. <tt...@te...>]

On 14.03.2008 16:11 Uhr, "Joe Strout" <jo...@st...> wrote:

> If I understand you properly, I think the find/replace functionality
> should be a visitor

Ah, thanks. This concept was new to me but I guess I had something like this
in mind, but not as sophisticated. I'm now reading up on this design pattern
to see what I can make of it.

Thomas