> At 05:13 PM 1/12/2004 -0500, Sterling Hughes wrote:
> >> I actually think it's nice and easy to have some of SimpleXML's methods.
> >> Maybe there is some redundancy and it might be an OK idea to make sure we
> >> got them right, but I definitely think we should keep them.
> >
> >Sure, but you're not an XML guy either. :) XML is a really nasty pit
> >when it comes to processing. Things that seem simple are crazy hard,
> >things that seem hard become crazy simple.
> >
> >Where do you draw the line, how do you implement these methods
> >coherently. Does getChildren() get the immediate children or *all*
> >descendants. This is actually an important question, depending on how
> >you want to process an XML document. How does getting the text of a
> >method work? How do you combine nodes split up by XML tags?
> >
> >DOM is evil, but it's in very many ways a necessary evil, if you want to
> >do programatical searching and manipulation of XML documents. This is a
> >very bad path for SimpleXML to go down. This is why I say XPath and
> >XQuery (in the future) are the solution. This was also the original
> >point of SimpleXML.
>
> I didn't say we should support everything (that would stop it from being
> simple). I'm just saying have some useful methods such as schema validation
> is nice. You were saying all methods should be nuked.
>
Right. Schema Validation is a great example. Perhaps it can be added as
a function, but here is where it gets tricky.
When I do a Schema validation on a simplexml_element, on what element
does the validation happen? Schema validation happens on the root
document, should it happen on the subnode that i call validate on? This
can be solved with a procedural approach (requiring that you pass the
root element), but can't easily be enforced with methods (unless you
throw an exception in every node except the root, which is kinda
counterproductive.)
> >> Also, it's great you've finally woken up, but it's a bit late in the game
> >> to be doing so. We are in a feature freeze now so that we can get RC1 out
> >> of the door hopefully by the end of the month, and it just doesn't make
> >> sense to redesign the whole thing now.
> >
> >Well, its not a feature freeze, and this doesn't require a full
> >redesign. As you know removing methods from a class entry is not at all
> >hard. Neither is changing two methods into functions. Much more
> >grotting of the internals could be done in the future, but the entire set
> >of
> >userspace changes (which are important for 5.0) can be done without any
> >terribly
> >invasive changes.
>
> I don't mind getting some cosmetic changes into RC1. However, I still think
> that not all methods should be made functions.
>
Well, which should remain?
>
> >> A lot of people have done some great work on your initial idea, including
> >> the write support which I think was a must. What we have today is
> >extremely
> >> useable and I think if there are any important last minute
> >> fixes/improvements that need to be made we should go ahead with them, but
> >> they should be made after consulting w/ people and I definitely wouldn't
> >> want to see something drastic such as removing methods. I think the fact
> >> that you have the methods defined on the SimpleXML objects is great.
> >That's
> >> the essence of OOP and if you like it or not, SimpleXML is an OOP
> >extension.
> >>
> >
> >I am consulting with people, thus the thread. Had I not been consulting
> >with people, I could have easily made the changes already.
> >
> >The core of SimpleXML uses objects, because that's the only way (tm).
> >SimpleXML is not an OOP extension. Look how you get a simplexml object,
> >it's all procedural (for a reason). You don't do:
> >
> >$obj = new SimpleXML();
> >$obj->loadFile('filename');
> >
> >But rather:
> >
> >$obj = simplexml_load_file('filename');
>
> Yeah but then you do $obj->foo->bar->barbara.
>
Sure. But I use php_error(E_WARNING) not exceptions. We can certainly
discuss how it is and isn't pure OO, and what that means. OO people are
still arguing that... In fact I read a paper on OO the other day that
said instantiable class should have no external methods (which is
bollocks).
At the end of the day its what works best for the API. And in the case
of SimpleXML which has a rather messed up structure, something like a
array/balanced tree hybrid, most utility methods make better sense as
functions. And access methods shouldn't exist, its not the point of
simplexml.
> >> So after all this ranting what I really think we should be discussing
> >is if
> >> there are any *crucial* things which need changing or fixing without
> >> redesigning the whole thing.
> >>
> >
> >It was never "redesigned." People added work while i was sleeping
> >(since I woke up after all), this work happens to be contrary to the
> >point of the extension. That's why I'm writing in disagreement.
>
> I think the people who continued your work have done a good job in keeping
> things simple. And I don't think the point of the extension has been lost.
> By the way, did you following problem:
>
> Due to engine problems it is currently not possible to access
> a subelement by index 0: $object->property[0].
>
Yes.
> Any constructive ideas on fixing it? The following was a proposed fix by
> Dmitry but I don't think it quite cut it:
Its in there. Its not yet fixed either:
<?php
$XML = <<<EOX
<?xml version="1.0"?>
<names>
<name>
<first>Joe</first>
</name>
</names>
EOX;
$names = simplexml_load_string($XML);
$names->name[0]->first = 'John';
echo $names->name[0]->first;
?>
Will segfault. I can trace it back to an engine problem, although I
haven't gotten into analyzing it yet. I'll take a look at in the
following days (amongst other things), do you have an idea as to the
reason its failing?
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
