Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dali-dev] Re: Dali naming convention for getter methods

> adding little to no value (since our code is not going to be
> introspected or modified by an external framework expecting get*/set*).

You guy seem to ignore that all developers using your api would use the 
same kind of "introspection" to find relevant properties to use....the example
below described by Tom is a good example.

Conventions are not only good for machines ;)

/max

> The Eclipse Platform and JDT and most other Eclipse projects do use the
> bean conventions, so we would be going against the grain if we went away
> from that.  I'm not sure if our project is the right place to buck this
> trend, but I suppose everything has to start somewhere.
>
> We should have some level of consistency within our own project, so that
> should be a goal regardless of where we end up.  So far that consistency
> has been moving away from get/set.  Unfortunately there isn't much time
> to make big changes at this point, so we probably need to focus on
> internal consistency as opposed to changing our conventions.
>
> Neil
>
>
> Tom Mutdosch wrote:
>> 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
> 





Back to the top