I will go ahead and make the change now, since it is to an interface.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Mon 7/26/2004 12:49 PM
To: Jakarta Commons Developers List; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [math] Ready for 1.0 RC?
Quoting [EMAIL PROTECTED]:
> Returning booleans is not the issue. It's the passing of boolean
> arguments to handle control flow inside methods. [lang] decided
> against boolean arguments in favor of two methods. One for each of
> the control paths.
>
> I for one, would prefer this same approach of dropping the boolean
> argument and replace it with sepearate methods. Do I feel strongly
> about this, as Phils asks? No, as Marks suggests, these methods could
> be added later.
>
> Brent Worden
>
I get it now, yea, I can see how it would be more control oriented to separate
the concerns into two separate methods. It makes sense to do it with methods
instead of parameters because the behavior can be designed into the Interfaces
of the API instead of in the Implementation. If multiple implementations
arise, the the behavior is of each method is well documented, where passing
parameters to control behavior could be somewhat more difficult to maintain.
If you feel the change isn't difficult to complete, I'd say fine, go for it
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
