commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [DBCP] svn commit: r734473
Date Tue, 20 Jan 2009 21:30:07 GMT
On Mon, Jan 19, 2009 at 1:46 PM, sebb <sebbaz@gmail.com> wrote:
> On 19/01/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>> Not really a DBCP only discussion at this point ...
>>
>>
>>  On Sun, Jan 18, 2009 at 1:20 PM, sebb <sebbaz@gmail.com> wrote:
>>  > On 18/01/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
<snip/>
>>  >>  I think whats being pointed out
>>  >>  here is that at some point a design decision was made to have a non
>>  >>  final protected field and its hard to say what usage implications that
>>  >>  has had in the wild.
>>  >
>>  > I take your point, but I think it's more likely that the final
>>  > qualifier was accidentally omitted...
>>
>> <snip/>
>>
>>  Yes, and only the original author can attest to that.
>>
>
> But we can draw inferences from other aspects of the class design.
>
>>
>>  > in particular, the MAJOR_VERSION
>>  > and MINOR_VERSION fields should surely be final, otherwise will the
>>  > implementation be JDBC compliant?
>>  >
>>
>> <snap/>
>>
>>  No time to look at the code ATM, but those seem to be special cases
>>  (theres more semantics to those fields that the purely final/non final
>>  discussion here).
>>
>
> Indeed, that is the point - it does not make sense for these fields to
> be mutable.
>
>>
>>  > If the user was expected to change the fields, why not provide
>>  > synchronised setters/getters as is done with
>>  > accessToUnderlyingConnectionAllowed?
>>  >
>>
>> <snip/>
>>
>>  Yes that can be done.
>
> My point was that if the author really had intended for the fields to
> be mutable, then why did (s)he not provide thread-safe methods for
> doing so?
>
<snap/>

*shrug*


>
>>  But that doesn't change the fact that finalizing
>>  the field(s) at this time breaks compatibility.
>>
>
> IMO, it only breaks compatibility with broken code.
>
<snip/>

I think it boils down to the above point -- saying all code that
writes will necessarily be broken cannot be corroborated.

-Rahul

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


Mime
View raw message