<div class="gmail_quote">On Thu, Jul 23, 2009 at 12:30 AM, Alaxander Smirnov <span dir="ltr"><<a href="mailto:asmirnov@exadel.com">asmirnov@exadel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A setter method 'void' return value is a part of the JavaBean contract. I guess that modification of the setter method pattern would also confuse many other Java Bean libraries like apache-beanutils, some EJB 3.x containers and so on. I do not think what an one JSR specification should violate any other, especially so wide used as JavaBeans are.</blockquote>
<div><br>I have always objected to the claim that getters and setters come from the JavaBean contract. That relationship is so loose one can only say that it is a van der Waals-like relationship. Okay, so we steal this idea of deriving a property from an object by removing get or set prefixes and lowercase the following letter, with the exception of a primitive boolean in which the is prefix is stripped as an alternative to get. The relationship to that specification then trails off into the ether.<br>
<br>The real spec that we are following is the yet undefined Java properties specification. What does it take for there to be a property? As Lincoln suggests, the return type on the setter should not be considered. Maybe even annotations can be used as an override of these defaults.<br>
<br>So the rules would be:<br><br>getter: a no arguments method whose name is formed by captializing the property name and prepending "get" with a return type equivalent to the property's type<br>setter: a single arguments method whose name is formed by captilizing the property name and prepending "set" and whose argument type is equivalent to the property's type (no restriction on return type)<br>
<br>Annotations, like in JAX-RS, can be used when these defaults are not sufficient for the class composition used by the application.<br><br>Btw: I think the who idea of the "is" prefix for primitive boolean types is half-assed and insufficient and should be supported only for backwards compatibility.<br>
<br>Lincoln, as far as I can tell what you are attempting to do is legal if you have JBoss EL loaded. JBoss EL is much more flexible about what is allowed and is hopefully a preview of EL 2.2.<br><br>-Dan<br></div></div><br clear="all">
<br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br>