Johannes Brunen wrote: > Hello Carsten, > Actually, I did build such a core, but I'm not satisfied with the result > for several reasons. > > At first, the interface is less flexible than using a bitfield. You > have, for instance, to clear the whole multi field and rebuild it in > order to switch to another set of nodes.
You could perhaps add a convenience function allowing one to select a subset of the first 32 (or 64) nodes using bit values, which internally still uses the mfchoices approach? > In addition handling the > selection of the child nodes with their particular index is also only > feasible for small numbers of nodes. Doesn't Node have an getIndexOfChild() or something similar? > Second, for efficience reasons. Using a multi field does imply testing > for each entry to the multi field. This is efficient only for a small > size. However, then I'm fine with the bitfield implementation. If the > size is growing some kind of sorting is inevitable. This however, > inefficient for itself. Have you considered sorting the mfchoices field in the changed() method? > At last, using the bitfield design I got the corner cases if NONE and > ALL for free. Using the multi field approach, however, does imply an > additional field plus interface. Could perhaps be implemented as the first index of the choices field being -1 or -2? Or perhaps this is just to complex so that it warrants two types of select-cores? (or three, since we have switch as well) Cheers, /Marcus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
