On 1 December 2011 15:01, henrib <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
