> So, subclassing doesn't seem to be the solution. > > Another issue is that it seems to be quite difficult to insert a > custom marker mid-way into a component's > startup/destruction phase. > I know this one won't come up as often as the others > above, but as an > example Lief had this problem supporting the Instrumentable > marker interface. > > I think we still need a way to ensure the defined order of the > standard avalon startup/destruction interfaces, but it could be > useful to include the ability to insert custom ones during > component startup (or should we consider the startup/destruction > process to be immutable ?). > > I've taken a look at both the ECM/ECS and Fortress > code, but both > don't seem to cover this space just yet (?). I'm > looking for ideas > about how to add such functionality to our existing classes that > doesn't require excessive subclassing of handlers or component > managers. > > Any ideas ? thoughts ?
I would suggest a generic solution instead of an objectoriented one (callbacks instead of subclasses ;-). So a component manager would have a list of callbacks for lookup and one for release. These callbacks would get the component as a parameter. This would even give nice ways to do very flexible things (e.g. via anonymous classes as callbacks :-). The cm would need methods to - register a callback for lookup, - deregister a callback for lookup, - register a callback for release and - deregister a callback for release. The methods lookup and release would simply iterate over their list and execute all the callbacks. For easier management the callbacks should have a method that returns their name. So everybody could ask for a list of the names of the callbacks. And a new callback could be inserted at the right position in the list. Regards, Ole -- Ole Bulbuk Tel.: 0331/74759/60 Ernst Basler + Partner Fax: 0331/74759/90 Tuchmacherstr. 47 E-Mail: mailto:[EMAIL PROTECTED] 14482 Potsdam WWW: http://www.ebp.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>