With methods... one could say object.do() (and do OO) as oposed to
do(Object). The guide line for OO is noun.verb().
I wish it was methods.
Shawn Bayern wrote:
> On Tue, 15 Oct 2002, James Cook wrote:
>
>
>>I wonder why the unnecessary complication here? If they are going to
>>use reflection anyway, why subject the users to creating these extra
>>xml fragments. A nickname hardly seems worth it, and adding another
>>point where a slight syntax problem in an XML document can cause
>>additional time deploying and debugging seems pointless.
>>
>>I hope they see the light and allow EL to invoke _any_ method
>>(including non-static) on beans that are exposed in a scoped context,
>>ala Velocity, et al
>
>
> The definition of functions instead of methods was the subject of a lot of
> debate. While you're right to point out that it's a little more
> complicated for the developer who's defining the functions, the hope was
> that it would ultimately be easier for page authors and that it would
> facilitate good application design. Functions can abstract data types,
> while allowing method calls from the EL specifically avoids this
> abstraction. If you have pages that use expressions like
>
> ${myList.size()}
>
> then you can't easily change the data type of 'myList' from, say, a List
> to an array. However, if we provide a standard 'size' function, then page
> authors can write
>
> ${size(myList)}
>
> without worrying how 'myList' is implemented.
>
> Moreover, it would be poor practice to encourage the use of methods with
> side effects; if we allowed all method calls, we'd simply be reintroducing
> scriptlets with a different syntax.
>
> Still, the topic is not one on which everyone agrees; functions do seem
> safest for the moment, however.
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
