[PHP-DEV] SimpleXML: Moving Forward
In the hopes of moving the discussion forward, I'm going to try and sum up general consensus. I believe we agree on most issues, so hopefully it should be easy to come up with the next steps we should take with SimpleXML. I know it's late in the PHP 5 process, but I feel that SimpleXML was designed in somewhat of an ad-hoc manner and has only now reached the point where we have enough experience using it to really know where the troublesome issues lurk. (Build one to throw away.) Since there hasn't yet been a final release of SimpleXML, this is our last chance to make these changes without worrying about BC and it's worth a little trouble to get things closer to right earlier rather than later. Here's where I think we stand, with the points descending from top to bottom in order of general agreement. (e.g. We all agree on point #1 and not everyone agrees with point #6.) 1) SimpleXML creates PHP data structures from XML documents. It only handles XML elements, attributes, and text nodes. The syntax for accessing the text node children of an element is akin to object properties ($foo-bar); the syntax of accessing attributes is akin to array elements ($foo['bar']). 2) It is important to honor the Simple in SimpleXML. SimpleXML will not try to replicate the entire DOM using an alternative syntax. Instead, it will implement a reasonable (as of now deliberately vaguely defined) subset of XML manipulation functions. People who want more comprehensive features can use DOM. 3) This subset will attempt to be as minimalistic as possible, to keep the core small. (e.g. Use XPath.) However, common actions will have an alternative interface when they make SimpleXML easier to use. (e.g. Implement getChildren() and getAttributes() functions.) When deciding the behavior of these functions (e.g. Does getChildren() return just the direct descendents or all children regardless of depth?), we'll define them to mimic XPath's behavior: (e.g. /child::node()). This reduces the potential for disagreement over what is the correct way to do things. (I'm just looking for a way to prevent protracted discussions over issues that have no clear right answers and can never really be solved.) 4) XPath and validation functions will be available in SimpleXML, but we will not try to code generic extensions that work with both SimpleXML and DOM if for no other reason than this is not guaranteed to be simple. (e.g. SimpleXML must remove from XPath results nodes that aren't elements, attributes, and text nodes.) 5) There will be a procedural interface for SimpleXML because nobody is actively against this, Sterling is strongly for this, and Sterling is willing to code it. :) 6) There will be an OO interface for SimpleXML because everybody except Sterling is for this and because it already exists. :) Okay, this message is too long, so I will end it now. If we can get a couple +1s on this, I would then like to move onto the next steps which would be deciding which functions will be in the initial release, what their prototypes are, and who should implement what and by when. If you have problems, please rebut in line. Please try to be brief, I'm wordy enough for everyone. :) -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
On Tue, 13 Jan 2004, Andi Gutmans wrote: At 07:39 AM 1/13/2004 +0100, Marcus Boerger wrote: It's not supposed to be DOM but I think there's a lot of added value in making it easy/simple to do some of the basic methods. I agree it shouldn't be bloated with all of DOM's capabilities. I guess nobody wants a whole bunch of methods in SXE. Up to now Sterling is the only nobody not that the current four responses or so are a real accurate survey :) I don't like those new methods either... as Sterling said it's not in the spirit of the extension. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
I pretty much agree with most of this. I am +1 on moving forward and reaching a plan and implementation ASAP. I agree with Sterling that we should keep things simple and slim. This will also allows us to regret this decision in the future and add more functionality. As I said previously, I would however want to see a few methods which are still simple and extremely useful, so that in the common case people won't need to convert the SimpleXML object to DOM. But seriously, let's move fast on this. It's not right to delay RC1 if people aren't giving this their best shot. Andi At 02:52 AM 1/13/2004 -0500, Adam Maccabee Trachtenberg wrote: In the hopes of moving the discussion forward, I'm going to try and sum up general consensus. I believe we agree on most issues, so hopefully it should be easy to come up with the next steps we should take with SimpleXML. I know it's late in the PHP 5 process, but I feel that SimpleXML was designed in somewhat of an ad-hoc manner and has only now reached the point where we have enough experience using it to really know where the troublesome issues lurk. (Build one to throw away.) Since there hasn't yet been a final release of SimpleXML, this is our last chance to make these changes without worrying about BC and it's worth a little trouble to get things closer to right earlier rather than later. Here's where I think we stand, with the points descending from top to bottom in order of general agreement. (e.g. We all agree on point #1 and not everyone agrees with point #6.) 1) SimpleXML creates PHP data structures from XML documents. It only handles XML elements, attributes, and text nodes. The syntax for accessing the text node children of an element is akin to object properties ($foo-bar); the syntax of accessing attributes is akin to array elements ($foo['bar']). 2) It is important to honor the Simple in SimpleXML. SimpleXML will not try to replicate the entire DOM using an alternative syntax. Instead, it will implement a reasonable (as of now deliberately vaguely defined) subset of XML manipulation functions. People who want more comprehensive features can use DOM. 3) This subset will attempt to be as minimalistic as possible, to keep the core small. (e.g. Use XPath.) However, common actions will have an alternative interface when they make SimpleXML easier to use. (e.g. Implement getChildren() and getAttributes() functions.) When deciding the behavior of these functions (e.g. Does getChildren() return just the direct descendents or all children regardless of depth?), we'll define them to mimic XPath's behavior: (e.g. /child::node()). This reduces the potential for disagreement over what is the correct way to do things. (I'm just looking for a way to prevent protracted discussions over issues that have no clear right answers and can never really be solved.) 4) XPath and validation functions will be available in SimpleXML, but we will not try to code generic extensions that work with both SimpleXML and DOM if for no other reason than this is not guaranteed to be simple. (e.g. SimpleXML must remove from XPath results nodes that aren't elements, attributes, and text nodes.) 5) There will be a procedural interface for SimpleXML because nobody is actively against this, Sterling is strongly for this, and Sterling is willing to code it. :) 6) There will be an OO interface for SimpleXML because everybody except Sterling is for this and because it already exists. :) Okay, this message is too long, so I will end it now. If we can get a couple +1s on this, I would then like to move onto the next steps which would be deciding which functions will be in the initial release, what their prototypes are, and who should implement what and by when. If you have problems, please rebut in line. Please try to be brief, I'm wordy enough for everyone. :) -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
From: Adam Maccabee Trachtenberg
1) SimpleXML creates PHP data structures from XML documents. It only
handles XML elements, attributes, and text nodes. The syntax for
accessing the text node children of an element is akin to object
properties ($foo-bar); the syntax of accessing attributes is akin
to array elements ($foo['bar']).
This goes back to my question on what is the goal of SimpleXML?
Is it supposed to be an easy api to be able to access any xml document or
only not complex ones?
Attributes are handled associative arrays, so given an element with 2
attributes with the same name, but in different namespaces, it wont work:
foo a:bar=x b:bar=y
xpath wont help here either as xsearch returns an array of sxe objects with
the attribute nodes (which causes some additional problems).
Its fine if this would have to be handled in dom, but to me the question
really has never been fully answered.
See also example under the xpath comments for elements containing mixed text
and element nodes.
When deciding the behavior of these functions (e.g. Does
getChildren() return just the direct descendents or all children
regardless of depth?), we'll define them to mimic XPath's behavior:
(e.g. /child::node()). This reduces the potential for disagreement
over what is the correct way to do things. (I'm just looking for
a way to prevent protracted discussions over issues that have no
clear right answers and can never really be solved.)
Should only be direct descendants. One should be able to navigate the entire
tree (elements/attributes) in a standard way without having to use xpath.
imho, this is one of the biggest reason why the two functions should be
implemented.
4) XPath and validation functions will be available in SimpleXML, but
we will not try to code generic extensions that work with both
SimpleXML and DOM if for no other reason than this is not
guaranteed to be simple. (e.g. SimpleXML must remove from XPath
results nodes that aren't elements, attributes, and text nodes.)
return types need to be standardized. attributes or getAttributes returns
name/value array, while the current xsearch will return array of a sxe
objects of the attribute node (which stated before is bad in the current
state of simplexml).
Also, consider the following (an element contains a mix of text and element
nodes):
$foo = simplexml_load_string('fooabfoo2test/foo2cd/foo');
$ns = $foo-xsearch('child::text()');
foreach ($ns as $node) {
print Node Value: .$node.\n;
}
Output:
Node Value: abcd
Node Value: abcd
One would expect:
Node Value: ab
Node Value: cd
Is the output correct, should something like this not be handled via
simpleXML, or is the xsearch incorrect when it returns the parent of a text
node?
Your initial point concerning what SimpleXML is was a good start, but it
still doesn't define the boundaries of what it is meant to handle. When do
you tell someone that what they are doing should not be done in SimpleXML?
This is where I get lost with the API as I don't really know its intended
limitations.
Still +1 on the getChildren/getAttributes.
Rob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
Rob Richards wrote:
From: Adam Maccabee Trachtenberg
accessing the text node children of an element is akin to object
properties ($foo-bar); the syntax of accessing attributes is akin
to array elements ($foo['bar']).
Hmm... This is somewhat up-side-down language wise. Attributes are
properties of a node and the node contains children like an array
contains elements. But I guess we'll keep it that way for nesting sake
($foo-foo2-foo3 is so much nicer than $foo['foo2']['foo3']).
But let's take a look on how I'd use it (xml formatted for readability):
$foo = simplexml_load_string('
foo x:a=xa y:a=ya
ab
foo2foo2a/foo2
cd
foo2foo2b/foo2
ef
foo3
foo3
foo4foo4/foo4
foo3
/foo3
gh
/foo');
foreach ($foo as $node) = foo2a foo2b foo3
foreach ($foo-foo2 as $node) = foo2a foo2b
foreach ($foo-foo3 as $node) = foo4
foreach ((array)$foo-foo3 as $node) = foo4
foreach ($foo-foo3-foo4 as $node) = nothing
foreach ((array)$foo-foo3-foo4 as $node) = foo4
What seems wrong here is that to output nodes where there can be 0 to
multiple instances I have to do something like:
if ($foo-$nodename)
{
if (is_array($foo-$nodename))
{
foreach ($foo-$nodename as $node)
echo $node\n;
}
else
echo {$foo-$nodename}\n;
}
else
echo No node $nodename found\n;
$nodename = 'node1' = No node node1 found
$nodename = 'node2' = foo2a foo2b
$nodename = 'node3' = foo3
Attributes are handled associative arrays, so given an element with 2
attributes with the same name, but in different namespaces, it wont work:
foo a:bar=x b:bar=y
Right now foo['bar'] will be an array('x', 'y') in that case. We're
losing the namespaces here but get the values. Simple or broken? Not sure.
Should only be direct descendants. One should be able to navigate the entire
tree (elements/attributes) in a standard way without having to use xpath.
I agree. What about getChildren($level = 1) with $level=0 meaning all?
This offers both functionalities while having a default we decide on.
As right now there is no easy (read non-xpath/xquery) way of getting the
attributes hidden in the magic array of $foo I think getAttributes
should be added too.
No other functions though. Should these be methods? I think so.
$foo = simplexml_load_string('fooabfoo2test/foo2cd/foo');
$ns = $foo-xsearch('child::text()');
foreach ($ns as $node)
print Node Value: .$node.\n;
I would actually expect abcd but only once:
Node Value: abcd
Concatenating all text parts _and_ returning them once for each part
definitely seems wrong.
+1 on getChildren/getAttributes (function or method)
-1 on more functions
I think it's quite usable this way and simple enough to use to earn the
name SimpleXML.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
At 14:33 13/01/2004, Rob Richards wrote: From: Adam Maccabee Trachtenberg 1) SimpleXML creates PHP data structures from XML documents. It only handles XML elements, attributes, and text nodes. The syntax for accessing the text node children of an element is akin to object properties ($foo-bar); the syntax of accessing attributes is akin to array elements ($foo['bar']). This goes back to my question on what is the goal of SimpleXML? Is it supposed to be an easy api to be able to access any xml document or only not complex ones? The way I see it - yes. Clarity and simplicity are much more important in SimpleXML than being able to analyze every last XML document, that's at least my opinion, and this is what caught the attention of people just about anywhere I demo'd it. Please note that SimpleXML takes after BEA's implementation of XML support in ECMAScript. It may not be a bad idea to see what decisions they took in that context. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
On Jan 13, 2004, at 7:33 AM, Rob Richards wrote:
From: Adam Maccabee Trachtenberg
1) SimpleXML creates PHP data structures from XML documents. It only
handles XML elements, attributes, and text nodes. The syntax for
accessing the text node children of an element is akin to object
properties ($foo-bar); the syntax of accessing attributes is akin
to array elements ($foo['bar']).
This goes back to my question on what is the goal of SimpleXML?
Is it supposed to be an easy api to be able to access any xml document
or
only not complex ones?
Here's where I see the benefit of SimpleXML. SimpleXML should be used
when you know the schema of an XML document and want to extract
specific pieces of data from it. My favorite use-cases are: RSS, REST,
and configuration files.
This doesn't mean there's necessarily a formal XML Schema or RelaxNG
document, but that the developer is familiar enough with the layout of
the XML document that she knows what she's looking for and can
formulate code to access the information she wants.
In most cases, this will be through directly accessing text nodes
through $foo-bar-baz. More complex cases will be handled using XPath:
/rss:foo[begins-with('dc:bar', '2004-01')]/rss:baz.
In my ideal world, you can use SimpleXML for all XML documents,
regardless of complexity (read: namespaces, right?). However, if this
lead to an unnecessary amount of complexity, I would sacrifice this
point.
Also, since there's some assumption of developer fore-knowledge of the
document's schema, there's no need for an overwhelming set of
introspection functions, since that's where DOM excels.
To sum up: it would be helpful to see some *real world* XML documents
that people want to parse using SimpleXML.
We'd then try very hard to make sure SimpleXML was easy to use for
those documents. It's easy to make up theoretical XML documents that
are well-formed and pathologically nasty, but it'd much prefer to leave
those to DOM.
Attributes are handled associative arrays, so given an element with 2
attributes with the same name, but in different namespaces, it wont
work:
foo a:bar=x b:bar=y
xpath wont help here either as xsearch returns an array of sxe objects
with
the attribute nodes (which causes some additional problems).
Its fine if this would have to be handled in dom, but to me the
question
really has never been fully answered.
See also example under the xpath comments for elements containing
mixed text
and element nodes.
Ugh. That's nasty. I would prefer to not handle this in SimpleXML. Have
you really even seen a case where someone did this?
When deciding the behavior of these functions (e.g. Does
getChildren() return just the direct descendents or all children
regardless of depth?), we'll define them to mimic XPath's behavior:
(e.g. /child::node()). This reduces the potential for disagreement
over what is the correct way to do things. (I'm just looking for
a way to prevent protracted discussions over issues that have no
clear right answers and can never really be solved.)
Should only be direct descendants. One should be able to navigate the
entire
tree (elements/attributes) in a standard way without having to use
xpath.
imho, this is one of the biggest reason why the two functions should be
implemented.
I agree here.
4) XPath and validation functions will be available in SimpleXML, but
we will not try to code generic extensions that work with both
SimpleXML and DOM if for no other reason than this is not
guaranteed to be simple. (e.g. SimpleXML must remove from XPath
results nodes that aren't elements, attributes, and text nodes.)
return types need to be standardized. attributes or getAttributes
returns
name/value array, while the current xsearch will return array of a sxe
objects of the attribute node (which stated before is bad in the
current
state of simplexml).
I also agree here. This is one of the reasons I feel it's important to
hash out these details now, so that all the functions work
consistently.
I would prefer to always return an array (or a SimpleXML_List object
that's similar to DOM nodeList) of SimpleXML objects from any querying
function, whether it's getChildren(), getAttributes, or xPathQuery(). I
think this is most consistent.
For example:
foo
bara/bar
bara/bar
/foo
Therefore, $xml-xPathQuery('/foo/bar') and $foo-getChildren() (and
maybe $foo?) would be equivalent.
Also, consider the following (an element contains a mix of text and
element
nodes):
$foo = simplexml_load_string('fooabfoo2test/foo2cd/foo');
$ns = $foo-xsearch('child::text()');
foreach ($ns as $node) {
print Node Value: .$node.\n;
}
Output:
Node Value: abcd
Node Value: abcd
One would expect:
Node Value: ab
Node Value: cd
Is the output correct, should something like this not be handled via
simpleXML, or is the xsearch incorrect when it returns the parent of a
text
node?
Honestly, I don't think anyone (read: I) never
Re: [PHP-DEV] SimpleXML: Moving Forward
On Jan 13, 2004, at 9:21 AM, Christian Schneider wrote:
But let's take a look on how I'd use it (xml formatted for
readability):
$foo = simplexml_load_string('
foo x:a=xa y:a=ya
ab
foo2foo2a/foo2
cd
foo2foo2b/foo2
ef
foo3
foo3
foo4foo4/foo4
foo3
/foo3
gh
/foo');
Ugh. This is pretty much the limit of what I think is reasonable for
SimpleXML to handle. It think the API would be more consistent if the
document looked like:
foo x:a=xa y:b=yb
foo2foo2a/foo2
foo2foo2b/foo2
foo3
foo4foo4/foo4
/foo3
/foo');
However, that may be placing too many restrictions upon documents to
make SimpleXML useful. Like I said before, I've never tried to use
SimpleXML with text nodes and elements sharing the same parent.
foreach ($foo as $node) = foo2a foo2b foo3
foreach ($foo-foo2 as $node) = foo2a foo2b
foreach ($foo-foo3 as $node) = foo4
foreach ((array)$foo-foo3 as $node) = foo4
foreach ($foo-foo3-foo4 as $node) = nothing
foreach ((array)$foo-foo3-foo4 as $node) = foo4
What seems wrong here is that to output nodes where there can be 0 to
multiple instances I have to do something like:
if ($foo-$nodename)
{
if (is_array($foo-$nodename))
{
foreach ($foo-$nodename as $node)
echo $node\n;
}
else
echo {$foo-$nodename}\n;
}
else
echo No node $nodename found\n;
$nodename = 'node1' = No node node1 found
$nodename = 'node2' = foo2a foo2b
$nodename = 'node3' = foo3
I raised this as an issue yesterday. Sterling said he'd look into this.
However, to tie this into my reply to Rob, I think there's some
expectation that the developer knows what she's getting and that the
cases where you have 0, 1, or many potential elements are few. (That
said, I just developed something where I do essentially this all over
the place and it sucks.)
Here are my thoughts on solutions:
1) Place all elements in an array (or nodeList) regardless whether
there's 0, 1, or many. This is the DOM solution. This just leads to
annoying code where you need to do $foo-item(0) and $foo-firstChild.
However, I don't really see any way around this otherwise. Either it's
general or not. It can't be both. (Unless there's some magical type
that's both an array and a scalar.) I'm willing to put up with this
headache because the klunkyness here is outweighted by the niceness for
most cases.
2) If a document has an XML Schema (or RelaxNG schema), SimpleXML could
optionally inspect the schema to see if there are minOccurs and
maxOccurs attributes in the schema for an element. If maxOccurs 1,
then the elements would be placed in an array even if there was only
one element in that particular instance.
This allows us to solve the problem by making the user specifically
tell us how they want SimpleXML to handle a document. It does add some
overhead, but simplicity is often more complex behind the scenes. This
has the benefit of using an existing XML technology to solve the
problem, but I don't know how expensive it'd be.
Again, my opinion is that arbitrary XML documents are best parsed using
DOM and well-defined ones are best parsed using SimpleXML.
Attributes are handled associative arrays, so given an element with 2
attributes with the same name, but in different namespaces, it wont
work:
foo a:bar=x b:bar=y
Right now foo['bar'] will be an array('x', 'y') in that case. We're
losing the namespaces here but get the values. Simple or broken? Not
sure.
This case still makes me puke. :)
Right now, SimpleXML always makes you lose the namespaces unless you
use XPath. I don't think that's too much to ask that if you can handle
XML Namespaces you can also handle XPath. I would prefer to guide
people through XPath in these nasty cases than make the general API
handle them.
As right now there is no easy (read non-xpath/xquery) way of getting
the attributes hidden in the magic array of $foo I think
getAttributes should be added too.
AFAIK, it's actually also impossible to find out the name of the
document element using SimpleXML, even using XPath.
I ended up doing:
$xml = simplexml_load_string($data);
$type = dom_import_simplexml($xml)-tagName;
Without this feature, it's difficult to make SimpleXML work in cases
where a page could be potentially processing two different XML
documents because you can't inspect the XML document to figure out what
type it is. :)
No other functions though. Should these be methods? I think so.
$foo = simplexml_load_string('fooabfoo2test/foo2cd/foo');
$ns = $foo-xsearch('child::text()');
foreach ($ns as $node)
print Node Value: .$node.\n;
I would actually expect abcd but only once:
Node Value: abcd
Concatenating all text parts _and_ returning them once for each part
definitely seems wrong.
Aren't those two lines contradictory? :)
+1 on getChildren/getAttributes (function or method)
-1 on more functions
I think it's quite usable this way and simple enough to use to earn
the name
Re: [PHP-DEV] SimpleXML: Moving Forward
On Tue, 13 Jan 2004, Adam Trachtenberg wrote: Here are my thoughts on solutions: 1) Place all elements in an array (or nodeList) regardless whether there's 0, 1, or many. This is the DOM solution. This just leads to annoying code where you need to do $foo-item(0) and $foo-firstChild. However, I don't really see any way around this otherwise. Either it's general or not. It can't be both. (Unless there's some magical type that's both an array and a scalar.) I'm willing to put up with this headache because the klunkyness here is outweighted by the niceness for most cases. To clarify, I prefer *NOT* to put everything in an array like DOM. The headache I'm willing to put up with is the if(is_array()) code, especially if it turns out to be feasable to do the XML Schema linkage I suggested. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
Adam Trachtenberg wrote: Ugh. This is pretty much the limit of what I think is reasonable for SimpleXML to handle. It think the API would be more consistent if the Agreed. I was just curious how it behaves if I push it to the limit :-) However, I don't really see any way around this otherwise. Either it's general or not. It can't be both. (Unless there's some magical type that's both an array and a scalar.) I'm willing to put up with this Elements are already a magical type which is an object and an array. Making foreach work on a both the scalar and array incantation of child elements seems very useful to me. And usefulness seems to be the goal of SimpleXML as far as I understand. maxOccurs attributes in the schema for an element. If maxOccurs 1, then the elements would be placed in an array even if there was only one element in that particular instance. I don't like the idea: Different behaviour with or without schema. I write code without schema first. If I decide to add a schema later code has to be rewritten. Not good. Again, my opinion is that arbitrary XML documents are best parsed using DOM and well-defined ones are best parsed using SimpleXML. I agree but I think I'll have something like config option1/option option2/option ... /config with 0 - many options quite often and iterating should be a simple foreach IMHO. AFAIK, it's actually also impossible to find out the name of the document element using SimpleXML, even using XPath. Yup, right now the only way is probably to wrap it in a dummy tag before giving it to SimpleXML. Sounds like a good idea anyway to me, if I have a domain specific document with varying content I'd probably do domain.../domain anyway. I would actually expect abcd but only once: Node Value: abcd Concatenating all text parts _and_ returning them once for each part definitely seems wrong. Aren't those two lines contradictory? :) Why? Right now it returns abcd twice which is definitely wrong. Returning ab and cd or (preferably IMHO) abcd once seems right. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
On Tue, 13 Jan 2004, Christian Schneider wrote: Adam Trachtenberg wrote: However, I don't really see any way around this otherwise. Either it's general or not. It can't be both. (Unless there's some magical type that's both an array and a scalar.) I'm willing to put up with this Elements are already a magical type which is an object and an array. Making foreach work on a both the scalar and array incantation of child elements seems very useful to me. And usefulness seems to be the goal of SimpleXML as far as I understand. If that can be done, then I am all for it. Maybe we can somehow make an individual item Iterable. maxOccurs attributes in the schema for an element. If maxOccurs 1, then the elements would be placed in an array even if there was only one element in that particular instance. I don't like the idea: Different behaviour with or without schema. I write code without schema first. If I decide to add a schema later code has to be rewritten. Not good. Don't do that. Use the schema. :) AFAIK, it's actually also impossible to find out the name of the document element using SimpleXML, even using XPath. Yup, right now the only way is probably to wrap it in a dummy tag before giving it to SimpleXML. Sounds like a good idea anyway to me, if I have a domain specific document with varying content I'd probably do domain.../domain anyway. Unless, of course, you're not in control over those documents. I would actually expect abcd but only once: Node Value: abcd Concatenating all text parts _and_ returning them once for each part definitely seems wrong. Aren't those two lines contradictory? :) Why? Right now it returns abcd twice which is definitely wrong. Returning ab and cd or (preferably IMHO) abcd once seems right. Sorry. I misread. I thought you wrote returning them once definitely seems wrong. I agree that we should return abcd in this case. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
Adam Maccabee Trachtenberg wrote: Don't do that. Use the schema. :) Is that why it's called SimpleXML? ;-) I don't think one should force people to use schemata for now. Unless, of course, you're not in control over those documents. You can simply wrap it when passing it to SimpleXML, e.g. simplexml_load_string(mydummytag$xmldata/mydummytag), no? - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
From: Adam Maccabee Trachtenberg
1) SimpleXML creates PHP data structures from XML documents. It only
handles XML elements, attributes, and text nodes. The syntax for
accessing the text node children of an element is akin to object
properties ($foo-bar); the syntax of accessing attributes is akin
to array elements ($foo['bar']).
This goes back to my question on what is the goal of SimpleXML?
Is it supposed to be an easy api to be able to access any xml document or
only not complex ones?
Attributes are handled associative arrays, so given an element with 2
attributes with the same name, but in different namespaces, it wont work:
foo a:bar=x b:bar=y
Attributes should be ns qualified within the array:
$node-foo['a:bar']
This would respect namespaces registered by register_ns()
xpath wont help here either as xsearch returns an array of sxe objects with
the attribute nodes (which causes some additional problems).
Its fine if this would have to be handled in dom, but to me the question
really has never been fully answered.
See also example under the xpath comments for elements containing mixed text
and element nodes.
4) XPath and validation functions will be available in SimpleXML, but
we will not try to code generic extensions that work with both
SimpleXML and DOM if for no other reason than this is not
guaranteed to be simple. (e.g. SimpleXML must remove from XPath
results nodes that aren't elements, attributes, and text nodes.)
I've decided (unless some more people pipe up support for removing
children() and attributes() its current 2-3 against) to leave children()
and attributes(), but remove the other methods. Things like schema
validation and xpath queries will become procedural.
return types need to be standardized. attributes or getAttributes returns
name/value array, while the current xsearch will return array of a sxe
objects of the attribute node (which stated before is bad in the current
state of simplexml).
xsearch will become a procedure, simplexml_query($node, 'expression', $matches);
Also, consider the following (an element contains a mix of text and element
nodes):
$foo = simplexml_load_string('fooabfoo2test/foo2cd/foo');
$ns = $foo-xsearch('child::text()');
foreach ($ns as $node) {
print Node Value: .$node.\n;
}
Output:
Node Value: abcd
Node Value: abcd
One would expect:
Node Value: ab
Node Value: cd
Is the output correct, should something like this not be handled via
simpleXML, or is the xsearch incorrect when it returns the parent of a text
node?
Yep, this is the intended behaviour of simplexml. The
simplexml_save_string() function will allow you to get the entire node
contents (including tags). As for processing text childs separately,
use DOM. It can interpret the same results of an XPath query in the
manner you desire.
Your initial point concerning what SimpleXML is was a good start, but it
still doesn't define the boundaries of what it is meant to handle. When do
you tell someone that what they are doing should not be done in SimpleXML?
This is where I get lost with the API as I don't really know its intended
limitations.
Well, this is the purpose in finalizing the underlying API. The answer
to that question is simple, if it doesn't do what you want, then
SimpleXML is not what you want. This is part of the reason I want to
finalize on no methods. If you need methods, use DOM, the two are
totally interoperable, requiring zero document copies to work with both.
You can process a DOM object then load it into simplexml for the final
processing. Conversely you can take a simplexml object and load it into
DOM for complex processing.
I'm certainly stopping the API at children() and attributes(),
regardless, as anything else is just silly, and it seems that only
people felt strongly about these two functions. (*)
Schema validation and XPath searching will become functions in
SimpleXML space.
-Sterling
(*) Btw, getChildren() is currently broken from a userspace perspective
as it is mainly implemented for the SPL recursive iterator. This will
have to change, simplexml will not add userspace APIs for other
extensions.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
On Tue, 13 Jan 2004, Marcus Boerger wrote: The problem here are virtual properties that are not stored via a hashtable in the object. The problem (of course) is that the read (RW) handler creates a temp container for the property value. As a consequence the changed value needs to be written back using the write handler. To accomplish that we have two options: a) Chnage the signature of the read handler so it returns whether ot not the prop is a virtual prop and use write after the change if so. b) Somehow identify the situation and print out a E_ERROR. Isn't that what Stas's proxy object system was supposed to solve? I've been trying to get an answer as to whether it works or not for a while now. -Andrei The day Microsoft makes something that doesn't suck, is probably the day Microsoft starts making vacuum cleaners. - Ernst Jan Plugge -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
On Tue, 13 Jan 2004, Adam Maccabee Trachtenberg wrote: If we can get a couple +1s on this, I would then like to move onto the next steps which would be deciding which functions will be in the initial release, what their prototypes are, and who should implement what and by when. +1. -Andrei Aim for success, not perfection. Never give up your right to be wrong, because then you will lose the ability to learn new things and move forward with your life. Remember that fear always lurks behind perfectionism. Confronting your fears and allowing yourself the right to be human can, paradoxically, make yourself a happier and more productive person. -- Dr. David M. Burns -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] fix for bug #26696
Hey,
I've attached a fix for an engine level crash in switch() when it is
used with string offsets. This eliminates a double-free and valgrind
reports that no new leaks have been introduced.
-Sterling
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.582
diff -u -r1.582 zend_execute.c
--- zend_execute.c 8 Jan 2004 17:31:47 - 1.582
+++ zend_execute.c 13 Jan 2004 19:58:18 -
@@ -194,13 +194,7 @@
{
switch (opline-op1.op_type) {
case IS_VAR:
- if (!T(opline-op1.u.var).var.ptr_ptr) {
- temp_variable *T = T(opline-op1.u.var);
- /* perform the equivalent of equivalent of a
-* quick silent get_zval_ptr, and FREE_OP
-*/
- PZVAL_UNLOCK(T-var.str_offset.str);
- } else {
+ if (T(opline-op1.u.var).var.ptr_ptr) {
zval_ptr_dtor(T(opline-op1.u.var).var.ptr);
if (opline-extended_value) { /* foreach() free */
zval_ptr_dtor(T(opline-op1.u.var).var.ptr);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] new function?
Hi internals, I know HEAD is freezed, but anyway to ask whether a new function in_array_all() can be added. It works like in_array() but checks whether all needles are in the stack array. Diff : http://www.hristov.com/andrey/projects/php_stuff/in_array_all.diff.txt Best wishes, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fix for bug #26696
Are you sure this is OK? It seems strange that string offsets don't need
any unlocking. It might mean we have a problem someplace else and that
you're fixing the cause and not the source of the problem (although I
haven't had time to dig deep).
In general, consider the following code:
$a = Foo;
switch ($a[0]) {
case 'b':
break;
case 'c':
break;
case 'F':
break;
}
Are you sure this doesn't leak now? I don't have time to look at it now,
but if you are absolutely convinced the patch makes sense I'll try and step
through it with a debugger as soon as I have some free time.
BTW, thanks for taking a look at it.
Andi
At 03:03 PM 1/13/2004 -0500, Sterling Hughes wrote:
Hey,
I've attached a fix for an engine level crash in switch() when it is
used with string offsets. This eliminates a double-free and valgrind
reports that no new leaks have been introduced.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fix for bug #26696
Are you sure this is OK? It seems strange that string offsets don't need
any unlocking. It might mean we have a problem someplace else and that
you're fixing the cause and not the source of the problem (although I
haven't had time to dig deep).
In general, consider the following code:
$a = Foo;
switch ($a[0]) {
case 'b':
break;
case 'c':
break;
case 'F':
break;
}
Are you sure this doesn't leak now? I don't have time to look at it now,
but if you are absolutely convinced the patch makes sense I'll try and step
through it with a debugger as soon as I have some free time.
No, I was wrong. I hate the memory manager, it cleans up my leaks for
me - makes it impossible to rely on valgrind. ;) Anyway to turn that off?
I'm playing around some more now.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fix for bug #26696
At 04:06 PM 1/13/2004 -0500, Sterling Hughes wrote:
Are you sure this is OK? It seems strange that string offsets don't need
any unlocking. It might mean we have a problem someplace else and that
you're fixing the cause and not the source of the problem (although I
haven't had time to dig deep).
In general, consider the following code:
$a = Foo;
switch ($a[0]) {
case 'b':
break;
case 'c':
break;
case 'F':
break;
}
Are you sure this doesn't leak now? I don't have time to look at it now,
but if you are absolutely convinced the patch makes sense I'll try and
step
through it with a debugger as soon as I have some free time.
No, I was wrong. I hate the memory manager, it cleans up my leaks for
me - makes it impossible to rely on valgrind. ;) Anyway to turn that off?
If you're running in --enable-debug it should be telling you about the leaks.
I'm playing around some more now.
OK thanks.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new function?
On Tue, 13 Jan 2004, Andrey Hristov wrote:
I know HEAD is freezed, but anyway to ask whether a new function
in_array_all() can be added. It works like in_array() but checks
whether all needles are in the stack array.
Do we really need this either way?
function in_array_all($needles, $haystack, $strict = false) {
foreach($needles as $needle) {
if (!in_array($needle, $haystack, $strict)) {
return false;
}
}
return true;
}
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: new function?
Andrey Hristov wrote: It works like in_array() but checks whether all needles are in the stack array. Looking at the prototype: bool in_array_all(mixed needle1[, mixed needle2], mixed haystack [, bool strict]) I'd say if (and I'm personally -1) this is added it should be bool in_array_all(array needles, array haystack [, bool strict]) IMHO which would make parameter handling much simpler. But then again you could also do array_intersect($needles, $haystack) to get the same result in a lot of cases. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new function?
Andrey Hristov wrote:
Hi internals,
I know HEAD is freezed, but anyway to ask
whether a new function in_array_all() can be added.
It works like in_array() but checks whether all needles
are in the stack array.
Diff :
http://www.hristov.com/andrey/projects/php_stuff/in_array_all.diff.txt
Best wishes,
Andrey
Does this mean that one of the arguments could/should be an array?
if(in_array($needles_array, $haystack_array))
{ /*err */ }
Cheers,
BDKR
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new function?
On Tue, 13 Jan 2004, Andrey Hristov wrote: Hi internals, I know HEAD is freezed, but anyway to ask whether a new function in_array_all() can be added. It works like in_array() but checks whether all needles are in the stack array. Diff : http://www.hristov.com/andrey/projects/php_stuff/in_array_all.diff.txt Maybe just use array_intersect() instead? - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function?
Hi Christian,
Christian Schneider wrote:
Andrey Hristov wrote:
It works like in_array() but checks whether all needles
are in the stack array.
Looking at the prototype:
bool in_array_all(mixed needle1[, mixed needle2], mixed haystack [, bool
strict])
I'd say if (and I'm personally -1) this is added it should be
bool in_array_all(array needles, array haystack [, bool strict])
IMHO which would make parameter handling much simpler.
But then again you could also do array_intersect($needles, $haystack) to
get the same result in a lot of cases.
- Chris
So, I did now some testing. Looks like in_array_all() is 6x faster than
array_intersect()
the haystack is 10 elements, and needles are 3.
When 1000 elements in haystack, the fastest time (when the needles are in the beggining
in_array_all is 300x faster. When the whole haystack should be traversed it's about
250x
faster than array_intersect. When one of the needles is not in the haystack : 300x .
Script :
?php
$i = 0;
while ($i++ 1000) {
$a[] = $i;
}
$start = microtime(1);
$res = in_array_all(100, 2, 3, $a, true);
$end = microtime(1);
printf(Time : %3.5f\n,$end - $start);
$needles = array(100, 2, 3);
$start = microtime(1);
$diff = array_diff($needles, $a);
$end = microtime(1);
var_dump($diff);
printf(Time : %3.5f\n,$end - $start);
?
[EMAIL PROTECTED]:~/dev/5_0 ./php s.php
bool(true)
Time : 0.00010
array(0) {
}
Time : 0.03888
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function?
Hi,
just a correction, I meant array_diff when i wrote array_intersect.
array_diff is more handy since just count($res)==0 is enough, $res is the
returned array of array_diff().
Andrey
Andrey Hristov wrote:
So, I did now some testing. Looks like in_array_all() is 6x faster than
array_intersect()
the haystack is 10 elements, and needles are 3.
When 1000 elements in haystack, the fastest time (when the needles are
in the beggining
in_array_all is 300x faster. When the whole haystack should be traversed
it's about 250x
faster than array_intersect. When one of the needles is not in the
haystack : 300x .
Script :
?php
$i = 0;
while ($i++ 1000) {
$a[] = $i;
}
$start = microtime(1);
$res = in_array_all(100, 2, 3, $a, true);
$end = microtime(1);
printf(Time : %3.5f\n,$end - $start);
$needles = array(100, 2, 3);
$start = microtime(1);
$diff = array_diff($needles, $a);
$end = microtime(1);
var_dump($diff);
printf(Time : %3.5f\n,$end - $start);
?
[EMAIL PROTECTED]:~/dev/5_0 ./php s.php
bool(true)
Time : 0.00010
array(0) {
}
Time : 0.03888
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function?
On Tue, 13 Jan 2004, Andrey Hristov wrote: Hi, just a correction, I meant array_diff when i wrote array_intersect. array_diff is more handy since just count($res)==0 is enough, $res is the returned array of array_diff(). Did you actually try array_intersect()? - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function?
Hi Andrei :)
Andrei Zmievski wrote:
On Tue, 13 Jan 2004, Andrey Hristov wrote:
Hi,
just a correction, I meant array_diff when i wrote array_intersect.
array_diff is more handy since just count($res)==0 is enough, $res is the
returned array of array_diff().
Did you actually try array_intersect()?
- Andrei
Here it is :
[EMAIL PROTECTED]:~/dev/5_0 cat s2.php
?php
$i = 0;
while ($i++ 1000) {
$a[] = $i;
}
$start = microtime(1);
$res = in_array_all(100, 2, 3, $a, true);
$end = microtime(1);
var_dump($res);
printf(Time : %3.5f\n,$end - $start);
$needles = array(100, 2, 3);
$start = microtime(1);
$diff = array_intersect($needles, $a);
$end = microtime(1);
var_dump($diff);
printf(Time : %3.5f\n,$end - $start);
?[EMAIL PROTECTED]:~/dev/5_0 ./php s2.php
bool(true)
Time : 0.00010
array(3) {
[0]=
int(100)
[1]=
int(2)
[2]=
int(3)
}
Time : 0.03078
About 300x .
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fix for bug #26696
Ok, attached is a diff that properly fixes the problem.
-Sterling
At 04:06 PM 1/13/2004 -0500, Sterling Hughes wrote:
Are you sure this is OK? It seems strange that string offsets don't need
any unlocking. It might mean we have a problem someplace else and that
you're fixing the cause and not the source of the problem (although I
haven't had time to dig deep).
In general, consider the following code:
$a = Foo;
switch ($a[0]) {
case 'b':
break;
case 'c':
break;
case 'F':
break;
}
Are you sure this doesn't leak now? I don't have time to look at it now,
but if you are absolutely convinced the patch makes sense I'll try and
step
through it with a debugger as soon as I have some free time.
No, I was wrong. I hate the memory manager, it cleans up my leaks for
me - makes it impossible to rely on valgrind. ;) Anyway to turn that off?
If you're running in --enable-debug it should be telling you about the
leaks.
I'm playing around some more now.
OK thanks.
Andi
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.583
diff -u -r1.583 zend_execute.c
--- zend_execute.c 9 Jan 2004 13:52:19 - 1.583
+++ zend_execute.c 13 Jan 2004 22:24:18 -
@@ -195,11 +195,10 @@
switch (opline-op1.op_type) {
case IS_VAR:
if (!T(opline-op1.u.var).var.ptr_ptr) {
- temp_variable *T = T(opline-op1.u.var);
/* perform the equivalent of equivalent of a
* quick silent get_zval_ptr, and FREE_OP
*/
- PZVAL_UNLOCK(T-var.str_offset.str);
+ PZVAL_UNLOCK(*Ts-var.ptr_ptr);
} else {
zval_ptr_dtor(T(opline-op1.u.var).var.ptr);
if (opline-extended_value) { /* foreach() free */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function?
Hi Andrey, My personal feeling is that not enough people use this to make the pure speed improvement worth a new function. I guess the list will decide... - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ZE2/PHP5 API re: extension questions
I'm looking to update the libical extension I wrote awhile back to use the new features of ZE2 in PHP5 (libical has been written in such a manner that the features of ZE2 are an excellent match to libical's interface). I've been looking over the default exception class in Zend/zend_default_classess.c, and it looks to be a good starting point for what I'd like to do. So, the questions: 1) Using the __ function features (specifically I'm interested in __clone(), __construct(), __destruct(), and __toString()) seems to just mean adding the appropriate entries to the zend_function_entry structure for the class. I notice that when the class is registered, the handlers.clone_obj entry is set to NULL. Am I safe in assuming that setting an entry to NULL in the handlers struct implies using the named function in the zend_function_entry list? (I think the above only applies to __clone(), __get(), and __set()?) 2) Private/protected internal class methods can be defined using the ZEND_ME macro with the flags set to ZEND_ACC_PRIVATE or ZEND_ACC_PROTECTED as appropriate? Also, static class methods can be defined also using ZEND_ME with ZEND_ACC_STATIC as the flags parameter? I guess I only have one class where an internal private/protected class method would be useful, but there are several classes that could benefit from static class methods. 3) Per-class constants: Almost every class in the libical extension can use per-class constants, but I don't see the code for that in the Zend API. Do I need to dig a bit deeper (pointers to appropriate Zend headers/files appreciated :) or is there a specific set of functions that doesn't have an API yet that I should be using? Any help would be appreciated. Thanks! -Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function?
Hi, I didn't write this function to be faster. You asked about array_intersect() and I decided to bechmark (you didn't ask for it though). What I had in mind when I decided to write it was to escape this : if (in_array(some_element, $haystack) in_array(other_element, $haystack) in_array(third_element, $haystack)) which with this function will be : in_array_all(first_element,second_element, third_element, $haystack) In addtion, I have no problem with the proposal the needles to be passed as an array as first parameter. I did the current proto in the way it's now since it's more consistent with in_array(). Finally, I hope that the list will decide. Andrey Christian Schneider wrote: Hi Andrey, My personal feeling is that not enough people use this to make the pure speed improvement worth a new function. I guess the list will decide... - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
