On Sun, 27 Feb 2005 23:15:00 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
<snip />
> The simple fact that we have to elaborate such strategies IMO reveals
> that there's a problem. This problem comes from the fact that a dynamic
> property space (request parameters, map entries, etc) is merged with a
> static property space (coming from the Java object), and that's why I
> proposed an additional static property to hold the dynamic space.
>
> In the case of request, this leads to both "request.parameters" and
> "request.attributes" as we have two dynamic property spaces.
>
> In the case of Map, this could be "map.entries", i.e. you would write
> "map.entries.foo" instead of map.get("foo"). But we can also consider
> that Map is of a special kind as it is nothing but a dynamic property
> space for Java. In that very particular case, we could reverse the
> scheme and have the dynamic space be the main property space (i.e.
> "map.foo") and have the actual Map methods be accessed through a single
> special property, e.g. "map.__obj__.size()". Mmmh...
I really like the dynamic property spaces for request attributes in
parameters, but when talking about a Map, honestly, I don't think
there is a clean solution. The former ".entries" idea is even more
verbose than the regular get() method, and the latter strategy is
similar to the "fn_" prefix but with the additional (admittedly
infrequent) problem of retrieving a property called "__obj__", not to
mention being more difficult to access extended properties and
functions.
>
> >That said, this is not an issue for the wrapper around List.
> >
>
> Yes, because a List's dynamic property space is defined by numbers (the
> index), and there is therefore no overlapping between the regular
> object's properties and the ones added by the special wrapper.
>
> >I wrote
> >a framework so you can add properties and methods to Java API's in a
> >generic way, and I use this to, among other things, add a "length"
> >property to any object that implements Collection to make it more
> >consistant with what one would expect to use with a JS array. My
> >favorite use of extension functions is to add closure functions such
> >as File.eachLine(func).
> >
> >
>
> That's groovy, in all meanings of it ;-)
Indeed as that was the inspiration - wanting the nice Java integration
and extensions of Groovy but with a mature, continuations-capable
scripting language. As I mentioned, I'm writing this keeping it clean
of Struts and chain constructs so it could be used in Cocoon if you
folks were interested, by moving it to a commons project.
Don
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
