|Re: [Wtp-wst-dev] XPath 2.0 User Doc Plugin|
Where the classes/interfaces are internal, we have a bit more freedom on the refactoring.
The method names with the underscores are legacy, and came with the initial code contribution. That type of refactoring especially in classes that are in API packages now, will require a bump of the major version since we are breaking the API contract.
I might suggest for the DefaultDynamicContext, marking it Deprecated, and then creating a new Interface with your suggested refactorings. Please also remember to update the User Interface wiki page with any proposed redesign.
http://wiki.eclipse.org/PsychoPathXPathProcessor/UserInterface As well as the Design Document: http://wiki.eclipse.org/PsychoPathXPathProcessor/DesignFor now, the biggest pressing issues is to make sure that we get to 100% compliance on the test suite. These refactorings and re-designs can be done after that work is completed.
Dave Jesper Steen Møller wrote:
Nice done, tying the Wiki part to the distributed docs.However, it reminds me that I would really like to change some parts of API. The overall changes I'll propose are these:A) ResultSequenceA1) Turn ResultSequence into an interface, and make it immutable, i.e. no more clear(), add(), and concat(). A2) Provide simple implementations for the the empty sequence, singleton sequences, and fixed length sequences. A3) Introduce a class ResultBuilder which has the methods required for building a ResultSequence. A4) Introduce a ResultSequence.modify() which returns a ResultBuilder and provide copy-on-use semantics, w.r.t. the underlying List.B) DefaultDynamicContextWe are mixing the elements of the dynamic and static contexts - I can't see how that's good for the adopters. Example when using XPath for Schema 1.1: - On loading the grammar, a static context is produced, one for each XPath expression (since e.g. namespace prefixes are going to be different). It may make sende for Xerces to provide their own StaticContext, so the shared parts like function libraries are shared, but e.g. the namespaces can differ. Then, for each assertion in a parse/validation run, a dynamic context is in use, and has to "adhere to" the static context of that expression.The proposed changes are then:- Change DefaultDynamicContext to delegate to the DefaultStaticContext instead of extending it. Or just provide a "getStaticContext" getter instead.C) Functions coupled to the static and even the dynamic contexts. This prevents sharing of function libraries. Rather, we should pass the dynamic context in when evaluating (especiallly if we add the getStaticContext to the DynamicContext interface?)D) Cosmetic: why are the function names not camelCase, but underscoreRidden ? shouldn't we at least mimic the style of the DOM standards, e.g. http://www.w3.org/TR/DOM-Level-3-XPath/java-binding.html which is obviously for XPath 1.0, but still worth looking at?Comments, anyone? Unless someone objects, I'll open a bug for each of A-D and submit suggested patches and explanations.-JesperOn Wed, Sep 2, 2009 at 3:07 AM, David Carver <d_a_carver@xxxxxxxxx <mailto:d_a_carver@xxxxxxxxx>> wrote:With the complete of bug 286070 , the PsychoPath user documentation and SDK documentation plugins have been created. The user documentation is sourced from the Eclipse Wiki  and then the appropriate help content is generated using mylyn-wikitext and docbook xsl stylesheets.  https://bugs.eclipse.org/bugs/show_bug.cgi?id=286070  http://wiki.eclipse.org/PsychoPathXPathProcessor/UserManual _______________________________________________ wtp-wst-dev mailing list wtp-wst-dev@xxxxxxxxxxx <mailto:wtp-wst-dev@xxxxxxxxxxx> https://dev.eclipse.org/mailman/listinfo/wtp-wst-dev ------------------------------------------------------------------------ _______________________________________________ wtp-wst-dev mailing list wtp-wst-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-wst-dev
Back to the top