> The whole problem with all of this is that you are going down the discussion > path of inventing a programming language...ie: what JEXL is trying to do by > implementing the spec of a programming language. > > All of what you want to do can already be done in Java and pushed into the > context. No need to enable it in Velocity. It is not always possible to put things into the context. Like some code generation tool: metadata -> tool-> Velocity templates -> generated code. Templates can be customized, but not a "tool". Some tools have "high level" API and context stuff is private API. See http://sourceforge.net/projects/strutsgenerator/ or http://www.gentleware.com/products/index.php3 for realistic examples. > > -jon > > on 2002/8/31 5:43 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > On 8/30/02 8:47 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote: > > > >> Daniel Rall <[EMAIL PROTECTED]> writes: > >> > >>> "Juozas Baliuka" <[EMAIL PROTECTED]> writes: > >>> > >>>> $myMap[ "key" ] > >>>> $myMap[ $var ] > >>> > >>> This array index syntax is not supported, as the $myMap object is not > >>> an Array object. > >> > >> Being very familiar with Perl and Python, I realize that other > >> languages do support this sort of syntax for hash lookups. As > >> Velocity is quite Java-centric and has so far explicitly avoided > >> anything resembling Perl, I wouldn't really be in favor of adding > >> anything like that, either. > > > > This is supported in Jexl, as I was thinking of proposing it here. ECMA > > script seems to require the equivalence of > > > > > > a.b and a[b] > > > > > > which to me is mind-bendingly weird as I see structural semantics behind "." > > and "[]" You can do things like > > > > foo.1 > > > > Where foo is an array... I have to have it in Jexl for compliance with > > JSTL's EL (not that Jexl is 100% compliant yet...)... > > > > Anyway, I can make a good argument (to myself anyway) that this fits with > > the notion of 'introspective polymorphism', the idea that class doesn't > > matter when you say > > > > $foo.bar > > > > to be able to be calling either getBar() or get("bar") and be able to > > switch the object in the context freely. > > > > This . == [] would take that one step further. > > > > However, I keep coming back to wondering if we can avoid adding [] and still > > have the functionality (less syntax is more...), but then we get to things > > like > > > > $foo.$bar > > > > (cue Jon : "This isn't Perl") to have the same functionality as > > > > $foo[$bar] > > > > > > I actually wouldn't personally mind an array accessor, as the problem of > > accessing out of bounds, which we already have with array lists : > > > > > > #set($foo = [1,2,3,4]) > > > > $foo.get(123) > > > > > > wouldn't be a new thing. > > > > Off to coffee.. > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
