On Tue, Nov 24, 2009 at 5:29 AM, henrib <[email protected]> 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.
>
<snip/>
Sounds reasonable. The {get,set} variant actually better aligns with
most other APIs which have a notion of a variable context.
> 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.
>
<snap/>
Sounds good, anything that codifies the notion of the "two-part API"
for our users is a good thing indeed.
-Rahul
> Just thoughts & wishes based on experience at this point...
>
>
> sebb-2-2 wrote:
>>
>> Also, please do the jexl => jexl2 changes separately from any other
>> changes.
>>
> Will do.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
