Hi, On 2/9/07, Stefan Guggisberg <[EMAIL PROTECTED]> wrote:
however, we should IMO be careful not to blindly sacrifice performance for cleaner code. a move operation could e.g. be modeled as a copy&delete, this might make sense from a design perspective, but not performance wise.
Agreed. The move vs copy&delete case is quite extreme, but even things like implementing Item.getAncestor(), Item.getPath(), or Item.getDepth() in terms of Item.getParent() are potential performance issues. There is however no stopping jackrabbit-core from extending the adapters and interfaces from the proposed generic solution to provide implementation-specific improvements for cases where performance gains are available. Thus I don't think the proposed solution introduces any design-induced performance issues that couldn't be easily avoided. As a general guideline I'd set the maximum allowed performance hit of the proposed layering to an extra one or two indirect calls per implemented method. If the performance hit seems worse, then we keep the current structure. BR, Jukka Zitting
