<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Recursiveness: CakePHP Set::extract() and JSONPath</title>
	<atom:link href="http://www.christophdorn.com/Blog/2008/09/12/recursiveness-cakephp-setextract-and-jsonpath/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.christophdorn.com/Blog/2008/09/12/recursiveness-cakephp-setextract-and-jsonpath/</link>
	<description>... All around the PHP Toolchain ...</description>
	<pubDate>Sat, 31 Jul 2010 14:44:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Christoph Dorn</title>
		<link>http://www.christophdorn.com/Blog/2008/09/12/recursiveness-cakephp-setextract-and-jsonpath/#comment-50</link>
		<dc:creator>Christoph Dorn</dc:creator>
		<pubDate>Sun, 14 Sep 2008 18:55:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.christophdorn.com/Blog/?p=71#comment-50</guid>
		<description>The comparison makes for a rough baseline but as you mentioned they cannot really be compered as they have different features.

JSONPath does have more features but it is not very user friendly as the selector syntax can get pretty hard to follow and there seem to be some inconsistencies with what is documented and implemented. I had one heck of a time trying to get a complex selector working for both libraries that produces the same result.

Taking the best implementation ideas from both and merging them to come up with a new library that implements a good set of the XPath 2.0 features would be great. Sticking with the XPath syntax probably makes the most sense as a lot of thought has been put into it and many people know it. There could also be a simplified syntax.</description>
		<content:encoded><![CDATA[<p>The comparison makes for a rough baseline but as you mentioned they cannot really be compered as they have different features.</p>
<p>JSONPath does have more features but it is not very user friendly as the selector syntax can get pretty hard to follow and there seem to be some inconsistencies with what is documented and implemented. I had one heck of a time trying to get a complex selector working for both libraries that produces the same result.</p>
<p>Taking the best implementation ideas from both and merging them to come up with a new library that implements a good set of the XPath 2.0 features would be great. Sticking with the XPath syntax probably makes the most sense as a lot of thought has been put into it and many people know it. There could also be a simplified syntax.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Felix Geisendörfer</title>
		<link>http://www.christophdorn.com/Blog/2008/09/12/recursiveness-cakephp-setextract-and-jsonpath/#comment-49</link>
		<dc:creator>Felix Geisendörfer</dc:creator>
		<pubDate>Sun, 14 Sep 2008 18:27:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.christophdorn.com/Blog/?p=71#comment-49</guid>
		<description>Thanks a lot for this comparison. I actually did look at JSONPath at some point and found the implementation to be very interesting. If I remember correctly JSONPath is also a more complete and powerful implementation than Set::extract, so I don't think its quite fair to compare the both directly.

About the 500%: That number was actually partially made up. I remembered that at some point I saw a jump in the ~500%ish range when first experimenting with a non-recursive approach. But after adding some more features and bug fixes I think the speed went down a little from that. So while I think that not using recursions is the biggest speed gain Set::extract has over JSONPath, the 500% difference is more of a coincidence and not directly related to that particular aspect of the implementation.</description>
		<content:encoded><![CDATA[<p>Thanks a lot for this comparison. I actually did look at JSONPath at some point and found the implementation to be very interesting. If I remember correctly JSONPath is also a more complete and powerful implementation than Set::extract, so I don&#8217;t think its quite fair to compare the both directly.</p>
<p>About the 500%: That number was actually partially made up. I remembered that at some point I saw a jump in the ~500%ish range when first experimenting with a non-recursive approach. But after adding some more features and bug fixes I think the speed went down a little from that. So while I think that not using recursions is the biggest speed gain Set::extract has over JSONPath, the 500% difference is more of a coincidence and not directly related to that particular aspect of the implementation.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
