Rob van Maris wrote:
> In addition, using a wrapper class, the demands of (for instance) EL
> can be met much better than by extending Node. E.g. with node extending
> Map it will be impossible to retreive a field named "cloud", since
> ${node.cloud} always evaluates to node.getCloud() instead of
> node.get("cloud").
Really? Would El not firstly decide that it is a Map, and therefore conclude
that it should use the second version?
> >The other issue is, is that Maps can be editable, and a Node can not
> >be.
> FYI, this is not correct. Maps are can be non-editable as well, in
> which case some of its methods are expected to throw a
> UnsupportedOperationException. See the Map apidoc for details.
I think you misread me, I did not say that Maps must be editable, only that
they _can_ be editable (which grantedly is close to a trueism, but
nevertheless what I said). This is in contradiction to Nodes. Which to me
was an extra argument that Node should not be Map, because we would have an
interface which methods which _must_ be unsupported, which stroke me as
rather odd, undesirable, and perhaps even contradictional.
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
