At 18:26 14/01/2004, Andrei Zmievski wrote:
On Wed, 14 Jan 2004, Zeev Suraski wrote:
> Pretty much everything, yes.
All the handlers? Or just get and set?
Whatever you want to support. Basically, the thing with the proxy object
interface is that there's really no big secret as to how it works. I
On Wed, 14 Jan 2004, Zeev Suraski wrote:
> Pretty much everything, yes.
All the handlers? Or just get and set?
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
At 01:20 14/01/2004, Andrei Zmievski wrote:
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 implem
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' ha
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 conseq
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
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 capabilit
I haven't read this whole huge thread, but I agree with Sterling in this
aspect. If the problem of children and attributes can be addressed
without functions, it should be done that way. DOM is not that overly
complex or with much overhead in the way it's been implemented. If
people need full
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 SX
Hello Andi,
Tuesday, January 13, 2004, 7:35:05 AM, you wrote:
> At 07:21 PM 1/12/2004 -0500, Sterling Hughes wrote:
>>I'm not arguing whether or not getChildren() is easier. Of course it
>>is. I'm arguing that getChildren() is not within the spirit of the
>>simplexml extension, which is explic
At 05:59 PM 1/12/2004 -0500, Sterling Hughes wrote:
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
At 07:21 PM 1/12/2004 -0500, Sterling Hughes wrote:
I'm not arguing whether or not getChildren() is easier. Of course it
is. I'm arguing that getChildren() is not within the spirit of the
simplexml extension, which is explicitly designed to be without accessor
methods. I further, because of the
Hello Pierre-Alain,
Tuesday, January 13, 2004, 12:10:14 AM, you wrote:
> On Tue, 13 Jan 2004 00:31:33 +0200
> Andi Gutmans <[EMAIL PROTECTED]> wrote:
>> I think the major issues are a few engine bugs which we are looking
>> at. If you have any others then feel free to bring them up, with
>> patc
On 2004/01/13, at 8:05, Sterling Hughes wrote:
So is generically processing child elements. Besides, if there is one
technology worth learning when it comes to processing XML its Xpath.
Its XML's SQL/regular expressions, draw what analogies to string
processing
that you will, but I don't see:
$
> I can accept getChildren() and getAttributes() (or better, just
> children() and attributes()) as methods on objects, but I'm not happy
> with them at all. These two methods were considered for inclusion in
> my original thoughts on simplexml, and I decided against them for the
> reasons I've me
Andi Gutmans wrote:
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.
Consider this: Judging from the comments on the list it seems to me that
a) people have
Sterling Hughes wrote:
The problem with simplexml_xpath_query returning an array is that how do
you signify failure and an empty set. In order for you to have code
that uses foreach() it would need to return an empty set on failure in
order to avoid warnings.
My preferred solution would be
1) retu
On Mon, 12 Jan 2004, Sterling Hughes wrote:
> I'm not arguing whether or not getChildren() is easier. Of course it
> is. I'm arguing that getChildren() is not within the spirit of the
> simplexml extension, which is explicitly designed to be without accessor
> methods. I further, because of the
> On Mon, 12 Jan 2004, Sterling Hughes wrote:
> > Its XML's SQL/regular expressions, draw what analogies to string processing
> > that you will, but I don't see:
> >
> > $results = simplexml_query($element, '/child::node()');
> > foreach ($results as $result) {
> > echo $result;
> > }
> >
> >
On Mon, 12 Jan 2004, Sterling Hughes wrote:
> Its XML's SQL/regular expressions, draw what analogies to string processing
> that you will, but I don't see:
>
> $results = simplexml_query($element, '/child::node()');
> foreach ($results as $result) {
> echo $result;
> }
>
> Signifigantly mor
> On Mon, 12 Jan 2004, Sterling Hughes wrote:
>
> > > What's the ultimate goal for simpleXML? I have been hesitant from ever
> > > touching this extension as what I thought it was intended to do, seems
> > > simplistic to where it acutally (is going/went?). Correct me if I'm wrong,
> > > but when
On Mon, 12 Jan 2004, Sterling Hughes wrote:
> > What's the ultimate goal for simpleXML? I have been hesitant from ever
> > touching this extension as what I thought it was intended to do, seems
> > simplistic to where it acutally (is going/went?). Correct me if I'm wrong,
> > but when it started I
On Tue, 13 Jan 2004 00:31:33 +0200
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> I think the major issues are a few engine bugs which we are looking
> at. If you have any others then feel free to bring them up, with
> patches even better. However, it's not that we're going fast. We're
> actually crawl
> 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
> bollock
>
> On Jan 12, 2004, at 5:35 PM, Sterling Hughes wrote:
>
> >>>Well, this can be added with userspace handlers as I mentioned to
> >>>Marcus. The real trick to XML manipulation is Xpath, not adding a
> >>>bunch
> >>>of broken methods. If people want to do that, they can load a
> >>>simplexml
> 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
>> XPath cant be the answer to everything. Although it would work, XPath
> sure. but it can solve most of the simple problems quite efficiently,
> like getting immediate children.
Out of all the functionality that has been mentioned, that was the one I
would have added :)
imho, that is a very us
On Jan 12, 2004, at 5:35 PM, Sterling Hughes wrote:
Well, this can be added with userspace handlers as I mentioned to
Marcus. The real trick to XML manipulation is Xpath, not adding a
bunch
of broken methods. If people want to do that, they can load a
simplexml
object into DOM, and use the two
> > Well, this can be added with userspace handlers as I mentioned to
> > Marcus. The real trick to XML manipulation is Xpath, not adding a bunch
> > of broken methods. If people want to do that, they can load a simplexml
> > object into DOM, and use the two together. ;)
>
> XPath cant be the an
At 11:22 PM 1/12/2004 +0100, Pierre-Alain Joye wrote:
On Mon, 12 Jan 2004 23:58:30 +0200
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> 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
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 ei
> Well, this can be added with userspace handlers as I mentioned to
> Marcus. The real trick to XML manipulation is Xpath, not adding a bunch
> of broken methods. If people want to do that, they can load a simplexml
> object into DOM, and use the two together. ;)
XPath cant be the answer to ever
On Mon, 12 Jan 2004 23:58:30 +0200
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> 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.
Good news :)
But I really would like to talk a
> Well, its not a feature freeze, and this doesn't require a full
"not a violation of a feature freeze."
is what i meant.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> 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 studlyC
Hello Sterling,
Monday, January 12, 2004, 10:54:36 PM, you wrote:
>> Hello Sterling,
>>
>> Monday, January 12, 2004, 10:33:08 PM, you 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
At 04:54 PM 1/12/2004 -0500, Sterling Hughes wrote:
> Hello Sterling,
>
> Monday, January 12, 2004, 10:33:08 PM, you 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 sa
> > My thoughts on this are as follows, some are directly related to the
> topic,
> > some are related to simplexml's original design and current functionality.
> > SimpleXML was originally designed to provide a direct mapping between a
> > XML document and a data structure, through access to the p
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
> Hello Sterling,
>
> Monday, January 12, 2004, 10:33:08 PM, you 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 an
> My thoughts on this are as follows, some are directly related to the
topic,
> some are related to simplexml's original design and current functionality.
> SimpleXML was originally designed to provide a direct mapping between a
> XML document and a data structure, through access to the properties
Hello Sterling,
Monday, January 12, 2004, 10:33:08 PM, you 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 st
> > 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
Hello Adam,
Monday, January 12, 2004, 10:21:23 PM, you wrote:
> On Mon, 12 Jan 2004, Sterling Hughes wrote:
> [snip]
>> > simplexml_save_dom(simplexml_element $e, domDocument $dom)
>> >
>>
>> dom has a function to do this.
> I guess it doesn't make too much difference whether DOM impor
On Mon, 12 Jan 2004, Sterling Hughes wrote:
[snip]
> > simplexml_save_dom(simplexml_element $e, domDocument $dom)
> >
>
> dom has a function to do this.
I guess it doesn't make too much difference whether DOM imports a
SimpleXML object or SimpleXML exports a DOM object to me.
[snip]
>
> > Much of the current code in SimpleXML is due to immaturities in either
> > Zend or the LibXML interface at the time I was writing SimpleXML. I wanted
> > to have cool things to show at conferences, plus other people wanted to see
> > what was possible with simplexml, so features started to cre
On Mon, 12 Jan 2004, Sterling Hughes wrote:
> The idea of simplexml is to return the nodes of *that particular node*,
> not all of the subsequent nodes, therefore (as mentioned before), the
> current behaviour is correct.
I yield to popular opinion and voice of the original
author. :)
> The curr
> To: Andi Gutmans
> Cc: Marcus Boerger; Blake Schwendiman; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] SimpleXML and Default Cast To String
>
> On Thu, 8 Jan 2004, Andi Gutmans wrote:
>
> > At 06:59 PM 1/7/2004 -0500, Adam Maccabee Trachtenberg wrote:
> &g
Schwendiman; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] SimpleXML and Default Cast To String
On Thu, 8 Jan 2004, Andi Gutmans wrote:
> At 06:59 PM 1/7/2004 -0500, Adam Maccabee Trachtenberg wrote:
> > > So i'd say let us add a method for returning the complete content.
Adam
> &
At 01:53 AM 1/12/2004 -0500, Adam Maccabee Trachtenberg wrote:
On Thu, 8 Jan 2004, Andi Gutmans wrote:
> At 06:59 PM 1/7/2004 -0500, Adam Maccabee Trachtenberg wrote:
> > > So i'd say let us add a method for returning the complete content. Adam
> > > could you do that?
> >
> >That wouldn't be too
On Thu, 8 Jan 2004, Andi Gutmans wrote:
> At 06:59 PM 1/7/2004 -0500, Adam Maccabee Trachtenberg wrote:
> > > So i'd say let us add a method for returning the complete content. Adam
> > > could you do that?
> >
> >That wouldn't be too difficult (although I am busy for the next day or
> >two). Howe
At 06:59 PM 1/7/2004 -0500, Adam Maccabee Trachtenberg wrote:
> So i'd say let us add a method for returning the complete content. Adam
> could you do that?
That wouldn't be too difficult (although I am busy for the next day or
two). However, as much as I loathe toggles, I'm wondering if it
wouldn'
ROTECTED]>
> Cc: "Blake Schwendiman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, January 07, 2004 4:59 PM
> Subject: Re: [PHP-DEV] SimpleXML and Default Cast To String
>
>
> > On Thu, 8 Jan 2004, Marcus Boerger wrote:
> >
> > &g
rcus Boerger" <[EMAIL PROTECTED]>
Cc: "Blake Schwendiman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 07, 2004 4:59 PM
Subject: Re: [PHP-DEV] SimpleXML and Default Cast To String
> On Thu, 8 Jan 2004, Marcus Boerger wrote:
>
>
Hello Adam,
Thursday, January 8, 2004, 12:59:19 AM, you wrote:
> On Thu, 8 Jan 2004, Marcus Boerger wrote:
>> From my opinion the current behavior is perfect because i see simplexml from
>> an xml developers side and not from an html developers side. The former must
>> typically know exactly whe
On Thu, 8 Jan 2004, Marcus Boerger wrote:
> From my opinion the current behavior is perfect because i see simplexml from
> an xml developers side and not from an html developers side. The former must
> typically know exactly where his strings comme from while the latter has
> only text to deal wit
Hello Adam,
Wednesday, January 7, 2004, 10:54:24 PM, you wrote:
> On Wed, 7 Jan 2004, Blake Schwendiman wrote:
>> Note that the embedded text is missing. Internally, the cast is
>> made using the xmlNodeListGetString function. Is there any reason that
>> it makes more sense to do that rather
On Wed, 7 Jan 2004, Blake Schwendiman wrote:
> Note that the embedded text is missing. Internally, the cast is
> made using the xmlNodeListGetString function. Is there any reason that
> it makes more sense to do that rather than use the xmlNodeGetContent
> function. The latter function returns
Hello,
If I have an XML document such:
.
This is some test text.
.
When I use simplexml_load_string and then do:
print( $obj->para );
The result is:
"This is some text."
Note that the embedded text is missing. Internally, the cast is
made using the xmlNodeListGetStrin
59 matches
Mail list logo
