commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [JEXL 2.0] o.a.c.jexl or o.a.c.jexl2 ?
Date Tue, 24 Nov 2009 15:25:48 GMT
sebb wrote at Dienstag, 24. November 2009 11:44:

> On 24/11/2009, henrib <henrib@apache.org> wrote:
>>
>>
>>
>>  sebb-2-2 wrote:
>>  >
>>  > Perhaps you could let us know exactly what you are planning to do
>>  > first?
>>  >
>>
>> 1 - Revisit the JexlContext concept to only expose {set,get}JexlVariable
>>  methods (instead of having to expose setVars/getVars & Map) to make it
>>  easier to implement. The "new" JexlContext would be a
>>  JexlEngine.Context, JexlContext would become deprecated but the API
>>  would still support it - using a trivial conversion from JexlContext to
>>  JexlEngine.Context - to make upgrading easier.
> 
> I don't know enough about this to comment.
> 
>>  2 - Make a clean separation between deep (non extensible) classes and
>>  "user land" ones. In particular, the current oac.introspection /
>>  oac.introspection.util.introspection packages are a mix of both
>>  (UberspectImpl vs Introspector) and depend on each other.
>>
>>  The main idea would be to have all extensible classes under oac.jexl2
>>  and all "internal" ones in oac.jexl2.internal(.*); oac.jexl2 would
>>  represent the contractual API, the one we guarantee will be maintained
>>  in subsequent versions, oac.jexl2.internal would be "extend at your own
>>  maintenance cost" APIs.
> 
> That's a very good idea.
> 
> We should still reserve the right to change the public API if doing a
> major release, as at present.
> 
> The difference would be that the internal API could change in minor
> releases.

+1

and we should drop the internal API from the published javadoc then. Modern 
IDEs will take the source anyway, so there's no harm, but its exclusion does 
also make a very clear statement.

- Jörg


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


Mime
View raw message