Re: Net_URL Bug #6470

From: Date: Wed, 22 Feb 2006 03:46:50 +0000
Subject: Re: Net_URL Bug #6470
References: 1 2 3 4 5 6 7  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-41449@lists.php.net to get a copy of this message
I've added a new comment to the bug report with a link to the new patch http://delta.squiz.net/~arailean/pear6479.udiff.patch It simply introduces a new method encodePath() that can be used standalone. Decided not to call resolvePath in it because they can easily be nested like encodePath(resolvePath($path)) or the other way around. At the moment, nothing in the Class is using this function. Something probably should. There are two places where it could (or should) be used. Constructor and/or getUrl(). Constructor is better, as once constructed, the path property of the URL object is guaranteed to be RFC valid. getURL is OK but not the best because putting it there implies that this is the only official way to extract a valid URL from this object, which means that many other classes that depend on Net_URL's parsing capabilities (to extract components) will not see the encoded path. Alternatively, we could add a 'setPath' method that will encode the path component when it is being set (similar to case 1 above - encoding in the constructor) Or a getPath that will encode (and possibly resolve) the path on access. -- Andrei > +1 for an extra method which would itself call resolvePath() , > but as said, I don't belong to gurus here, better ask them. > ( I belong to stupids ) > Regards > -- > toggg

« previous php.pear.dev (#41449) next »