DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8134>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8134 logic error in Function::Execute() for 3-argument functions ------- Additional Comments From [EMAIL PROTECTED] 2002-04-16 21:25 ------- > ------- Additional Comments From [EMAIL PROTECTED] 2002-04-16 18:39 - ------ > OK, I'll update the samples and the doc, but I think you missed my point. > > All extension functions are called through this overload of execute(): > > virtual XObjectPtr > execute( > XPathExecutionContext& executionContext, > XalanNode* context, > const XObjectArgVectorType& args, > const Locator* locator) const; > > So, if you're extension function implements this overload, the bug will not > affect you. Is that clearer? Your point was clear originally. However, it's obvious - not only from the sample extensions, but also from the "extension library" that Xalan-C ships with (e.g. intersection(), etc.) - that the standard method for creating an extension function as a subclass of Function is to overload the argument- specific version of execute(), *not* the vector-based version. Any alternative "new" method that developers "should" be using is not only undocumented, but completely unused in the rest of the system. So if I were to do what you suggest, I'd not only be writing a slightly larger, more error-prone, less reuse-friendly, less encapsulated system by needlessly duplicating a bit of vector-scanning logic every time I added an extension function - I'd also be deviating from what is clearly the standard way of implementing extension functions in Xalan-C 1.3, purely to avoid this bug. No thanks - I think I'll just change the code to call the 3-argument overload when there are 3 arguments...
