sebb wrote at Dienstag, 24. November 2009 11:44: > On 24/11/2009, 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. > > 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: [email protected] For additional commands, e-mail: [email protected]
