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
designe
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 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
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 a
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
proper
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
>properti
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
propert
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
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.
>
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.
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
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.
simplex
> 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
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, 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.
-Andre
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 f
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 Inter
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"
> 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:
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 d
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, $hays
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
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 wis
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_
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
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()
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
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()
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
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
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 comm
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_classes
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(
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
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",
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
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 t
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)
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() can
39 matches
Mail list logo
