Pierre van Rooden wrote:
> Michiel Meeuwissen wrote:
> >Since there is a Set getFunctions on Cloud you may also expect it on Node
> >and Module? (But, without argument then).
>
> Could be easily added.
>
> >Perhaps. But I deliberately did not choose 'contains' back then, because
> >the
> >interface already has a 'contains' method, which means something quite
> >different (does not look at the parameter definition, but at the parameter
> >value).
>
> It is similar to Map: containsKey(). Essentially the Parameter is a Key
> in Parameters. It follows the naming conventions used in these classes.
Well, yes. But Map does not also contain 'contains'.
> >I would have expected to more simple:
> >
> >public Function getFunction(String functionName) {
> > return parent.getFunction(this, functionName);
> > }
>
> And what would parent.getFunction(this, functionName) return?
Some function object containing 'this' Node (likely as a member).
> Likely a wrapped function (because you have to return a 'Function'
> object that takes the parameter 'node' into account).
I'm not sure what other function it needs to wrap then. I would rather
expect an extension of AbstractFunction? Perhaps an AbstractNodeFunction
would come in handy, which would provide that node-member. Of course, a
default implemetnation would call executeFunction...
Btw, why is FunctionProvider not an interface? Does it make sense that
MMTable extends from it? Does this not place functions in a more prominent
place that they deserve? (Hey, I would have prefered MMObjectBuilder extends
MMTable, FunctionProvider, but since that is not possible..).
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
