You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/11/10 03:57:53 UTC
Chaining Methods and Fortress
Hi,
I found some code in Fortress (specifically ContextBuilder) that uses
chaining. ie code can look something like
ContextBuilder cb = ...;
cb.doX().doY().doZ();
Because all the methods return this. In many cases this is considered a
problem because it hides problems relating to;
* synchronization
* resource management
etc.
While those don't cover our situation I still consider it a bad practice
because mutators/accessors should be sideeffect free IMO. WOuld anyone object
if I made all those methods not return this? So the code would end up looking
like
ContextBuilder cb = ...;
cb.doX();
cb.doY();
cb.doZ();
--
Cheers,
Peter Donald
He strains to hear a whisper who refuses to hear a shout.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Chaining Methods and Fortress
Posted by Peter Donald <pe...@apache.org>.
On Sun, 10 Nov 2002 22:27, Leo Simons wrote:
> Sounds good. Is this also something to add to our coding standards?
Yep.
>
> cheers,
>
> - Leo
>
> On Sun, 2002-11-10 at 03:57, Peter Donald wrote:
> > Hi,
> >
> > I found some code in Fortress (specifically ContextBuilder) that uses
> > chaining. ie code can look something like
> >
> > ContextBuilder cb = ...;
> >
> > cb.doX().doY().doZ();
> >
> > Because all the methods return this. In many cases this is considered a
> > problem because it hides problems relating to;
> > * synchronization
> > * resource management
> > etc.
> >
> > While those don't cover our situation I still consider it a bad practice
> > because mutators/accessors should be sideeffect free IMO. WOuld anyone
> > object if I made all those methods not return this? So the code would end
> > up looking like
> >
> > ContextBuilder cb = ...;
> >
> > cb.doX();
> > cb.doY();
> > cb.doZ();
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Chaining Methods and Fortress
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Tue, 12 Nov 2002 13:27, Berin Loritsch wrote:
> > > From: Leo Simons [mailto:leosimons@apache.org]
> > >
> > > Sounds good. Is this also something to add to our coding
> standards?
> >
> > What about the "Builder" pattern? Or the precedence of how C++
> > insert operators work?
> >
> > Is there anything inherently evil about it? I am looking to learn
> > here. It seems that in this instance it isn't "so bad".
>
> Breaks java idioms (mainly javabeans and related) and is only
> matched by nio.
And Commons CLI
But, as it was originally done the "java" way, there is no
problem with reverting it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Chaining Methods and Fortress
Posted by Peter Royal <pr...@apache.org>.
On Monday, November 11, 2002, at 09:44 PM, Peter Donald wrote:
>> What about the "Builder" pattern? Or the precedence of how C++
>> insert operators work?
>>
>> Is there anything inherently evil about it? I am looking to learn
>> here. It seems that in this instance it isn't "so bad".
>
> Breaks java idioms (mainly javabeans and related) and is only matched
> by nio.
and StringBuffer?
fwiw the bean pattern is cleaner code unless you are chaining the same
method name.
new StringBuffer().append().append().append();
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Chaining Methods and Fortress
Posted by Peter Donald <pe...@apache.org>.
On Tue, 12 Nov 2002 13:27, Berin Loritsch wrote:
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > Sounds good. Is this also something to add to our coding standards?
>
> What about the "Builder" pattern? Or the precedence of how C++
> insert operators work?
>
> Is there anything inherently evil about it? I am looking to learn
> here. It seems that in this instance it isn't "so bad".
Breaks java idioms (mainly javabeans and related) and is only matched by nio.
--
Cheers,
Peter Donald
"Man's mind stretched to a new idea never goes back to its original
dimensions." -Oliver Wendell Holmes
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Chaining Methods and Fortress
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> Sounds good. Is this also something to add to our coding standards?
What about the "Builder" pattern? Or the precedence of how C++
insert operators work?
Is there anything inherently evil about it? I am looking to learn
here. It seems that in this instance it isn't "so bad".
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Chaining Methods and Fortress
Posted by Leo Simons <le...@apache.org>.
Sounds good. Is this also something to add to our coding standards?
cheers,
- Leo
On Sun, 2002-11-10 at 03:57, Peter Donald wrote:
> Hi,
>
> I found some code in Fortress (specifically ContextBuilder) that uses
> chaining. ie code can look something like
>
> ContextBuilder cb = ...;
>
> cb.doX().doY().doZ();
>
> Because all the methods return this. In many cases this is considered a
> problem because it hides problems relating to;
> * synchronization
> * resource management
> etc.
>
> While those don't cover our situation I still consider it a bad practice
> because mutators/accessors should be sideeffect free IMO. WOuld anyone object
> if I made all those methods not return this? So the code would end up looking
> like
>
> ContextBuilder cb = ...;
>
> cb.doX();
> cb.doY();
> cb.doZ();
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>