[lang] this.foo() vs. foo()

[Gary Gregory <gg...@seagullsoftware.com>]

Hello:

This could be a religious issue... look out!

In our product code bases, we use the "this.foo()" convention. The
argument being, that in object oriented programming, a message is sent
to an object, always.

How does the list feel about cleaning up foo()'s to this.foo()'s?

I am willing to do this clean up, actually, I'll let Eclipse do it ;)

Or, we can leave it all as is, with some classes doing it one way and
others the other way.

Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] this.foo() vs. foo()

[Torsten Curdt <tc...@apache.org>]

> This could be a religious issue... look out!

yepp

> In our product code bases, we use the "this.foo()" convention. The
> argument being, that in object oriented programming, a message is sent
> to an object, always.
>
> How does the list feel about cleaning up foo()'s to this.foo()'s?

hate it :)

cheers
--
Torsten

Re: [lang] this.foo() vs. foo()

[Craig McClanahan <cr...@apache.org>]

On 3/7/06, Sandy McArthur <sa...@apache.org> wrote:
>
> On 3/7/06, Gary Gregory <gg...@seagullsoftware.com> wrote:
> > In our product code bases, we use the "this.foo()" convention. The
> > argument being, that in object oriented programming, a message is sent
> > to an object, always.
> >
> > How does the list feel about cleaning up foo()'s to this.foo()'s?
> >
> > I am willing to do this clean up, actually, I'll let Eclipse do it ;)
> >
> > Or, we can leave it all as is, with some classes doing it one way and
> > others the other way.
>
> My position is that as you're working on a chunk of code, clean it up
> to whatever you like but DO NOT go changing code just for cosmetic
> sake.


I would look at it slightly differently.

One of the first principles I learned about open source development was that
if I proposed a patch, I should conform to the local style of the code I am
patching, no matter what my personal preferences might be ... advice that I
still think is appropriate for today.

If the committers want to focus on stylistic conformance codebase-wide
that's fine (but I try to stand well back from such conversations :-) --
and, if that means changes to existing code, it's preferable that ONLY the
cosmetic changes be done at that point.  Mixing functional and cosmetic
changes makes it much harder to review things.

--
> Sandy McArthur


Craig

Re: [lang] this.foo() vs. foo()

[Sandy McArthur <sa...@gmail.com>]

On 3/7/06, Phil Steitz <ph...@gmail.com> wrote:
> On 3/7/06, Phil Steitz <ph...@gmail.com> wrote:
> > On 3/7/06, Sandy McArthur <sa...@apache.org> wrote:
> > > On 3/7/06, Gary Gregory <gg...@seagullsoftware.com> wrote:
> > > > In our product code bases, we use the "this.foo()" convention. The
> > > > argument being, that in object oriented programming, a message is sent
> > > > to an object, always.
> > > >
> > > > How does the list feel about cleaning up foo()'s to this.foo()'s?
> > > >
> > > > I am willing to do this clean up, actually, I'll let Eclipse do it ;)
> > > >
> > > > Or, we can leave it all as is, with some classes doing it one way and
> > > > others the other way.
> > >
> > > My position is that as you're working on a chunk of code, clean it up
> > > to whatever you like but DO NOT go changing code just for cosmetic
> > > sake.
> > >
> >
> > Phil says +1 to the remark above.  Of course you could tell it is Phil
> > speaking by the from header and the sig below ;-)
> >
> > Phil
>
> Seriously, Craig makes an important point as does Gary (about the code
> being public).  I should not have responded categorically.  I
> personally do not agree in this case, but agree that style changes are
> OK if community (meaning those actually maintaining the code base)
> agree.
>
> Phil

I don't think there should ever be a sweeping code reformat if for no
other reason than it obscures how recently a block of code has been
reviewed by `svn blame`. I try to make commits that only change lines
that I've thought about and will own up to regardles if they end up
being good or bad.

Back to the original post, my preference is against "this.foo()"
because I'd bet the compiler generates more bytecode for the "this."
and because it doesn't really add anything unless you are using a text
editor without syntax highlight and other built in Java intelligence.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] this.foo() vs. foo()

[Phil Steitz <ph...@gmail.com>]

On 3/7/06, Phil Steitz <ph...@gmail.com> wrote:
> On 3/7/06, Sandy McArthur <sa...@apache.org> wrote:
> > On 3/7/06, Gary Gregory <gg...@seagullsoftware.com> wrote:
> > > In our product code bases, we use the "this.foo()" convention. The
> > > argument being, that in object oriented programming, a message is sent
> > > to an object, always.
> > >
> > > How does the list feel about cleaning up foo()'s to this.foo()'s?
> > >
> > > I am willing to do this clean up, actually, I'll let Eclipse do it ;)
> > >
> > > Or, we can leave it all as is, with some classes doing it one way and
> > > others the other way.
> >
> > My position is that as you're working on a chunk of code, clean it up
> > to whatever you like but DO NOT go changing code just for cosmetic
> > sake.
> >
>
> Phil says +1 to the remark above.  Of course you could tell it is Phil
> speaking by the from header and the sig below ;-)
>
> Phil

Seriously, Craig makes an important point as does Gary (about the code
being public).  I should not have responded categorically.  I
personally do not agree in this case, but agree that style changes are
OK if community (meaning those actually maintaining the code base)
agree.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] this.foo() vs. foo()

[Phil Steitz <ph...@gmail.com>]

On 3/7/06, Sandy McArthur <sa...@apache.org> wrote:
> On 3/7/06, Gary Gregory <gg...@seagullsoftware.com> wrote:
> > In our product code bases, we use the "this.foo()" convention. The
> > argument being, that in object oriented programming, a message is sent
> > to an object, always.
> >
> > How does the list feel about cleaning up foo()'s to this.foo()'s?
> >
> > I am willing to do this clean up, actually, I'll let Eclipse do it ;)
> >
> > Or, we can leave it all as is, with some classes doing it one way and
> > others the other way.
>
> My position is that as you're working on a chunk of code, clean it up
> to whatever you like but DO NOT go changing code just for cosmetic
> sake.
>

Phil says +1 to the remark above.  Of course you could tell it is Phil
speaking by the from header and the sig below ;-)

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] this.foo() vs. foo()

[Sandy McArthur <sa...@apache.org>]

On 3/7/06, Gary Gregory <gg...@seagullsoftware.com> wrote:
> In our product code bases, we use the "this.foo()" convention. The
> argument being, that in object oriented programming, a message is sent
> to an object, always.
>
> How does the list feel about cleaning up foo()'s to this.foo()'s?
>
> I am willing to do this clean up, actually, I'll let Eclipse do it ;)
>
> Or, we can leave it all as is, with some classes doing it one way and
> others the other way.

My position is that as you're working on a chunk of code, clean it up
to whatever you like but DO NOT go changing code just for cosmetic
sake.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] this.foo() vs. foo()

[Torsten Curdt <tc...@apache.org>]

On 08.03.2006, at 11:17, Henri Yandell wrote:

> On 3/7/06, Gary Gregory <gg...@seagullsoftware.com> wrote:
>> Hello:
>>
>> This could be a religious issue... look out!
>>
>> In our product code bases, we use the "this.foo()" convention. The
>> argument being, that in object oriented programming, a message is  
>> sent
>> to an object, always.
>>
>> How does the list feel about cleaning up foo()'s to this.foo()'s?
>
> For the same reason I'm against mindless javadoc:

Could not agree more - see my old blog

http://vafer.org/blog/tcurdt/archives/000183.html

cheers
--
Torsten

Re: [lang] this.foo() vs. foo()

[Henri Yandell <fl...@gmail.com>]

On 3/7/06, Gary Gregory <gg...@seagullsoftware.com> wrote:
> Hello:
>
> This could be a religious issue... look out!
>
> In our product code bases, we use the "this.foo()" convention. The
> argument being, that in object oriented programming, a message is sent
> to an object, always.
>
> How does the list feel about cleaning up foo()'s to this.foo()'s?

For the same reason I'm against mindless javadoc:

/**
 * Gets the name
 *
 * @return the name
 */
public String getName() {
    return this.name;
}

I'm also against this.foo() everywhere - it's non-useful noise for the
sake of being right.

----------

However, with Java 1.5 the addition of static imports has given us a
reason to want to use it.

this.name() clearly states that it is on this class; while name()
might be pulled from another class.

If I was forced to use static imports (which generally I'm avoiding
like the plague), the above might be a tempting convention as it would
have a use.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] this.foo() vs. foo()

[James Ring <sj...@jdns.org>]

Hi Gary,

On Wednesday 08 March 2006 10:35, Gary Gregory wrote:
> Hello:
>
> This could be a religious issue... look out!
>
> In our product code bases, we use the "this.foo()" convention. The
> argument being, that in object oriented programming, a message is sent
> to an object, always.

Will this.foo() and foo() always result in the same behaviour, particularly 
when you're dealing with overridden methods? I ask because I am unsure!

> How does the list feel about cleaning up foo()'s to this.foo()'s?

I personally think that foo() is just fine, especially when calling private 
helper methods.

> I am willing to do this clean up, actually, I'll let Eclipse do it ;)
>
> Or, we can leave it all as is, with some classes doing it one way and
> others the other way.

My (unimportant, meaningless ;) vote is to leave it.

> Gary

Regards,
James

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [lang] this.foo() vs. foo()

["Noel J. Bergman" <no...@devtech.com>]

> How does the list feel about cleaning up foo()'s to this.foo()'s?

IMO, a waste of time.  Java isn't Smalltalk, and this isn't self.

	--- Noel

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org