Re: [PHP-DEV] Re: new function?
Andrey Hristov wrote: Hi, jason davidson wrote: I like the idea of passing an array of needles, I wonder if you could just add the ability to pass a needles array to in_array, rather than create a new function. Anyways, it adds flexability, I would use it. Jason Unfortunately, in_array() cannot be modified since this will break BC. Consider this example : php -r '$a = array(1, 2); $haystack = array("string", array(1, 2), 5.5); var_dump(in_array($a, $haystack));' So, in_array() checks for everything, including arrays, starting PHP5 it can look for objects too. So the BC is that till now an array as first parameter is quite ok therefore it cannot be changed. Andrey Sorry, i hadnt even realized that you could already pass needles array into in_array, and now i beleive ive missed the whole point of this thread.. Im done.. :) J -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Leak Script
Hey, The attached script gives 10 leaks when PHP5 is compiled with --enable-debug. These problems are also related to Bug #26765, I'll be taking a look at it, unless someone knows the cause already. The leaks caused when running it are: /home/sterling/work/php/php-src/Zend/zend_execute.c(2840) : Freeing 0x40162A30 (16 bytes), script=t.php /home/sterling/work/php/php-src/Zend/zend_hash.c(236) : Freeing 0x401629CC (44 bytes), script=t.php Last leak repeated 1 time /home/sterling/work/php/php-src/Zend/zend_execute.c(3094) : Freeing 0x40162968 (44 bytes), script=t.php /home/sterling/work/php/php-src/Zend/zend_API.c(720) : Actual location (location was relayed) Last leak repeated 1 time /home/sterling/work/php/php-src/Zend/zend_objects.c(88) : Freeing 0x40162924 (12 bytes), script=t.php Last leak repeated 1 time /home/sterling/work/php/php-src/Zend/zend_execute.c(3093) : Freeing 0x401628E0 (16 bytes), script=t.php /home/sterling/work/php/php-src/Zend/zend_API.c(721) : Freeing 0x4016272C (32 bytes), script=t.php /home/sterling/work/php/php-src/Zend/zend_hash.c(157) : Actual location (location was relayed) Last leak repeated 1 time === Total 10 memory leaks detected === -Sterling t.php Description: application/httpd-php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function?
Hi, jason davidson wrote: I like the idea of passing an array of needles, I wonder if you could just add the ability to pass a needles array to in_array, rather than create a new function. Anyways, it adds flexability, I would use it. Jason Unfortunately, in_array() cannot be modified since this will break BC. Consider this example : php -r '$a = array(1, 2); $haystack = array("string", array(1, 2), 5.5); var_dump(in_array($a, $haystack));' So, in_array() checks for everything, including arrays, starting PHP5 it can look for objects too. So the BC is that till now an array as first parameter is quite ok therefore it cannot be changed. Andrey -- 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 Wed, 14 Jan 2004, Zeev Suraski wrote: > Yes, it works, the 'problem' is that it's really very very simple. 99% of > the work is upto the implementor of the particular proxy object... It just > gives you a very general framework. You mean the implementor needs to implement 'get' and 'set' handlers? - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function?
Andrey Hristov wrote: 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 I like the idea of passing an array of needles, I wonder if you could just add the ability to pass a needles array to in_array, rather than create a new function. Anyways, it adds flexability, I would use it. Jason -- 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
At 19:32 13/01/2004, Andrei Zmievski wrote: 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. Yes, it works, the 'problem' is that it's really very very simple. 99% of the work is upto the implementor of the particular proxy object... It just gives you a very general framework. Zeev -- 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
[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] fix for bug #26696
On Tue, Jan 13, 2004 at 05:27:05PM -0500, Sterling Hughes wrote: > Ok, attached is a diff that properly fixes the problem. [..] > /* perform the equivalent of equivalent of a While you're in there, could you fix the double occurrence double occurrence in this comment? -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- 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
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 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 ?>[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] 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, 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 : ?> [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 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 : ?> [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] 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] 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
[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?
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
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] 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
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
[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
[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
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
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
> 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: > > 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('abtestcd'); > $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: 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("$xmldata"), no? - 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 > ... 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 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 1 2 ... 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 ... 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, 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
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(' ab foo2a cd foo2b ef foo3 foo4 foo3 gh '); 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: foo2a foo2b foo4 '); 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: 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('abtestcd'); $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 SimpleXML. I think this is where we're coming out. (Modulo the XPath and Validation functions.) -adam -- adam
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: 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: a a 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('abtestcd'); $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 considerer that SimpleXML would be used in cases
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
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(' ab foo2a cd foo2b ef foo3 foo4 foo3 gh '); 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: 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('abtestcd'); $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
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: 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('abtestcd'); $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
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 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
[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