> At 04:33 PM 1/12/2004 -0500, Sterling Hughes wrote:
> >> > In theory, I like the idea of a unified set of XML helper extensions,
> >> > but DOM's so big and ugly that I don't know if it plays well with
> >> > others in the sandbox.
> >>
> >> We are not consistent! Not in any way. DOM uses studlyCaps and SimpleXML
> >> uses underscores for its method names. Speaking of consistency we should
> >> probably discuss whether we want to change all methods of SimpleXML to
> >> studlyCaps (we cannot hcnage the DOM method names). Until RC1 i guess we
> >> can do such changes if we all agree and see it to be important.
> >>
> >
> >Haven't you been reading the thread - there are no more methods! :)
>
> Sterling,
>
> 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.
> 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.
> 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');
> 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.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
