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..
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
[EMAIL PROTECTED]
+1-203-247-1713
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
