Re: Call for Votes: JSON location
| From: | Joshua Eichorn | Date: | Fri, 07 Apr 2006 22:34:40 +0000 |
| Subject: | Re: Call for Votes: JSON location | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-42134@lists.php.net to get a copy of this message | ||
Pierre wrote:
On 4/8/06, Joshua Eichorn <josh@bluga.net> wrote:But it doesn't matter one bit since HTML_AJAX supports more then just JSON so i have it wrapped anyway and detecting the extension and falling back if it doesn't exist is nice and easy in that context even if its not in the quick some JSON out on the page. -joshFor my use in HTML_AJAX not at all, but im not sure how, you would fit that into the pear packaging standards, or if you really would want too.The name of the package and what it provides may differ. I do not see a problem to have JSON or (Services|HTML|Text)_JSON as name and the two public methods in one file.Since even if you wrapped it in functions_exists you don't have a good way of guaranteeing that the c code and the php code output the same thing. Of course this is mainly a problem on the decode where you have to make choices about using assoc arrays or objectsThe output must be semantically the same. As far as I know they work together to keep both sync'ed.I'd expect you'd want the code in PEAR to match the extension but i don't know how easy of a job that is too do. My extent of working with the code has been patching around utf-8 encoding problems.It is not an easy job, but even a nearly compatible version (> 90%) is way more usefull than a OO interface, from a maintenance and forward compatibility point of view. --Pierre I guess that standpoint the code should at least include a json_encode and json_decode even if it provides an OO api as well.