On 1 December 2011 15:01, henrib <henrib@apache.org> wrote:
> After more thoughts on the matter, I tried to be attractive to pragmatic
Sorry, what matter?
> coder with JEXL which is antagonist to the more rigorous approach you want
> to impose.
I'm just being cautious, see below.
> As a user of some other libraries, I find bothersome not being able to
> derive classes because all methods/fields are private and/or final when
> there is no "obvious" reason. Which also means I accept the price of this
> freedom which is to follow releases / maintain my code when necessary. Thus,
> my tendency to privilege 'protected' fields or methods.
There are a lot of users of Commons code who just want to be able to
drop in a replacement jar when updates are released.
As I already wrote, it's really easy to release a new version with
fewer restrictions as that does not affect binary compatibility.
The reverse is not the case, and generally requires major upheaval.
> My goal with JEXL was allowing a "playground" of some sort for scripting; I
> will definitely loose interest in it if it has to become a "closed" library.
> Your call.
I expect other users will lose interest if the API breaks frequently.
> --
> View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-New-non-private-mutable-fields-tp4127864p4128789.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
|