Pierre van Rooden wrote: > >It's only when you want something else which is not aware of MMBase to do > >something with nodes, then you would want it as a Map, for which I figured > >this wrapper would be ideal. > > But one of the uses of the bridge is to allow outside programs to use > it. And having Nodes behave as Maps would make that a lot easier. > Having to make a wrapper for it sounds cumbersome too, imo. > What do other people think? Worth a vote?
The other issue is, is that Maps can be editable, and a Node can not be. Well, its values can, but you can never remove keys. If that would be impelented, that would be much more logical on NodeManager. So, the only sensible thing to do for the methods 'remove' and 'removeAll' would be to throw an UnssuportedOperationException, which is allowed according to the contract of Map, but it would become a bit silly if no other implementations are possible. For the wrapper that is no issue, because it simply is 'a' Map implementation, which _may_ be non modifiable, while those methods in the Node interface would have to state that they _must_ throw an exception. Another interesting one is 'entryList', which is the only method from Map really missing in bridge, but one would certainly expect a more bridge-like name when in Node. Something like fieldValueList(). The counterpart of Map.Entry of course being FieldValue. I think the idea was to offer the complete bridge api to outside programs? I mean, not one single object, in the hope that it could be handle genericly. Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
