We like to stay young with a non-conformist attitude. : )
In an effort to clean up some of the inconsistency, we managed to come
up with a standard way of naming before the API is locked down for M6.
After some discussion, it seemed most reasonable to continue with the
Eclipse pattern in general. This might cause some breakages that can
be fixed by prefixing broken method references with "get".
-For single value accessors, we will use "get"
-In general, any method that returns the same object upon repeated
calls when asked will start with "get"
-For collections, we generally return an iterator (which probably
deserves an explanation as well), which often makes use of our iterator
utilities. These will not return the same object twice and will
therefore not start with get.
-java.lang.Boolean accessors will start with "get"
-boolean accessors will start with "is" where applicable or use the
best grammar available
Hopefully this will keep things consistent for everyone, which I
certainly favor. The changes will be in this weeks I-Build.
Neil
Max Rydahl Andersen wrote:
guys,
You are making me smile - I thouhght this were an old and dead discussion in java land ;)
You use getters and setters for accessor methods and you don't have setters if it is an immutable property.
Note: property is not necessarily maps directly to a field.
If you method does some action then "get" is optional and depends on the context, e.g. url.getInputStream()
is not just getting the property but is actually doing "something" (and inputStream is actually a derived/calculated property),
but having url.close(); return true/false is all okey.
I guess your #3+#4 is what get closest.
Hence .jpaProject() is really weird ;)
/max
Well, given the number of discussions about these "conventions" we've
had among ourselves over the last 7 or 8 years, there's no way we could
accuse you of being "smart-alecky" without being guilty ourselves. :-)
What you are suffering from is the manifestation of our group's indecision.
We have even been discussing this over the last few weeks, amongst ourselves,
as we try to clean up our public/provisional API.
I guess there are a number of options [discussion]:
1. Prefix the name of any method that returns a value with "get". [This fits
the JavaBean spec; but the JavaBean spec is of questionable value. This
doesn't quite mesh with "action" methods that return a value as a result
of the action - e.g. parse(), run(), calculate(). This allows code-assist
users to quickly find methods that return a value; assuming the users have
memorized method names such as hashCode() and iterator().]
2. Never prefix a method name with "get". [This eliminates the redundacy in
the name. This avoids making a decision as to whether a method is a "getter"
or an "action" the returns a value.]
3. Something we have done in a previous development effort:
Prefix the name of any true "getter" with "get"; i.e. any method
that simply returns the value of a field/instance variable is tagged
with a "get". [This feels closer to what the JavaBean spec seems to represent.
But the implementation is exposed a bit. And it doesn't really work with
interfaces. {We didn't have much need for many interfaces in the afore-
mentioned dev effort.} This causes problems when the implementation changes
though.]
4. Use "get" on any method that has a corresponding "set" method.
(Let's ignore the idea that maybe we don't need the "set" prefix
either. :-) We don't want to get the Smalltalk bigots involved.)
[I'm not sure of this idea - it's just what has recently crossed
my mind. :-) ]
Anyway, I'm just airing out some of our thoughts. Yours are welcome.
We haven't firmly decided anything, at the moment.
Thanks for your patience, Tom. :-)
Brian
-----Original Message-----
>From Tom Mutdosch <tommut@xxxxxxxxx>
Sent Tue 3/25/2008 2:53 PM
To General Dali EJB ORM developer discussion. <dali-dev@xxxxxxxxxxx>
Subject [dali-dev] Re: Dali naming convention for getter methods
Tom Mutdosch wrote:
Hi all,
One thing that I've noticed -- and this may be a silly question -- but
is there some particular strategy or code style guideline used to
determine which API getters start with "get" or not? Example:
jpaProject(), jpaFile(), etc, instead of getJpaProject()? This gets
really confusing when using code assist, as my default behavior is to
type "get" and then look for all the related getters. Of course, I
don't see any. I then have to hunt up and down the entire list of
methods looking for any methods that may be what I need. This also
makes it hard to determine which methods are returning results, versus
which are performing an action (Example: PersistentType.dataSource()
versus PesistentType.update()). It probably would be less of an issue
if this convention was used everywhere, but a lot of times there are
getters that start with "get" provided by parent classes, so in the
method hierarchy you actually do see both getters that start with
"get" and those that don't, which confuses matters even more. Again,
this is not a big deal; it just always causes me momentarily
confusion. I figured there was a reason, so was just curious why the
normal "get" convention is not generally used. :)
Thanks
Tom
Hi guys,
I realize that my question may have come off smart-alecy when I
originally asked about the naming convention for getter methods, so my
apologies. I actually was just genuinely curious about the convention,
as I know that eclipse and WTP often utilize conventions that eventually
filter on down to other developers like myself. I just didn't know if
it was as simple as "all the API are essentially getters, so a 'get'
prefix is redundant" or if there were other factors. I really don't
mind; was just interested from a fellow developer standpoint.
-Tom
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
|
