BTW, regarding the filter class, I have some more comments. I still<div>don't know if I can post the sample code I wrote at work yesterday, so</div><div>I'm just going to include my comments and leave the code out.</div>
<div><br></div><div><br></div><div><br></div><div><div> Looking at this class reminds me of something else: I generally prefer to</div><div>avoid concrete virtual classes in favor of interface-based inheritance. There</div>
<div>are a bunch of benefits to this; e.g., it usually gives you a conceptually cleaner</div><div>design, it makes it much easier to cut dependencies between components (for</div><div>testing, for instance), and it makes it a lot clearer exactly how two components</div>
<div>interact (instead of the slippery business of self-calls). This is different from</div><div>how traditional widget sets (like Qt) tend to work, but I think it's worth the</div><div>trouble to get the hang of this style of coding.</div>
<div><br></div><div> In this case, it looks to me like you have three things that are mixed together:</div><div> 1. The filter function.</div><div> 2. The name associated with the filter (always set when the filter is constructed</div>
<div> and never changed).</div><div> 3. A holder that allows the filter function to be modified to another filter that's</div><div> implemented by the same class and that emits a signal when it's changed.</div>
<div><br></div><div> Item (1) could be accomplished simply by having a member variable of type</div><div>boost::function<bool(Package *)>, or by using your own interface. Probably a</div><div>custom interface is a bit better? I would avoid Qt dependencies in the filter</div>
<div>interface (leaving aside Package), although obviously implementations could</div><div>rely on Qt objects. Filters should probably be immutable.</div><div><div><br></div><div> Item (2) confuses me -- what is the name for, exactly? If it's just the</div>
<div>name the user gave, why is it immutable? I'm going to assume that</div><div>was an oversight.</div><div><br></div><div> Item (3) can be handled at the same time as item (2), by creating</div><div>a separate "holder" class that represents the user's definition of the</div>
<div>filter and is modified when the definition is modified. This has the</div></div><div>extra advantage of letting you switch to any other filter, not just one</div><div>implemented by the same concrete class.</div><div>
<br></div><div> i.e., you would have "package_filter", which is an interface for predicates</div><div>on packages, and "package_filter_definition", which contains a name and a</div><div>package_filter (pointer), both of which have mutators, and which has two</div>
<div>signals corresponding to those fields, emitted when they change.</div><div><br></div><div> Daniel</div>
</div>