On 27 May 2010 15:41, Daniel Convissor <dani...@analysisandsolutions.com> wrote: > Hi Richard: > > On Tue, May 25, 2010 at 12:08:17PM +0100, Richard Quadling wrote: >> >> In the event that the xpointer evaluation doesn't return anything, the >> "XPointer evaluation failed" warning is always thrown and the >> xfallback kicks in. > > If there's nothing for a query to find, why is the query being put in at > all? I mean we know whether there's something to be found ahead of time. > So how about only including the lookups where there actually is something > to lookup? > > Thanks, > > --Dan > > -- > T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y > data intensive web and database programming > http://www.AnalysisAndSolutions.com/ > 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 >
You are right. And that is how it is (with the exception of datetime classes). But there are instances where getting just the first entry from the method synopsis list isn't right. The DatePeriod class has 3 constructors. That led me to see the difference between a methodsynopsis and a constructorsynopsis and that the xpointer results were being truncated to only the first entry. Then realised that a fallback was needed when there is no data. So, I put in the construct/destruct/method synopsis xincludes and handled the difference between an OOP and procedural. The fallback was needed when there is nothing to retrieve, but instantly allows for the addition of them without having to modify the class file. Currently, the end result provides for ... 1 - Any number of prototypes for the OOP and procedural constructor/destructor/methods. 2 - Separate constructor and destructor from the methods. And by having the constructor/destructor before the other methods, it feels more right than having them tucked away in the list due to the __ prefix being ignored when the list is displayed. I suspect the sort order is based upon the filename and so if it was __construct.xml rather than, then this would sort them and we could just use methodsynopsis. I would like to have the class synopsis look like ... __construct()'s __destruct()'s __magicMethod's localMethod's inheritedMethod's (public's, protected's as well as final private's to show what methods cannot be overloaded if this class is inherited or sub-classed). For me, it is one of consistency. Also, you have the benefit of being able to identify constructor/destructor/methods x oop/proc in PhD and show them differently if required. I suppose some consensus on this would be nice. I'm more than happy to leave off what I've done. Richard. -- ----- Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling
