avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Chaining Methods and Fortress
Date Sun, 10 Nov 2002 13:06:55 GMT
On Sun, 10 Nov 2002 23:49, Leo Sutic wrote:
> Peter Donald wrote:
>  > 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.
> It is using the named parameter idiom:
>      * http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.17
> The code has no problems with synchronization or resource management
> because it is explicitly supposed to be used that way, and I think the use
> of the above idiom is justified in this case.

Its not using "named parameter idiom" as that is used when you need to supply 
multiple parameters to perform some action (that usually ends up aquiring a 
resource). Where it is being used to build a config object that is then 
passed to a real builder that is responsible for doing the work.

ie It is like building the MetaData objects in Phoenix, the ApplicationConfig 
in struts or whatever. 

Everyone else in java land uses beans idioms for building beans - I don't 
think it would be a great idea to break the mold. This convention is rarely 
used outside of ex-C++ developers learning java.

The one place where this convention was broken (NIO) ended up being regretted 
by the EG members who pushed through the change.

If you still want it then I can just create an alternative mechanism that 
follows standard idioms but I would prefer to only support one mechanism.


Peter Donald
He strains to hear a whisper who refuses to hear a shout.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message