We can (and I think we should) solve the attribute/child node ambiguity
using the new array-syntax overloading, i.e., use $root['child'] for the
attribute, and $root->child for nested elements. We should definitely stay
away from having to use functions, either way.
As for the array behavior,
The problem is one of simplicity ;)
I ran into the same problem a couple days ago. In the two examples, an
array of element 'child' is expected. That array may be one or more
elements. SimpleXML turns multiple children of the same element name
into array's, but a single child is not. I'm not
Zeev seems to be working on foreach and simplexml, but the above
behaviour is the correct one. Why should the first loop? If I did:
what would i get?
-Sterling
On Thu, 2003-09-04 at 18:24, Sebastian Bergmann wrote:
> The following script
>
> $root = simplexml_load_string('
>
The problem is this creates a difference with the PEAR classes and PEAR
standards.
I agree that on the whole using underscores is a better method, its my
preference as well. But PEAR already made the decision to go with
studlyCaps, and we should follow in suite (as they are the largest
collection
On 9/4/03 5:55 PM, Lukas Smith wrote:
From: Marcus Börger [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 5:13 PM
CS.
PEAR has had their error messages all lowered cased since it's creation.
I can only speak for the last 1,5 years were I don’t remember this ever
being an issue that
> > A default __toString() doesn't hinder an extension that interoperates with
> > Java/COM or whatever external objects in anyway to handle their casting as
> > they like. In fact the interface approach would deliver the ability to hide
> > those internal differences so that the user can use the
> >> It's just one of my trivial ideas, that why don't us make it capable of
> >> arbitrary casting operation rather than limiting it just for string casts?
Hmm, funny English.. I've got no idea why I wrote it this way.
> > i agree here. this can be important for external integration e.g. Java an
Related articles:
http://marc.theaimsgroup.com/?l=php-dev&m=10527308470&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=104837776401767&w=2
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Hello internals,
>
> referring to paragraph 6 of our CODING_STYLES i changed my own spl extension
>
Zeev Suraski wrote:
> Don't get anywhere near foreach and SimpleXML right now. It's in the
> works :)
Okay :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Int
It would work fine (dunno what you mean with "work" compile/using?)
if you really used HEAD..try getting the real HEAD sources first.
--Jani
On Thu, 4 Sep 2003, Antony Dovgal wrote:
>Hi, all.
>
>Ming extension doesn't work with current HEAD.
>This patch fixes the problem.
>
Don't get anywhere near foreach and SimpleXML right now. It's in the works :)
Zeev
At 19:24 04/09/2003, Sebastian Bergmann wrote:
The following script
');
foreach ($root->child as $child) {
var_dump($child);
}
?>
does not print anything while
The following script
');
foreach ($root->child as $child) {
var_dump($child);
}
?>
does not print anything while
');
foreach ($root->child as $child) {
var_dump($child);
}
?>
correctly prints
o
> From: Marcus Börger [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 04, 2003 5:13 PM
> referring to paragraph 6 of our CODING_STYLES i changed my own spl
> extension
> and parts of SQLite which interact with spl.
>
> [6] Method names follow the 'studlyCaps' (also referred to as 'bumpy
ca
On Thu, 4 Sep 2003, Marcus Börger wrote:
> As the only consequence i think we should remove that part 6 from our CS.
let's replace it with this:
[6] Method names follow the same naming style as normal
functions like "mysql_connect".
Good:
'connect()'
'get_data()'
'buil
> As the only consequence i think we should remove that part 6 from our CS.
Certainly. I did not even know it was there.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello internals,
referring to paragraph 6 of our CODING_STYLES i changed my own spl extension
and parts of SQLite which interact with spl.
[6] Method names follow the 'studlyCaps' (also referred to as 'bumpy case'
or 'camel caps') naming convention, with care taken to minimize the
letter
Hi, all.
Ming extension doesn't work with current HEAD.
This patch fixes the problem.
And there is some problems with Ming documentation.
For example, "new SWFBitmap()" waits for _file contents_ to be passed as first
argument, but manual says:
new swfbitmap ( string filename [, int alphafilenam
Hello l0t3k,
Thursday, September 4, 2003, 2:56:16 PM, you wrote:
>> It's just one of my trivial ideas, that why don't us make it capable of
>> arbitrary casting operation rather than limiting it just for string casts?
> i agree here. this can be important for external integration e.g. Java and
>
> It's just one of my trivial ideas, that why don't us make it capable of
> arbitrary casting operation rather than limiting it just for string casts?
i agree here. this can be important for external integration e.g. Java and
COM
> Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing Li
> It's just one of my trivial ideas, that why don't us make it capable of
> arbitrary casting operation rather than limiting it just for string casts?
i agree here. this can be important for external integration e.g. Java and
COM
> Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing Li
20 matches
Mail list logo
