Hi, > > IMO it would be better if the number of child nodes is calculated > > by the caller. why do we have the method anyway? ;) > > The caller may well want to adapt it's functionality depending on > whether a node has 10 or 10M child nodes. > > >> Iterable<ChildNodeEntry> getChildNodeEntries(int offset, int length); > > > > doesn't this imply that the implementation will keep the child > > nodes in a list? > > Any implementation that supports orderable child nodes is necessarily > some form of a list.
that's correct. but an array list is just one way of doing it. you could also implement it as a linked list where index lookup is O(n). > The only extra bit here is that I'm expecting the implementation to be > able to use a numeric index instead of some other pointer to indicate > the starting point. That should be easily doable with most models of > persistence. Also, the current MicroKernel interface assumes that the > underlying storage model is able to use numeric indices. IMO this means it mandates two forms of child node look up: - by name - by index do we really need both? regards marcel > BR, > > Jukka Zitting
