Re: [PHP-DEV] beta2, deriving from class Extension and calling parent::__toString() segfaults
Hello Markus, Sunday, November 30, 2003, 10:59:50 PM, you wrote: > Hi, > On Sat, Nov 29, 2003 at 06:09:36PM +0100, Marcus Boerger wrote : >> this works now. > Thanks. Sorry for the order of reply of the mails, my spam filer > catches this one and I only discovered it yet. >> >Besides the segfaults above, is there a chance we have a nicer HTML >> >formatting for reported Exceptions (while still strip those HTML >> >tags from it for logging)? > Can you advise in this issue too? > The thing is, the stack trace is alright and looks good, but not in > HTML since the line breaks are ordinary ones; there's not HTML > formatting for them, so the line break is not visible in the HTML > output. > If I derive my own exception and override __toString() I can call > nl2br(); but then I've the HTML output in the error_log too. > Seems like an chicken and egg problem. Another solution is to modify > error_prepend/append to encapuslate the error output in a pre block. There you go. > Besides this possible, would it be feasable to handle this issue > right away in PHP for HTML and error log output? Maybe it's not > possible anyway. Hm. I don't think this makes sense but maybe we *could* try to establish a callback into main to display uncaught exceptions. But this must wait until after 5 release i think. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move old (or non-mainstream) extensions to PECL before beta 3
Hello Marcus, Sunday, November 30, 2003, 1:35:23 PM, you wrote: > Hello Wez, > Sunday, November 30, 2003, 11:01:51 AM, you wrote: >> There is no point moving unmaintained code from ext to pecl; >> its just a waste of time until we can solve the problem at >> packaging time, which is why I'm suggesting that one of the build >> guru's that hates these unmaintained extensions *cough* Jani >> *cough* should work on the distro building tool which we >> will need real soon now anyway. ;-) > Why not go with RPM's then? The eays way is to split up the RPM's so that we > can have RPMs for the basic stuff like INI, Docs and all, then for the > different sapis and then for all the extensions. See attached makerpm for > current state of work. Hmmm, no attachement. Then here is the url: http://marcus-boerger.de/?php/ext/makerpm -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5 libxml2 Error Handler Broken
We've defined a custom libxml2 error handler,
php_libxml_error_handler(), that makes error messages go through
php_error() instead of printing to stderr.
Unfortunately, libxml2 doesn't make one call to the error function for
each error. Sometimes it seems to do it once per
character. Unfortunately, this makes the error log look crazy.
For instance:
$s = domDocument::load('http://www.php.net/news.rss');
$xpath = new domXpath($s);
$nodes = $xpath->query('//rss:title');
Gives:
PHP Warning: XPath error Undefined namespace prefix in /home/adam/xml-test.php on
line 7
PHP Warning: / in /home/adam/xml-test.php on line 7
PHP Warning: / in /home/adam/xml-test.php on line 7
PHP Warning: r in /home/adam/xml-test.php on line 7
PHP Warning: s in /home/adam/xml-test.php on line 7
PHP Warning: s in /home/adam/xml-test.php on line 7
PHP Warning: : in /home/adam/xml-test.php on line 7
PHP Warning: t in /home/adam/xml-test.php on line 7
PHP Warning: i in /home/adam/xml-test.php on line 7
PHP Warning: t in /home/adam/xml-test.php on line 7
PHP Warning: l in /home/adam/xml-test.php on line 7
PHP Warning: e in /home/adam/xml-test.php on line 7
... (and about 12 more lines after this.)
It should look something like:
PHP Warning: XPath error Undefined namespace prefix in /home/adam/xml-test.php on
line 7
PHP Warning: //rss:title in /home/adam/xml-test.php on line 7
PHP Warning: ^ in /home/adam/xml-test.php on line 7
Reviewing libxml2 error messages, I propose we create a libxml2 error
buffer that only gets flushed when libxml2 sends us a string that ends in
"\n". Otherwise, we just append the new error to the buffer.
I have a patch that does this. Unfortunately, I'm unsure of the best
way to maintain the buffer between calls. I'm pretty sure I'm not
allowed to just declare it "static" within
php_libxml_error_handler(). My current patch makes it a global
variable, which seems just as bad.
I'm not worried too much about concurrency issues because if libxml2
doesn't make atomic error calls, we can't fix it on our end. However,
it would be nice if each extension / instance that uses this error
function maintain its own buffer, or is that not really an issue?
The patch is up at:
http://www.trachtenberg.com/patches/php_libxml_error_handler.txt
-adam
--
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug in DOM document.c php_dom_ctx_error_level()
The php_dom_ctx_error_level() function in DOM document.c assumes that input->filename is always non-null. This is not true when the file is an entity. You can trigger this by killing your Internet connection and then loading any XML file that references an external entity. For example: http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent";> %HTMLlat1; ]> A patch to fix this is available at: http://www.trachtenberg.com/patches/php_dom_ctx_error_level.txt -adam -- [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in DOM document.c php_dom_ctx_error_level()
hi adam it's commited. thanks fot the patch chregu On 12/1/03 9:10 AM, Adam Maccabee Trachtenberg wrote: The php_dom_ctx_error_level() function in DOM document.c assumes that input->filename is always non-null. This is not true when the file is an entity. You can trigger this by killing your Internet connection and then loading any XML file that references an external entity. For example: http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent";> %HTMLlat1; ]> A patch to fix this is available at: http://www.trachtenberg.com/patches/php_dom_ctx_error_level.txt -adam -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Compatibility problems with PHP 5
> From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 30, 2003 12:10 AM > The strict was introduced so that we can add warnings about practices we > recommend and deprecated behavior. > I think "var" belongs there. > We could remove E_STRICT from E_ALL (although that'd be a bit hacky) and > save ppl the trouble of seeing these warnings. > Then again, we could remove the warning about var but I'm not sure I'd > want > to do that. Well I would make E_ALL a subset of E_STRICT. This would be the cleanest for BC. Of course it might be confusing since "ALL" implies everything .. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
At 07:49 AM 12/1/2003 +0100, Marcus Boerger wrote: Hello Andrei, Friday, November 28, 2003, 1:59:35 PM, you wrote: > On Thu, 27 Nov 2003, Marcus Boerger wrote: >> hellyThu Nov 27 14:24:38 2003 EDT >> >> Modified files: >> /ZendEngine2 zend_API.c >> Log: >> Convert objects to string if string is required by newer parameter parsing >> since we do this for older parameter parsing does so too. > Do you really think this is necessary? I can see the automatic > object->string casting being useful for things like print(), but when a > extension author expects a string, would it make sense to make the > object convert itself? I mean the result will most likely be some > internal object info represented as a string, and not something > meaningful. No, when the object does not offer a valid string conversion nothing will change compared to what we had before. So the only thing done is that you now can implement objects that can be used as strings like simplexml_element. An extension like that cannot be programmed so elegant than without havin it. Besides that we convert all other types automatially whereever we are and objects offer an optional string conversion - so i thing we should use that where the conversion would have been applied for other types and where it makes sense - at least in the parameter parsing. If we don't do this i don't understant why we did such a complex conversion facility at all. Also i see confusion in the users. Why does print use conversion and sprintf not? I disagree strongly. We will get ourselves into a nightmare by trying to automatically support __toString() in all sorts of places. We discussed this a long time ago and agree that __toString() will be only automatically called by print by using make_printable_zval() (some places such as backtrace can also call this). The engine itself should not call __toString() automatically and people will have to use it the verbose way similar to Java. Marcus, please revert any patches which have broken this direction. You shouldn't just commit this stuff without discussing it first. Thanks, Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
At 12:50 AM 12/1/2003 -0500, Adam Maccabee Trachtenberg wrote:
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
> >As far as I'm concerned, if you don't want your object to be
> >auomatically cast to a string, you shouldn't provide a __toString()
> >method.
>
> Wrong. __toString() isn't supposed to work in every case the engine expects
> a string.
> You'd probably also want $obj[3] to work as a string offset?
> In this case, maybe we should rename __toString to __toPrintable, because I
> think Marcus' patch is asking for trouble.
Maybe I'm the one who is confused. What's the point of having a magic
__toString() method (or __toPrintable()) if it doesn't let the object
pretend it's a string?
You're saying it's okay to do:
class foo {
public function __toString() {
return "foo";
}
}
$obj = new foo;
print $foo;
But not:
print htmlentities($foo);
That makes absolutely no sense to me. What if __toString() returns
characters that need encoding? Or if I want to do anything else with
the output other than just print it out?
If I don't want automatic type casting to happen, I don't define
__toString(), but myToString(), which I call when I need to convert the
object to a string.
__toString() is not used for automatic type casting. It is used as a
convention *and* to make it nice to print objects. If you need anything
more than that then call it explicitly. It would be a nightmare to modify
the engine the way you are thinking and many extensions would be fixed.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
At 12:54 AM 12/1/2003 -0500, Adam Maccabee Trachtenberg wrote: On Sun, 30 Nov 2003, Andi Gutmans wrote: > I kind of agree with Andrei here. We discussed in the past that > __toString() will not propogate to every place in the engine where we check > for IS_STRING but will only effect print. > I think getting into this is a bad idea. If the old parameter passing API > does so maybe that should be fixed. I've already expressed my opinion in a previous message, but however this discussion turns out, we should definitely be consistent. If this patch is reverted, then we need to go alter convert_to_string_ex() not to convert an object to a string. Right. I didn't realize this was happening. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
At 07:54 AM 12/1/2003 +0100, Marcus Boerger wrote: Hello Andi, Sunday, November 30, 2003, 12:08:33 AM, you wrote: > At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote: >>On Fri, 28 Nov 2003, Andrei Zmievski wrote: >> >> > On Thu, 27 Nov 2003, Marcus Boerger wrote: >> > > Convert objects to string if string is required by newer parameter >> parsing >> > > since we do this for older parameter parsing does so too. >> > >> > Do you really think this is necessary? I can see the automatic >> > object->string casting being useful for things like print(), but when a >> > extension author expects a string, would it make sense to make the >> > object convert itself? I mean the result will most likely be some >> > internal object info represented as a string, and not something >> > meaningful. >> >>This is needed for SimpleXML. It's an object pretending to be a set of >>strings. You've got to be able to things like: >> >>htmlentities($xml->element); >> >>You can't do that currently because htmlentities() complains that >>you're passing in an object. >> >>As far as I'm concerned, if you don't want your object to be >>auomatically cast to a string, you shouldn't provide a __toString() >>method. > Wrong. __toString() isn't supposed to work in every case the engine expects > a string. > You'd probably also want $obj[3] to work as a string offset? > In this case, maybe we should rename __toString to __toPrintable, because I > think Marcus' patch is asking for trouble. I guess you're right that it doesn not make sense in all places but even if you rename it to printable it should work with all printing functions and hence you are causing confusing trouble and confusion in disallowing it. And if at all we drop the auto-conversion then what we get is: print toupper((string)$obj); Wow, no more elegant php - no more typeless php. No. You would get print toupper($obj->__toString()). I am not sure (string) cast on objects should work. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
>>And if at all we drop the auto-conversion then what we get is: >>print toupper((string)$obj); >>Wow, no more elegant php - no more typeless php. PHP was never "elegant" in this meaning - you never could do toupper($object) and expect something meaningful. I also don't see any elegancy in it - just more crypic way of saying the same thing. I see no problem at all in writing toupper($object->_toString()) - it is clear, self-documenting and error-resistant much more than your "elegant" version. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Mon, 1 Dec 2003, Stanislav Malyshev wrote: >>>And if at all we drop the auto-conversion then what we get is: >>>print toupper((string)$obj); >>>Wow, no more elegant php - no more typeless php. > >PHP was never "elegant" in this meaning - you never could do >toupper($object) and expect something meaningful. I also don't see any >elegancy in it - just more crypic way of saying the same thing. I see no >problem at all in writing toupper($object->_toString()) - it is clear, >self-documenting and error-resistant much more than your "elegant" >version. Couldn't agree more.. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
It *needs* to work so that overloaded objects (simplexml, COM etc.) can have their cast handlers called. Andi wrote: > No. You would get print toupper($obj->__toString()). > I am not sure (string) cast on objects should work. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Mon, 1 Dec 2003, Wez Furlong wrote: > It *needs* to work so that overloaded objects (simplexml, COM etc.) > can have their cast handlers called. Yeah, it's pretty much needed for those extensions... though I don't like these things for normal user defined objects... atleast extensions should have the possibility to have an automatic call to __toString in cases where it is needed. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
There is no __toString in overloaded objects; thats the reason that the (string) cast should work on objects. > > It *needs* to work so that overloaded objects (simplexml, COM etc.) > > can have their cast handlers called. > > Yeah, it's pretty much needed for those extensions... though I don't > like these things for normal user defined objects... atleast extensions > should have the possibility to have an automatic call to __toString in > cases where it is needed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Mon, 1 Dec 2003, Wez Furlong wrote: > There is no __toString in overloaded objects; thats the reason that the > (string) cast should work on objects. Ah, of course :) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
I don't think casting an object to a string should work. I don't see why this is any better than the more verbose $obj->__toString(). Can you please explain in what situation you need __toString() to be called for SimpleXML and COM automatically and we can try and think of a solution together. A possible solution is to remove the comment I put and to remove the __toString () call in the std objects cast handler. Andi At 01:09 PM 12/1/2003 +0100, Derick Rethans wrote: On Mon, 1 Dec 2003, Wez Furlong wrote: > There is no __toString in overloaded objects; thats the reason that the > (string) cast should work on objects. Ah, of course :) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
I'm talking about (string)$obj calling the cast handler in overloaded
objects; COM does not have a __toString() method, and we shouldn't
be cluttering up the "method-space" for overloaded objects - what
if the underlying object has a __toString() method?
I'm not particularly worried about __toString() for regular
user-defined objects, but for overloaded objects, we need that
(string) cast stuff to work so that people can serialize()
things like variant dates, integer values etc.
// Perfect
$v = new variant("12/01/03", VT_DATE);
serialize((string)$v);
// this cannot work- VT_DATE has no methods
serialize($v->__toString());
// PHP string cast gets in the way of
// the real __toString() call.
$v = new COM("Object.With.toString.Method");
serialize($v->__toString());
--Wez.
> I don't think casting an object to a string should work.
> I don't see why this is any better than the more verbose
$obj->__toString().
>
> Can you please explain in what situation you need __toString() to be
called
> for SimpleXML and COM automatically and we can try and think of a solution
> together. A possible solution is to remove the comment I put and to remove
> the __toString
> () call in the std objects cast handler.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
WF>> I'm talking about (string)$obj calling the cast handler in overloaded WF>> objects; COM does not have a __toString() method, and we shouldn't WF>> be cluttering up the "method-space" for overloaded objects - what WF>> if the underlying object has a __toString() method? If it does, it would be good to use it to convert it to string. It actually could be good if Java objects would use standard Java toString method to convert them to string. WF>> I'm not particularly worried about __toString() for regular WF>> user-defined objects, but for overloaded objects, we need that WF>> (string) cast stuff to work so that people can serialize() WF>> things like variant dates, integer values etc. Just a moment here. You imply that serialize() would use the same conversion to string that print, etc.? But that's obviously wrong - no object of PHP does this. Serialized object is one and string representation is something very different. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
serialize($obj) is different from serialize((string)$obj); The reason I mentioned this is that serialize($obj) is currently meaningless for COM objects, so people are using serialize((string)$obj) to get a string representation. --Wez. > Just a moment here. You imply that serialize() would use the same > conversion to string that print, etc.? But that's obviously wrong - no > object of PHP does this. Serialized object is one and string > representation is something very different. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
WF>> The reason I mentioned this is that serialize($obj) is currently WF>> meaningless for COM objects, so people are using WF>> serialize((string)$obj) to get a string representation. I don't understand - what is the meaning of serialize((string)$obj)? What should it return? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
> WF>> The reason I mentioned this is that serialize($obj) is currently > WF>> meaningless for COM objects, so people are using > WF>> serialize((string)$obj) to get a string representation. > > I don't understand - what is the meaning of serialize((string)$obj)? What > should it return? Just pretend I didn't mention serialization... you're getting off topic :-) What I'm trying to say is that (string)$obj really should work (as it does currently) for overloaded objects because they might not have a __toString() method, and if they do, we shouldn't overload it in PHP with some kludge method because we will probably get it wrong (just take a look at the kind of kludge we have for IEnumVariant support in the 4.x COM extension!). --Wez -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
WF>> What I'm trying to say is that (string)$obj really should work (as it WF>> does currently) for overloaded objects because they might not have a I see where you are heading. I would say it should work for objects with explicit cast, but not implicitly, then. Meaning, the cast opcode should call the method for object, I think. That would be a good trade-off between making the cast too magical and requiring explicit toString call. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tidy & PHP5
I would like to propose that tidy extension be bundled with PHP 5. First of all it'll provide an easy means to validate and/or fix HTML input for webforms, which can also help existing functions such as strip_tags(). The extension can also be used to reduce HTML output by removing formatting, which can be quite significant for large pages (even if compression is used). Tidy can also be used to provide a rapid means for conversion between HTML and XHTML and if needed can even handle XML. To those who need to parse HTML it also provides a fairly handy OO API (similar to that of simplexml), which would enable people to write fast HTML parsers in PHP. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
On Monday, Dec 1, 2003, at 14:45 Europe/Copenhagen, Ilia Alshanetsky wrote: I would like to propose that tidy extension be bundled with PHP 5. First of all it'll provide an easy means to validate and/or fix HTML input for webforms, which can also help existing functions such as strip_tags(). The extension can also be used to reduce HTML output by removing formatting, which can be quite significant for large pages (even if compression is used). Tidy can also be used to provide a rapid means for conversion between HTML and XHTML and if needed can even handle XML. To those who need to parse HTML it also provides a fairly handy OO API (similar to that of simplexml), which would enable people to write fast HTML parsers in PHP. Sounds like a useful thing for many typical PHP applications, so +1 from here. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On 2003/12/01, at 19:39, Andi Gutmans wrote:
At 12:50 AM 12/1/2003 -0500, Adam Maccabee Trachtenberg wrote:
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
> >As far as I'm concerned, if you don't want your object to be
> >auomatically cast to a string, you shouldn't provide a __toString()
> >method.
>
> Wrong. __toString() isn't supposed to work in every case the engine
expects
> a string.
> You'd probably also want $obj[3] to work as a string offset?
> In this case, maybe we should rename __toString to __toPrintable,
because I
> think Marcus' patch is asking for trouble.
Maybe I'm the one who is confused. What's the point of having a magic
__toString() method (or __toPrintable()) if it doesn't let the object
pretend it's a string?
You're saying it's okay to do:
class foo {
public function __toString() {
return "foo";
}
}
$obj = new foo;
print $foo;
But not:
print htmlentities($foo);
That makes absolutely no sense to me. What if __toString() returns
characters that need encoding? Or if I want to do anything else with
the output other than just print it out?
If I don't want automatic type casting to happen, I don't define
__toString(), but myToString(), which I call when I need to convert
the
object to a string.
__toString() is not used for automatic type casting. It is used as a
convention *and* to make it nice to print objects. If you need
anything more than that then call it explicitly. It would be a
nightmare to modify the engine the way you are thinking and many
extensions would be fixed.
Probably I didn't catch up with the discussion, but I once mentioned
that automatic type casting is quite useful to implement a
internationalized
string container class. I think it's not only for giving
human-readable string representation but it even more makes
sense to me in practice.
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
At 01:21 PM 12/1/2003 +, Wez Furlong wrote: > WF>> The reason I mentioned this is that serialize($obj) is currently > WF>> meaningless for COM objects, so people are using > WF>> serialize((string)$obj) to get a string representation. > > I don't understand - what is the meaning of serialize((string)$obj)? What > should it return? Just pretend I didn't mention serialization... you're getting off topic :-) What I'm trying to say is that (string)$obj really should work (as it does currently) for overloaded objects because they might not have a __toString() method, and if they do, we shouldn't overload it in PHP with some kludge method because we will probably get it wrong (just take a look at the kind of kludge we have for IEnumVariant support in the 4.x COM extension!). I think there are two options: a) Revert the cast operator patch and don't support automatic string conversion by PHP objects (i.e. allowing overloading extensions to support it). But you still shouldn't expect automagical conversions when passing COM objects to functions which accept strings as a parameter. b) Add a __toString() C API function and make $obj->__toString() call that. It would mean that your COM example would look like serialize($com_object->__toString()). Personally, I prefer (b) but I think I can live with both. Note: In both cases you won't have automatic conversions. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] HEAD eats all memory
Hi, all Current HEAD eats all memory and dies, trying to execute any script (, for example). Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built some minutes ago) work fine on the same machine. My configuration: Linux 2.4.21 autoconf 2.57 automake 1.7 libtool 1.5 gcc 3.3 glibc-2.3.2 apache 1.3.27 cat ./config.nice ! /bin/sh './configure' \ '--with-apxs=/usr/local/apache/bin/apxs' \ '--enable-memory-limit' \ '--disable-dom' \ '--without-pear' \ '--without-sqlite' \ '--disable-cli' \ "$@" of course, when memory-limit is enabled, it only complains "Allowed memory size of 16777216 bytes exhausted" and php tries to eat all memory only when I remove it. --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
I favour a), if you mean that (string)$com_object will work. I'm not so bothered with userspace objects. b) is just wrong for overloaded objects; if we do some magic and either hide an existing __toString() method, or call one with the wrong parameters (it might implement one differently to the way that we expect), then we end up in trouble. --Wez. > I think there are two options: > a) Revert the cast operator patch and don't support automatic string > conversion by PHP objects (i.e. allowing overloading extensions to support > it). But you still shouldn't expect automagical conversions when passing > COM objects to functions which accept strings as a parameter. > b) Add a __toString() C API function and make $obj->__toString() call that. > It would mean that your COM example would look like > serialize($com_object->__toString()). > > Personally, I prefer (b) but I think I can live with both. > Note: In both cases you won't have automatic conversions. > > Andi > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
+1 from me; very useful for screen scraping as well as validation and fixing. --Wez. - Original Message - From: "Ilia Alshanetsky" <[EMAIL PROTECTED]> To: "PHP Internals" <[EMAIL PROTECTED]> Sent: Monday, December 01, 2003 1:45 PM Subject: [PHP-DEV] Tidy & PHP5 > I would like to propose that tidy extension be bundled with PHP 5. > > First of all it'll provide an easy means to validate and/or fix HTML input for > webforms, which can also help existing functions such as strip_tags(). The > extension can also be used to reduce HTML output by removing formatting, > which can be quite significant for large pages (even if compression is used). > Tidy can also be used to provide a rapid means for conversion between HTML > and XHTML and if needed can even handle XML. To those who need to parse HTML > it also provides a fairly handy OO API (similar to that of simplexml), which > would enable people to write fast HTML parsers in PHP. > > Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: HEAD eats all memory
> Current HEAD eats all memory and dies, trying to execute any script (, for example). > Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built some minutes ago) work fine on the same machine. > Thank god ;-) i thought it was on my machine only! Gr, JOhn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
On Mon, 1 Dec 2003 15:51:54 +0100 "John Huntjens" <[EMAIL PROTECTED]> wrote: > > Current HEAD eats all memory and dies, trying to execute any script ( phpinfo(); ?>, for example). > > Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built some > minutes ago) work fine on the same machine. > > > > Thank god ;-) i thought it was on my machine only! I'm glad to hear, that it's not only my problem. But I wonder why it wasn't discovered before... --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Its a binary maths problem: #define E_ALL (E_ERROR | E_WARNING | E_PARSE | E_NOTICE | E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_COMPILE_WARNING | E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE) I guess either slotting E_STRICT in the and defining E_ALL_PHP5 or (E_ALL_PHP4 and redefining E_ALL).. probably worth sticking in a few for future use... so the same problem doesnt occur again..??? E_UNUSED_1 E_UNUSED_2 E_UNUSED_3 E_UNUSED_4 E_UNUSED_5 Regards Alan Lukas Smith wrote: From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: Sunday, November 30, 2003 12:10 AM The strict was introduced so that we can add warnings about practices we recommend and deprecated behavior. I think "var" belongs there. We could remove E_STRICT from E_ALL (although that'd be a bit hacky) and save ppl the trouble of seeing these warnings. Then again, we could remove the warning about var but I'm not sure I'd want to do that. Well I would make E_ALL a subset of E_STRICT. This would be the cleanest for BC. Of course it might be confusing since "ALL" implies everything .. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
+1 if this is counted :) Moriyoshi On 2003/12/01, at 22:45, Ilia Alshanetsky wrote: I would like to propose that tidy extension be bundled with PHP 5. First of all it'll provide an easy means to validate and/or fix HTML input for webforms, which can also help existing functions such as strip_tags(). The extension can also be used to reduce HTML output by removing formatting, which can be quite significant for large pages (even if compression is used). Tidy can also be used to provide a rapid means for conversion between HTML and XHTML and if needed can even handle XML. To those who need to parse HTML it also provides a fairly handy OO API (similar to that of simplexml), which would enable people to write fast HTML parsers in PHP. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
> I would like to propose that tidy extension be bundled with PHP 5. Uhh... +1 from me, too. :) John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
+1 there are ... a lot :-) - Original Message - From: "John Coggeshall" <[EMAIL PROTECTED]> To: "PHP Internals" <[EMAIL PROTECTED]> Sent: Monday, December 01, 2003 4:31 PM Subject: Re: [PHP-DEV] Tidy & PHP5 > > I would like to propose that tidy extension be bundled with PHP 5. > > Uhh... +1 from me, too. :) > > > John > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
Works fine for me. --Jani On Mon, 1 Dec 2003, Antony Dovgal wrote: >Hi, all > >Current HEAD eats all memory and dies, trying to execute any script (phpinfo(); ?>, for example). Version of HEAD from 2003-11-29 and current >PHP_4_3 (both are built some minutes ago) work fine on the same machine. > >My configuration: > >Linux 2.4.21 >autoconf 2.57 >automake 1.7 >libtool 1.5 >gcc 3.3 >glibc-2.3.2 >apache 1.3.27 > >cat ./config.nice > >! /bin/sh > >'./configure' \ >'--with-apxs=/usr/local/apache/bin/apxs' \ >'--enable-memory-limit' \ >'--disable-dom' \ >'--without-pear' \ >'--without-sqlite' \ >'--disable-cli' \ >"$@" > > > >of course, when memory-limit is enabled, it only complains "Allowed memory size of >16777216 bytes exhausted" >and php tries to eat all memory only when I remove it. > >--- >WBR, >Antony Dovgal aka tony2001 >[EMAIL PROTECTED] > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
All I want to be able to do is this:
$s = simplexml_load_file('rss.xml');
foreach ($s->item as $item) {
print htmlentities($item->title . "\n");
}
That's not *all* I want to do, but this is my three-line test case. If
we can figure out a way to make this work, then I'm a happy camper.
I *don't* think it's realisitic to make a person explictly cast
$item->title to a string here. That's not SimpleXML, that's
ConfusingXML, particularly when this works perfectly fine:
print $item->title;
I can't imagine any user in the world understanding why one works and
the other doesn't.
Additionally, I don't think only supporting a print-only __toString()
method is a good thing. That assumes we operate in a CLI context. In a
Web context, people need to call htmlentities() on their data to
ensure their HTML is valid and to prevent XSS attacks. A non-safe lazy
default is asking for trouble.
As to whether this type of magic should be allowed only in C
extensions versus userland classes, is there a fundamental technical
issue or are we only trying to prevent novices from shooting
themselves in the foot?
-adam
On Mon, 1 Dec 2003, Wez Furlong wrote:
> I favour a), if you mean that (string)$com_object will work.
> I'm not so bothered with userspace objects.
>
> b) is just wrong for overloaded objects; if we do some magic
> and either hide an existing __toString() method, or call one
> with the wrong parameters (it might implement one differently
> to the way that we expect), then we end up in trouble.
>
> --Wez.
>
> > I think there are two options:
> > a) Revert the cast operator patch and don't support automatic string
> > conversion by PHP objects (i.e. allowing overloading extensions to support
> > it). But you still shouldn't expect automagical conversions when passing
> > COM objects to functions which accept strings as a parameter.
> > b) Add a __toString() C API function and make $obj->__toString() call
> that.
> > It would mean that your COM example would look like
> > serialize($com_object->__toString()).
> >
> > Personally, I prefer (b) but I think I can live with both.
> > Note: In both cases you won't have automatic conversions.
> >
> > Andi
> >
> >
> >
>
>
--
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
> > > Current HEAD eats all memory and dies, trying to execute any script ( > phpinfo(); ?>, for example). > > > Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built some > > minutes ago) work fine on the same machine. > > > > > > > Thank god ;-) i thought it was on my machine only! > > I'm glad to hear, that it's not only my problem. > But I wonder why it wasn't discovered before... What i more worried about: Is'nt there a quality check about things commited to cvs? It shoud not be possible to break things in such a fundamental way!! Gr, JOhn PS. for now rolled back to php5-200311291030.tar.tar, works ok -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
AMT>> I *don't* think it's realisitic to make a person explictly cast AMT>> $item->title to a string here. That's not SimpleXML, that's If it's not a string - definitely it does. AMT>> ConfusingXML, particularly when this works perfectly fine: If you find it confusing - change API of SimpleXML so that it would make $item->title a string. If you put object in something, why don't you expect it be an object? Why it should instantly become string? AMT>> ensure their HTML is valid and to prevent XSS attacks. A non-safe AMT>> lazy default is asking for trouble. So is complicated default behaviour good or is it bad? I consider it be bad - including auto-converting objects to strings. Except, probably, for explicit (string) conversion. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
Jani Taskinen wrote: > Works fine for me. Works fine here, too. (Win32) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Mon, 1 Dec 2003, Stanislav Malyshev wrote: > AMT>> I *don't* think it's realisitic to make a person explictly cast > AMT>> $item->title to a string here. That's not SimpleXML, that's > > If it's not a string - definitely it does. > > AMT>> ConfusingXML, particularly when this works perfectly fine: > > If you find it confusing - change API of SimpleXML so that it would make > $item->title a string. If you put object in something, why don't you > expect it be an object? Why it should instantly become string? To make it simple to use? I agree with Adam here, with the new overloaded objects you can finally do nice things, just like this here. Don't destroy the coolness of this... Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
On Mon, 1 Dec 2003 17:40:09 +0200 (EET) Jani Taskinen <[EMAIL PROTECTED]> wrote: > > Works fine for me. > I've already re-checked that about 10 times. 2 minutes ago I've repeated all the process from the very beginning: #cvs co php-src #./buildconf #./configure ...blah-blah (configure line from the previous letter) #make same results with : ... Allowed memory size of 16777216 bytes exhausted (tried to allocate 256 bytes) ... --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
On Mon, 1 Dec 2003, John Huntjens wrote: > > > > Current HEAD eats all memory and dies, trying to execute any script > ( > > phpinfo(); ?>, for example). > > > > Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built > some > > > minutes ago) work fine on the same machine. > > > > > > > > > > Thank god ;-) i thought it was on my machine only! > > > > I'm glad to hear, that it's not only my problem. > > But I wonder why it wasn't discovered before... > > What i more worried about: > Is'nt there a quality check about things commited to cvs? > It shoud not be possible to break things in such a fundamental way!! Oh shutup. It works just fine. You guys must be doing something wrong. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
Try with the snapshot from http://snaps.php.net --Jani On Mon, 1 Dec 2003, Antony Dovgal wrote: >On Mon, 1 Dec 2003 17:40:09 +0200 (EET) >Jani Taskinen <[EMAIL PROTECTED]> wrote: > >> >> Works fine for me. >> > >I've already re-checked that about 10 times. > >2 minutes ago I've repeated all the process from the very beginning: >#cvs co php-src >#./buildconf >#./configure ...blah-blah (configure line from the previous letter) >#make > >same results with : >... >Allowed memory size of 16777216 bytes exhausted (tried to allocate 256 bytes) >... > > >--- >WBR, >Antony Dovgal aka tony2001 >[EMAIL PROTECTED] > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
DR>> To make it simple to use? I agree with Adam here, with the new It may make one particular case of use simple. It would make understanding even this case complicated, and will complicate a lot of other cases of which we didn't think now. DR>> overloaded objects you can finally do nice things, just like this here. DR>> Don't destroy the coolness of this... What is "coolness"? Ability to write code that uses tricks nobody can understand without reading engine sources? I don't think it's cool. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
> > What i more worried about: > > Is'nt there a quality check about things commited to cvs? > > It shoud not be possible to break things in such a fundamental way!! > > Oh shutup. It works just fine. You guys must be doing something wrong. No I won't! I compile a snap every day, in the same configuration: snap from 29-11 is ok, today's snap is not. You must be brain dead to say to shutup, without make any verifications! JOhn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
On Mon, 1 Dec 2003 17:03:43 +0100 (CET) Derick Rethans <[EMAIL PROTECTED]> wrote: > On Mon, 1 Dec 2003, John Huntjens wrote: > > > > > > Current HEAD eats all memory and dies, trying to execute any script > > ( > > > phpinfo(); ?>, for example). > > > > > Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built > > some > > > > minutes ago) work fine on the same machine. > > > > > > > > > > > > > Thank god ;-) i thought it was on my machine only! > > > > > > I'm glad to hear, that it's not only my problem. > > > But I wonder why it wasn't discovered before... > > > > What i more worried about: > > Is'nt there a quality check about things commited to cvs? > > It shoud not be possible to break things in such a fundamental way!! > > Oh shutup. It works just fine. You guys must be doing something wrong. of course, there is such possibility. but I have really no idea what can cause today's HEAD to eat memory and Friday's HEAD to work fine at the same time. autotools again? BTW, I've already asked about this message: buildconf: autoconf version 2.50 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. and nobody answered. the problem: if I install autoconf-2.13, ./buildconf fails, because it *requires* autoconf >= 2.50. so, at this moment I don't know which version of autoconf should I use to build PHP from sources in the right way, but autoconf 2.50 worked fine till now (except this message). --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
On Mon, 1 Dec 2003 17:12:02 +0100 "John Huntjens" <[EMAIL PROTECTED]> wrote: > > > > > What i more worried about: > > > Is'nt there a quality check about things commited to cvs? > > > It shoud not be possible to break things in such a fundamental way!! > > > > Oh shutup. It works just fine. You guys must be doing something wrong. > > No I won't! > > I compile a snap every day, in the same configuration: snap from 29-11 is > ok, today's snap is not. > > You must be brain dead to say to shutup, without make any verifications! please, calm down. I'm sure, that Derick, Jani and Sebastian verified this before answering. better tell me versions of your autotools. --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
On Monday, Dec 1, 2003, at 17:12 Europe/Copenhagen, John Huntjens wrote: What i more worried about: Is'nt there a quality check about things commited to cvs? It shoud not be possible to break things in such a fundamental way!! Oh shutup. It works just fine. You guys must be doing something wrong. No I won't! Hey John, no need for harsh tone. PHP5 is work in progress so while it is nice that people test the snaps there is by no means a guarantee that things will work. So tone down your replies a bit. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
> > > > > >>> What i more worried about: > >>> Is'nt there a quality check about things commited to cvs? > >>> It shoud not be possible to break things in such a fundamental way!! > >> > >> Oh shutup. It works just fine. You guys must be doing something wrong. > > > > No I won't! > > > Hey John, no need for harsh tone. PHP5 is work in progress so while it > is nice that people test the snaps there is by no means a guarantee > that things will work. So tone down your replies a bit. Well, I am normally a very polite guy, but when someone tell's me to shut up ... JOhn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
John instead of making a nuisance of yourself, why not find the problem that affects your installation (that 3 developers cannot replicate) and suggest a fix? Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: vrana
Maintaining Czech documentation. If I will find mistake in English documentation, I can send a patch to someone else. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
On Mon, 1 Dec 2003 18:04:46 +0200 (EET) Jani Taskinen <[EMAIL PROTECTED]> wrote: > > Try with the snapshot from http://snaps.php.net no, php5-200312011430 didn't help (just ./configure; make). I've tried this snapshot and current CVS-version on 2 linux-boxes with the same result. It still tries to eat memory =( Second machine is: Linux 2.4.18-5 gcc-2.96 autoconf 2.50 automake 1.4-p5 libtool 1.5 Apache 1.3.27 --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: vrana
Jakub Vrana wrote: Maintaining Czech documentation. If I will find mistake in English documentation, I can send a patch to someone else. Jakub has already helped with the english documentation : http://news.php.net/article.php?group=php.doc&article=969357093 http://news.php.net/article.php?group=php.doc&article=969357092 http://news.php.net/article.php?group=php.doc&article=969357098 didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
> DR>> To make it simple to use? I agree with Adam here, with the new
>
> It may make one particular case of use simple. It would make understanding
> even this case complicated, and will complicate a lot of other cases of
> which we didn't think now.
Are we discussing this feature's technical or aesthetic merits? Or both?
> DR>> overloaded objects you can finally do nice things, just like this here.
> DR>> Don't destroy the coolness of this...
>
> What is "coolness"? Ability to write code that uses tricks nobody can
> understand without reading engine sources? I don't think it's cool.
Everyone who I show SimpleXML to automatically understands what's
going on. Having to explicitly write $node->__toString() undoes about
50% of the simplicty in the extension.
Have you ever used the DOM XML? It's so heavyweight that I want to
shoot myself whenever I'm forced to use it. With DOM, I need to write
crap like:
foreach ($dom->getElementsByTagname('person') as $person) {
list($firstname) = $person->getElementsByTagname('firstname');
$firstname_text_value = $firstname->firstChild->nodeValue;
}
Compare that to:
foreach($s->person as $person) {
$firstname_text_value = $person->firstname;
}
You tell me which one "nobody can understand."
SimpleXML -- with the current automagical casting -- is so easy and
intutive that it's probably more useful for the majority of users than
any other feature in PHP 5. Okay. That's an overstatement.
Here's my take. PHP is messy because it tries to make a messy task
like Web programming easy. XML is a key part of Web
programming. SimpleXML is the PHP take on solving XML. I'd prefer for
SimpleXML not to be messy, but that's what we need to do to make using
XML easy.
-adam
--
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
> no, php5-200312011430 didn't help (just ./configure; make). > I've tried this snapshot and current CVS-version on 2 linux-boxes with the same result. > It still tries to eat memory =( > > Second machine is: > Linux 2.4.18-5 > gcc-2.96 > autoconf 2.50 > automake 1.4-p5 > libtool 1.5 > Apache 1.3.27 My first machine: Linux 2.4.16 gcc-2.95-3 autoconf 2.52 automake 1.4-p5 libtool 1.5 Apache 1.3.20 Now trying on a second machine: Linux 2.4.18 gcc-3.3 autoconf 2.57 automake 1.7 libtool 1.5 Apache 2.0.48 JOhn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
Hello Moriyoshi,
Monday, December 1, 2003, 2:56:29 PM, you wrote:
> On 2003/12/01, at 19:39, Andi Gutmans wrote:
>> At 12:50 AM 12/1/2003 -0500, Adam Maccabee Trachtenberg wrote:
>>> On Sun, 30 Nov 2003, Andi Gutmans wrote:
>>>
>>> > At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
>>>
>>> > >As far as I'm concerned, if you don't want your object to be
>>> > >auomatically cast to a string, you shouldn't provide a __toString()
>>> > >method.
>>> >
>>> > Wrong. __toString() isn't supposed to work in every case the engine
>>> expects
>>> > a string.
>>> > You'd probably also want $obj[3] to work as a string offset?
>>> > In this case, maybe we should rename __toString to __toPrintable,
>>> because I
>>> > think Marcus' patch is asking for trouble.
>>>
>>> Maybe I'm the one who is confused. What's the point of having a magic
>>> __toString() method (or __toPrintable()) if it doesn't let the object
>>> pretend it's a string?
>>>
>>> You're saying it's okay to do:
>>>
>>> class foo {
>>> public function __toString() {
>>> return "foo";
>>> }
>>> }
>>>
>>> $obj = new foo;
>>> print $foo;
>>>
>>> But not:
>>>
>>> print htmlentities($foo);
>>>
>>> That makes absolutely no sense to me. What if __toString() returns
>>> characters that need encoding? Or if I want to do anything else with
>>> the output other than just print it out?
>>>
>>> If I don't want automatic type casting to happen, I don't define
>>> __toString(), but myToString(), which I call when I need to convert
>>> the
>>> object to a string.
>>
>> __toString() is not used for automatic type casting. It is used as a
>> convention *and* to make it nice to print objects. If you need
>> anything more than that then call it explicitly. It would be a
>> nightmare to modify the engine the way you are thinking and many
>> extensions would be fixed.
> Probably I didn't catch up with the discussion, but I once mentioned
> that automatic type casting is quite useful to implement a
> internationalized
> string container class. I think it's not only for giving
> human-readable string representation but it even more makes
> sense to me in practice.
Well we had all we wanted to make ext/simplexml and such a thing working but
now it is all for nothingshitty code!
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
What's the chance of having a __toString() in an external object model (note the two underscores :) Andi At 02:26 PM 12/1/2003 +, Wez Furlong wrote: I favour a), if you mean that (string)$com_object will work. I'm not so bothered with userspace objects. b) is just wrong for overloaded objects; if we do some magic and either hide an existing __toString() method, or call one with the wrong parameters (it might implement one differently to the way that we expect), then we end up in trouble. --Wez. > I think there are two options: > a) Revert the cast operator patch and don't support automatic string > conversion by PHP objects (i.e. allowing overloading extensions to support > it). But you still shouldn't expect automagical conversions when passing > COM objects to functions which accept strings as a parameter. > b) Add a __toString() C API function and make $obj->__toString() call that. > It would mean that your COM example would look like > serialize($com_object->__toString()). > > Personally, I prefer (b) but I think I can live with both. > Note: In both cases you won't have automatic conversions. > > Andi > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
AMT>> Are we discussing this feature's technical or aesthetic merits? Or
AMT>> both?
Technical.
AMT>> foreach ($dom->getElementsByTagname('person') as $person) {
AMT>> list($firstname) = $person->getElementsByTagname('firstname');
AMT>> $firstname_text_value = $firstname->firstChild->nodeValue;
AMT>> }
AMT>>
AMT>> Compare that to:
AMT>>
AMT>> foreach($s->person as $person) {
AMT>> $firstname_text_value = $person->firstname;
AMT>> }
AMT>>
AMT>> You tell me which one "nobody can understand."
Both can be understood, but in the first case you know wat is going on (so
you can rely on $s->person being array and you would be able to do:
$elements = $dom->getElementsByTagname('person');
do_something_with($elements[0]);
and in the second case there's so much magic you don't know what the hell
is really going on. That's OK when you need to do just that, that stops to
be OK when you want to slightly modify the behaviour and discover the
magic is tightly coupled with particular case of use. For example, what
exactly is $person->firstname there? Tag, or some attribute, or contents?
What is $s->person - is it list of all tags with name 'person' contained
in $s or is it element with ID 'person' in $s or maybe it is 'person'
attribute of tag $s? How can I see it from that code? I can't.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
Hello Stanislav, Monday, December 1, 2003, 5:05:14 PM, you wrote: DR>>> To make it simple to use? I agree with Adam here, with the new > It may make one particular case of use simple. It would make understanding > even this case complicated, and will complicate a lot of other cases of > which we didn't think now. If you don't understand XML then it is harder to understand. If you do then you are now basically forced to do fucking code like DOM - thanks - no more simple. DR>>> overloaded objects you can finally do nice things, just like this here. DR>>> Don't destroy the coolness of this... > What is "coolness"? Ability to write code that uses tricks nobody can > understand without reading engine sources? I don't think it's cool. Well it is just features you explicitly have to code like several other languages do - just for the ability to have elegant code. > -- > Stanislav Malyshev, Zend Products Engineer > [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
MB>> If you don't understand XML then it is harder to understand. If you Well, let's suppose I do understand XML for some measure. MB>> you are now basically forced to do fucking code like DOM - thanks - MB>> no more simple. Making particular case of XML handling simple is good if it doesn't make other things harder. I believe the simplification of DOM can be made without making all objects magically convert themselves to strings. MB>> Well it is just features you explicitly have to code like several MB>> other languages do - just for the ability to have elegant code. Now you replaced "cool" with "elegant" - but my point is still standing. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
Hey, I don't quite understand why SimpleXML can't return a string. Why does it need to return an object? It should know how to differentiate between read/write mode, and return a string in read mode and a proxy object in write mode. What am I missing? I agree that we should allow for SimpleXML's simplicity and I think it's one of the coolest features in PHP 5. I definitely want to find a solution to allow it to work the way it works today. However, I do want to try and prevent the propogation throughout the engine because it's going to give us lots of trouble. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
It's probably a lot higher than you think, given that other object models are likely to use a similar naming convention :-) I still think it is a bad idea to hide methods like this for overloaded objects; we have the cast handler and (to my eyes) $foo = (string)$obj; looks simpler and less magical than: $foo = $obj->__toString(); Plus, this latter one has the overhead of resolving the function name etc., whereas the former takes less overhead as (string) gets resolved at compile time, and the engine routes the cast using a shorter path at run time ;-) --Wez. > What's the chance of having a __toString() in an external object model > (note the two underscores :) > > Andi > > At 02:26 PM 12/1/2003 +, Wez Furlong wrote: > >I favour a), if you mean that (string)$com_object will work. > >I'm not so bothered with userspace objects. > > > >b) is just wrong for overloaded objects; if we do some magic > >and either hide an existing __toString() method, or call one > >with the wrong parameters (it might implement one differently > >to the way that we expect), then we end up in trouble. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
It can be resolved at compile-time. My main problem is not with the casting operator but with auto-casting all throughout the engine including parameter passing. I have a very bad feeling that stuff will break such as array offset assigning. Andi At 04:58 PM 12/1/2003 +, Wez Furlong wrote: It's probably a lot higher than you think, given that other object models are likely to use a similar naming convention :-) I still think it is a bad idea to hide methods like this for overloaded objects; we have the cast handler and (to my eyes) $foo = (string)$obj; looks simpler and less magical than: $foo = $obj->__toString(); Plus, this latter one has the overhead of resolving the function name etc., whereas the former takes less overhead as (string) gets resolved at compile time, and the engine routes the cast using a shorter path at run time ;-) --Wez. > What's the chance of having a __toString() in an external object model > (note the two underscores :) > > Andi > > At 02:26 PM 12/1/2003 +, Wez Furlong wrote: > >I favour a), if you mean that (string)$com_object will work. > >I'm not so bothered with userspace objects. > > > >b) is just wrong for overloaded objects; if we do some magic > >and either hide an existing __toString() method, or call one > >with the wrong parameters (it might implement one differently > >to the way that we expect), then we end up in trouble. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
> Now trying on a second machine: > Linux 2.4.18 > gcc-3.3 > autoconf 2.57 > automake 1.7 > libtool 1.5 > Apache 2.0.48 On this machine build is OK JOhn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Something wrong with logos
Current HEAD built as Debug_TS on Windows 2000: http://wopr/index.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 Fatal error: Possible integer overflow in memory allocation (2 * -858993460 + 1) in Unknown on line 0 -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
> I would like to propose that tidy extension be bundled with PHP 5. +1 Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Mon, 1 Dec 2003, Andi Gutmans wrote:
> I don't quite understand why SimpleXML can't return a string. Why does it
> need to return an object? It should know how to differentiate between
> read/write mode, and return a string in read mode and a proxy object in
> write mode.
That may be a solution; however, would I still be able to do something
like this:
$s = simplexml_load_file('file.xml');
$s->person->xsearch('/my/xpath/query');
I'd be willing to sacrfice this in order to get the string behavior
back, however.
> I agree that we should allow for SimpleXML's simplicity and I think it's
> one of the coolest features in PHP 5. I definitely want to find a solution
> to allow it to work the way it works today. However, I do want to try and
> prevent the propogation throughout the engine because it's going to give us
> lots of trouble.
I'm with you here. I don't want to cause trouble, I just want them to
work. :)
-adam
--
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Dec 1, 2003, at 11:52 AM, Marcus Boerger wrote: Hello Stanislav, Monday, December 1, 2003, 5:05:14 PM, you wrote: DR>>> To make it simple to use? I agree with Adam here, with the new It may make one particular case of use simple. It would make understanding even this case complicated, and will complicate a lot of other cases of which we didn't think now. If you don't understand XML then it is harder to understand. If you do then you are now basically forced to do fucking code like DOM - thanks - no more simple. One possible solution is to just fix simplexml. If you have a node that has no descendants, cast it as a string (or better yet, add Schema parsing and recast it as the correct PHP type.). That aside, I agree with Adam, Derick and Marcus that as is the __toString method has high WTF factor and low usability. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
before bundling i'd like to see the api refined... right now it's not possible to work with more than one html-doc at a time. (tidy_parse_file() does not return a resource to the internal tidy doc, so you can only have one doc at a time) also we should ask ourself if (i haven't used tidy so i might be wrong) we want tidy to expose a similar API as SimpleXML does (which we all seem to like - be it too magic or not) re, tc Am 01.12.2003 um 18:39 schrieb Georg Richter: I would like to propose that tidy extension be bundled with PHP 5. +1 Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
AMT>> $s = simplexml_load_file('file.xml');
AMT>> $s->person->xsearch('/my/xpath/query');
This makes fetch for read.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Summary of string conversion problem
Hey, Let's try and summarize this discussion and try and see what solution we can come up with. The change which was made in convert_to_string() is quite problematic. It touches a very fundamental engine function and changes the behavior of tons of places. For example: a) include $obj; will not error out but convert the object to a string and then include it. b) $obj[2] = 3; (where $obj implements a __toString function) isn't quite defined anymore. Should this work? c) $arr[$obj] would suddenly work according the __toString(). Not to say that all sorts of bugs would probably be introduced because all places which call convert_to_string() would have to be checked. The second patch which automatically calls __toString() on parameters isn't quite as bad but I am really not sure this is what we want. Do we want PHP scripts to become much less readable and have people save their strings in objects and pass those around? How will passing such objects by reference work with extension functions which expect their string parameter to be by reference? As you can see there are LOTS of problems this would introduce (and most likely more than I could think of). In the past it was agreed that __toString() would be called explicitly but we would let "print" to be overloaded. Right now, I think making people call it explicitly is the best way to go and the way Java chose too (not that I thnk we necessarily need to go the same way but there were some smart ppl who thought of these issues before us). I do think that SimpleXML has to be tailored for because I truly think that it's the best addition to PHP 5 including the new OOP features. So the question really boils down to what exactly the SimpleXML extension requires? Can't it return a string when it's in read mode? Let's try and find the right balance between ease-of-use for extensions such as SimpleXML and verbosity and a PHP which is not error-prone and as consistent as possible. Marcus, reverting the patch was nothing personal. You can see I have technical issues with it. I think you have been doing some great patches and you know it :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
> AMT>> $s = simplexml_load_file('file.xml');
> AMT>> $s->person->xsearch('/my/xpath/query');
>
> This makes fetch for read.
I'm with Andi and George. We should just fix SimpleXML to return
strings instead of objects when there are no descendant nodes.
Then, $s->person would return an object if there were other nodes to
examine and a string if it was the leaf.
-adam
--
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Dec 1, 2003, at 12:51 PM, Adam Maccabee Trachtenberg wrote:
On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
AMT>> $s = simplexml_load_file('file.xml');
AMT>> $s->person->xsearch('/my/xpath/query');
This makes fetch for read.
I'm with Andi and George. We should just fix SimpleXML to return
strings instead of objects when there are no descendant nodes.
Then, $s->person would return an object if there were other nodes to
examine and a string if it was the leaf.
[puts on evil twin hat]
To play devil's advocate to the idea - the problem with it is that it
requires a bunch of extra code when examining an unknown document.
This is similar to the (promised by Sterling to be fixed) quirk of
SimpleXML returning a string when a chile has a single descendent of a
given name and an array otherwise. This seems intuitive at first, but
means that you need to always check the type of your value before you
use it. The same problem exists here.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory (solved?)
On Mon, 1 Dec 2003 18:21:33 +0100 "John Huntjens" <[EMAIL PROTECTED]> wrote: > > Now trying on a second machine: > > Linux 2.4.18 > > gcc-3.3 > > autoconf 2.57 > > automake 1.7 > > libtool 1.5 > > Apache 2.0.48 > > On this machine build is OK I've changed autoconf to 2.57 and automake to 1.7 - all the same. Upgrading Apache to 1.3.29 doesn't affect this too. Found an interesting effect: this bug appears only when I'm using Opera or Mozilla. both lynx & wget browse ok =) Derick, please, take an attentive look at your patch to SAPI.c, SAPI.h, rfc1867.c, php_variables.c (Sat Nov 29 10:24:35 2003) - Fix sapi_input_filter patch. Reverting your patch fixes the problem, cause the problem seems to be in header parsing routines. Again, the problem is definitely in this patch. --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
On Mon, 1 Dec 2003, George Schlossnagle wrote: > [puts on evil twin hat] Theo? > To play devil's advocate to the idea - the problem with it is that it > requires a bunch of extra code when examining an unknown document. > This is similar to the (promised by Sterling to be fixed) quirk of > SimpleXML returning a string when a chile has a single descendent of a > given name and an array otherwise. This seems intuitive at first, but > means that you need to always check the type of your value before you > use it. The same problem exists here. If you're trying to examine an unknown document using SimpleXML, you're in deep trouble. I don't think SimpleXML really gives you the introspection features that one needs for crawling the tree. For instance, you can't look at attributes at all unless you already know they exist because we've overloaded foreach to iterate through an object's children nodes instead of its "array elements." (Using the correct syntax here with all the overload is difficult.) SimpleXML is best when you're already somewhat familiar with the schema. (IMO) I was trying not to bring up the scalar/array bit because I knew that would just open up a whole new can of worms. Sterling told me at ApacheCon that he'd fix this, but I'll believe him when I see the code. :) I've run into the single/multiple bit before in my actual programs, and I've also run into occasions where an element was missing. However, I've yet to run into occasions when I thought something would be a parent and it turned out to be a leaf. Have you? -adam -- [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
Hi, As an observer of this whole debate, I'd like to point out that if __toString() will be magical anywhere, it must be magical everywhere PHP would normally do an implicit cast, otherwise it does nothing but confuse the issue. implicit cast to string always happens when using string operators and echo/print, and so the __toString() should be looked for. As for built in functions, it would be logical to expect those that operate on strings to do an implicit cast. The only question that I think should be addressed is whether it is practical in terms of performance and code structure. If this seems like too much magic, the entire feature should be dropped, imo (I hope not - I like the __toString() feature, it will be great for many applications). Greg Adam Maccabee Trachtenberg wrote: This is needed for SimpleXML. It's an object pretending to be a set of strings. You've got to be able to things like: htmlentities($xml->element); You can't do that currently because htmlentities() complains that you're passing in an object. As far as I'm concerned, if you don't want your object to be auomatically cast to a string, you shouldn't provide a __toString() method. -adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
In the primary use of tidy (which is to validate HTML), there is very little need for a returned resource other than to clutter the namespace. Unlike most extensions, where it would be useful imo the resource is unnecessary. Since we can reuse the container for the tidy documentation, it's much faster to just perform serial operations for the general case then it is to reallocate a brand new container every time for no reason. As far as the API itself goes for the OO side of things, I think the API that is exposed is just fine. Just as is the case with any screen-scraping tool, the problem is not in the tool but in the document you are scraping (trying to find that table you want buried in the document). John On Mon, 2003-12-01 at 12:46, Thies C.Arntzen wrote: > before bundling i'd like to see the api refined... > > right now it's not possible to work with more than one html-doc at a > time. (tidy_parse_file() does not return a resource to the internal > tidy doc, so you can only have one doc at a time) > > also we should ask ourself if (i haven't used tidy so i might be wrong) > we want tidy to expose a similar API as SimpleXML does (which we all > seem to like - be it too magic or not) > > re, > tc > > > Am 01.12.2003 um 18:39 schrieb Georg Richter: > > > > >> I would like to propose that tidy extension be bundled with PHP 5. > > > > +1 > > > > Georg > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
On Mon, 1 Dec 2003, Antony Dovgal wrote: >On Mon, 1 Dec 2003 18:04:46 +0200 (EET) >Jani Taskinen <[EMAIL PROTECTED]> wrote: > >> >> Try with the snapshot from http://snaps.php.net > >no, php5-200312011430 didn't help (just ./configure; make). >I've tried this snapshot and current CVS-version on 2 linux-boxes with the same >result. >It still tries to eat memory =( Was there some script to go with this..? >gcc-2.96 There is no such gcc version.. >autoconf 2.50 No workie. >libtool 1.5 No workie. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
Jani Taskinen wrote: > Was there some script to go with this..? Maybe this is related to the problem with PHP's logos I posted earlier? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Summary of string conversion problem
I'm not really sure on what's the best way to handle the string conversion problem, as I haven't worked with SimpleXML yet. Andi's examples on the other hand aren't convincing enough for me so here my comments: Andi Gutmans wrote: a) include $obj; will not error out but convert the object to a string and then include it. I'd expect that in most cases this would be an invalid filename which would result in an error message. Nothing lost there. b) $obj[2] = 3; (where $obj implements a __toString function) isn't quite defined anymore. Should this work? The bracket syntax has been deprecated in PHP4 already. Giving a warning on a high error reporting level seems do the job for me. c) $arr[$obj] would suddenly work according the __toString(). I remember this being requested as a feature anyway ;-) go and the way Java chose too (not that I thnk we necessarily need to go the same way but there were some smart ppl who thought of these issues before us). I don't like Java being used for PHP design decisions really. The syntax is cumbersome and has a different focus (static type checking). Don't forget that a lot of design decisions for Java were made in the 80s. My $.2, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
On Mon, 1 Dec 2003, Antony Dovgal wrote: >BTW, I've already asked about this message: > >buildconf: autoconf version 2.50 (ok) >buildconf: Your version of autoconf likely contains buggy cache code. > Running cvsclean for you. > To avoid this, install autoconf-2.13 and automake-1.5. > Don't use autoconf > 2.13, it's really SLOW and also buggy. >and nobody answered. > the problem: if I install autoconf-2.13, ./buildconf >fails, because it *requires* autoconf >= 2.50. Eh..if that was true, I would never ever run this every day: # ./cvsclean && ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: libtool version 1.4.3 (ok) . . Or would I? :) >so, at this moment I don't know which version of autoconf should I use to >build PHP from sources in the right way, but autoconf 2.50 worked fine till >now (except this message). I has never worked perfectly, please don't claim that. As I doubt you have the correct bison, libtool, etc. either, I recommend that you stick with snapshots. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory (solved?)
Finally..if you had mentioned THIS in the first place, you wouldn't have wasted our time.. (didn't I ask for some reproducing procedure? I don't remember anymore :) --Jani On Mon, 1 Dec 2003, Antony Dovgal wrote: >On Mon, 1 Dec 2003 18:21:33 +0100 >"John Huntjens" <[EMAIL PROTECTED]> wrote: > >> > Now trying on a second machine: >> > Linux 2.4.18 >> > gcc-3.3 >> > autoconf 2.57 >> > automake 1.7 >> > libtool 1.5 >> > Apache 2.0.48 >> >> On this machine build is OK > >I've changed autoconf to 2.57 and automake to 1.7 - all the same. >Upgrading Apache to 1.3.29 doesn't affect this too. > >Found an interesting effect: >this bug appears only when I'm using Opera or Mozilla. >both lynx & wget browse ok =) > >Derick, please, take an attentive look at your patch to SAPI.c, SAPI.h, rfc1867.c, >php_variables.c (Sat Nov 29 10:24:35 2003) >- Fix sapi_input_filter patch. > >Reverting your patch fixes the problem, cause the problem seems to be in header >parsing routines. >Again, the problem is definitely in this patch. > >--- >WBR, >Antony Dovgal aka tony2001 >[EMAIL PROTECTED] > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
On Mon, 1 Dec 2003, Sebastian Bergmann wrote: >Jani Taskinen wrote: >> Was there some script to go with this..? > > Maybe this is related to the problem with PHP's logos I posted earlier? Eh? What logos? (either I'm getting senile or I'm not getting some mails) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [FIX] Bug #25585: PHP crash if executed MSSQL-query with RAISERROR() call and error 515
This does not fix the problem.
mssql_query is designed to stop fetching for each result. Use
mssql_next_result() to move the internal pointer to the nex result and
process the data.
I have tested the code provided with the bug report and it works as I
expect (no crash).
- Frank
> I believe the problem here is in how mssql_query handles result sets
> that have multiple results returned, but none with rows (such as in
> this bug where there are multiple commands executed and multiple errors
> returned). In the php_mssql.c for PHP 4.3.4 the block at line 1145
> reads:
>
> while ((num_fields = dbnumcols(mssql_ptr->link)) <= 0 && retvalue ==
> SUCCEED) {
> retvalue = dbresults(mssql_ptr->link);
> }
>
> According to Microsoft
> (http://msdn.microsoft.com/library/en-us/dblibc/dbc_pdc04e_52sz.asp),
> however:
>
> "You must call dbresults until it returns NO_MORE_RESULTS, or
> any continued use of the DBPROCESS causes the DB-Library error
> 10038 'Results Pending'."
>
> As this code in php_mssql.c currently stands it stops looping the empty
> result sets too early becuase it's looking for SUCCEED instead of
> NO_MORE_RESULTS. Changing this code to:
>
> while ((num_fields = dbnumcols(mssql_ptr->link)) <= 0 && retvalue !=
> NO_MORE_RESULTS) {
> retvalue = dbresults(mssql_ptr->link);
> }
>
> causes both SQL Server error messages generated by the sample query in
> the bug report to be correctly displayed and eliminates the fault.
>
> Michael Sisolak
> [EMAIL PROTECTED]
>
>
> __
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
Jani Taskinen wrote: > Eh? What logos? Current HEAD built as Debug_TS on Windows 2000: http://wopr/index.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 Fatal error: Possible integer overflow in memory allocation (2 * -858993460 + 1) in Unknown on line 0 -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory (solved?)
On Mon, 1 Dec 2003, Antony Dovgal wrote: > On Mon, 1 Dec 2003 18:21:33 +0100 > "John Huntjens" <[EMAIL PROTECTED]> wrote: > > > > Now trying on a second machine: > > > Linux 2.4.18 > > > gcc-3.3 > > > autoconf 2.57 > > > automake 1.7 > > > libtool 1.5 > > > Apache 2.0.48 > > > > On this machine build is OK > > I've changed autoconf to 2.57 and automake to 1.7 - all the same. > Upgrading Apache to 1.3.29 doesn't affect this too. > > Found an interesting effect: > this bug appears only when I'm using Opera or Mozilla. > both lynx & wget browse ok =) > > Derick, please, take an attentive look at your patch to SAPI.c, SAPI.h, rfc1867.c, > php_variables.c (Sat Nov 29 10:24:35 2003) > - Fix sapi_input_filter patch. > > Reverting your patch fixes the problem, cause the problem seems to be in header > parsing routines. > Again, the problem is definitely in this patch. Hmm, interesting. But I'll need to have abetter 'bug' report before I can do anything about it as things work just fine for me... Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory (solved?)
Derick, looking at the code it looks like we are checking for the a= case and handling that correctly, but not the =a case. As in foo.com?a= vs foo.com?=a Not sure if it is yours or my bug. Currently in India and the connection here is too damn slow to browse through cvs. -Rasmus On Mon, 1 Dec 2003, Derick Rethans wrote: > On Mon, 1 Dec 2003, Antony Dovgal wrote: > > > On Mon, 1 Dec 2003 18:21:33 +0100 > > "John Huntjens" <[EMAIL PROTECTED]> wrote: > > > > > > Now trying on a second machine: > > > > Linux 2.4.18 > > > > gcc-3.3 > > > > autoconf 2.57 > > > > automake 1.7 > > > > libtool 1.5 > > > > Apache 2.0.48 > > > > > > On this machine build is OK > > > > I've changed autoconf to 2.57 and automake to 1.7 - all the same. > > Upgrading Apache to 1.3.29 doesn't affect this too. > > > > Found an interesting effect: > > this bug appears only when I'm using Opera or Mozilla. > > both lynx & wget browse ok =) > > > > Derick, please, take an attentive look at your patch to SAPI.c, SAPI.h, rfc1867.c, > > php_variables.c (Sat Nov 29 10:24:35 2003) > > - Fix sapi_input_filter patch. > > > > Reverting your patch fixes the problem, cause the problem seems to be in header > > parsing routines. > > Again, the problem is definitely in this patch. > > Hmm, interesting. But I'll need to have abetter 'bug' report before I > can do anything about it as things work just fine for me... > > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory (solved?)
On Mon, 1 Dec 2003, Rasmus Lerdorf wrote: > Derick, looking at the code it looks like we are checking for the a= case > and handling that correctly, but not the =a case. As in foo.com?a= vs > foo.com?=a That is something I did not touch, but I found the problem which caused this...forgot to change the default sapi input filter handler to return new_val_len. I'll have a look at the =a case (what should this do?) later. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Sun, Nov 30, 2003 at 01:10:25AM +0200, Andi Gutmans wrote: > The strict was introduced so that we can add warnings about practices we > recommend and deprecated behavior. > I think "var" belongs there. > We could remove E_STRICT from E_ALL (although that'd be a bit hacky) and > save ppl the trouble of seeing these warnings. Again, turning off E_STRICT stops people from seeing major deprication issues. Declaring a class variable via "var" vs "public" is not a major deprication problem at this point in time. E_STRICT is creating a major problem. Pepole who provide classes for public consumption -- and there are a lot of us out here -- would be forced to maintain/distribute two branches of code: one using var for PHP 4 users, one using strict for PHP 5 users. All I can say is "PLEASE don't make this scenario come true." --Dan -- FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/ T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory (solved?)
On Mon, 1 Dec 2003, Derick Rethans wrote: > On Mon, 1 Dec 2003, Rasmus Lerdorf wrote: > > > Derick, looking at the code it looks like we are checking for the a= case > > and handling that correctly, but not the =a case. As in foo.com?a= vs > > foo.com?=a > > That is something I did not touch, but I found the problem which caused > this...forgot to change the default sapi input filter handler to return > new_val_len. I'll have a look at the =a case (what should this do?) It should skip the variable. -R -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Summary of string conversion problem
IMHO, think that __toString should be explicitly
called as in java. Sure it would be great if it works
when using print, echo, etc, mean that cases when its
obvious that should evaluate to string. But ALL other
cases should be evaluated only explicitly. Maybe using
a diferent syntax for that as (string)$obj or (s)$obj
or $obj{}
And the best example is the one Andi wrote:
> > c) $arr[$obj] would suddenly work according the
> __toString().
> I remember this being requested as a feature anyway
> ;-)
I think this is a big problem. How would we retrieve
the object from an array when that object has defined
a __toString() method?
Specifying casting ??? like $arr[(obj)$obj] ???
$arr[(str)$obj]
I think it wasn´t the PHP pourpose, but wouldn´t be
bad
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
At 02:37 PM 12/1/2003 -0500, Daniel Convissor wrote: On Sun, Nov 30, 2003 at 01:10:25AM +0200, Andi Gutmans wrote: > The strict was introduced so that we can add warnings about practices we > recommend and deprecated behavior. > I think "var" belongs there. > We could remove E_STRICT from E_ALL (although that'd be a bit hacky) and > save ppl the trouble of seeing these warnings. Again, turning off E_STRICT stops people from seeing major deprication issues. Declaring a class variable via "var" vs "public" is not a major deprication problem at this point in time. E_STRICT is creating a major problem. Pepole who provide classes for public consumption -- and there are a lot of us out here -- would be forced to maintain/distribute two branches of code: one using var for PHP 4 users, one using strict for PHP 5 users. All I can say is "PLEASE don't make this scenario come true." I don't quite understand the problem. E_STRICT was only meant for people who really want to be pedantic. I think we can make it not part of E_ALL. Is that OK? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32 time.c
Does this mean I can enable my GetLongPathName() patch in tsrm_virtual_cwd.c (I think it also requires Win98 but I kept it out because there are people who are still using Windows 95). I think we decided that we will continue supporting Windows 95 and I #If 0'd my patch. Also, I just saw (and fixed the indentation) of some realpath() implementation in tsrm_win32.c. Any reason for me not to nuke it? I think my code is better or is it being used throughout PHP? If so, we should probably use something similar to my implementation using GetLongPathName(). Thoughts? Andi At 10:59 PM 11/29/2003 +, Wez Furlong wrote: wez Sat Nov 29 17:59:34 2003 EDT Modified files: /php-src/win32 time.c Log: Fix build for new usleep implementation. NB: we now depend on windows 98 and later; windows 95 does not have these timing functions. Index: php-src/win32/time.c diff -u php-src/win32/time.c:1.7 php-src/win32/time.c:1.8 --- php-src/win32/time.c:1.7Sat Nov 29 17:48:42 2003 +++ php-src/win32/time.cSat Nov 29 17:59:33 2003 @@ -11,7 +11,7 @@ * */ -/* $Id: time.c,v 1.7 2003/11/29 22:48:42 wez Exp $ */ +/* $Id: time.c,v 1.8 2003/11/29 22:59:33 wez Exp $ */ /** * @@ -22,9 +22,14 @@ /* Include stuff */ +/* this allows the use of the WaitableTimer functions. + * For win98 and later */ +#define _WIN32_WINNT 0x400 + #include "time.h" #include "unistd.h" #include "signal.h" +#include #include #include #include @@ -131,7 +136,7 @@ HANDLE timer; LARGE_INTEGER due; - due.QuadPart = -useconds * 1000; + due.QuadPart = -1000 * useconds; timer = CreateWaitableTimer(NULL, TRUE, NULL); SetWaitableTimer(timer, &due, 0, NULL, NULL, 0); -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Mon, Dec 01, 2003 at 10:15:46PM +0200, Andi Gutmans wrote: > > I don't quite understand the problem. E_STRICT was only meant for people > who really want to be pedantic. I think we can make it not part of E_ALL. > Is that OK? Better. The only drawback is people who do want to be pedantic will get flooded by tons of warnings about var rather than being able to focus on real problems. Guess I'M being pedantic. :) --Dan -- FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/ T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
At 03:32 PM 12/1/2003 -0500, Daniel Convissor wrote: On Mon, Dec 01, 2003 at 10:15:46PM +0200, Andi Gutmans wrote: > > I don't quite understand the problem. E_STRICT was only meant for people > who really want to be pedantic. I think we can make it not part of E_ALL. > Is that OK? Better. The only drawback is people who do want to be pedantic will get flooded by tons of warnings about var rather than being able to focus on real problems. Guess I'M being pedantic. :) If they'd like to keep var then they aren't pedantic :) I'm sure that even with big apps doing a search and replacing var with public will take no more than half an hour. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy & PHP5
> before bundling i'd like to see the api refined... > > right now it's not possible to work with more than one html-doc at a > time. (tidy_parse_file() does not return a resource to the internal > tidy doc, so you can only have one doc at a time) Yes, Thies is right here! But s/resource/object :) I don't know the tidy api very well, but wouldn't be the normal way to have an object for a Document (which was created by tidyCreate) instead to use a global value for? So you can work with multiple documents, and you also can add additional (userland) functionality. This would be the "normal" behaviour for new php5 extensions (simplexml, sqlite, mysqli, mono, ...). Just my 0,024$ Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32 time.c
I'm not sure if we should whole-heartedly abandon win95; I'd love to, I'm just not sure. CGI/FastCGI sapi will only run under NT and later (because of the named pipe stuff). For the people running PHP in a web server, this shouldn't be a problem (who would be mad enough to run '95 as a server anyway? ;-) I think the question is how many people use php under 95? (for gtk?) Do we *need* to support win95 in PHP 5? My preference is to say good riddance to it, as doing so allows us to implement these missing features and catch up with the unix version. --Wez. - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: "Wez Furlong" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, December 01, 2003 8:23 PM Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32 time.c > Does this mean I can enable my GetLongPathName() patch in > tsrm_virtual_cwd.c (I think it also requires Win98 but I kept it out > because there are people who are still using Windows 95). I think we > decided that we will continue supporting Windows 95 and I #If 0'd my patch. > Also, I just saw (and fixed the indentation) of some realpath() > implementation in tsrm_win32.c. Any reason for me not to nuke it? I think > my code is better or is it being used throughout PHP? If so, we should > probably use something similar to my implementation using GetLongPathName(). > > Thoughts? > Andi > > At 10:59 PM 11/29/2003 +, Wez Furlong wrote: > >wez Sat Nov 29 17:59:34 2003 EDT > > > > Modified files: > > /php-src/win32 time.c > > Log: > > Fix build for new usleep implementation. > > NB: we now depend on windows 98 and later; > > windows 95 does not have these timing functions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
Hello Stanislav,
Monday, December 1, 2003, 5:51:20 PM, you wrote:
> AMT>> Are we discussing this feature's technical or aesthetic merits? Or
> AMT>> both?
> Technical.
> AMT>> foreach ($dom->getElementsByTagname('person') as $person) {
> AMT>> list($firstname) =
> $person->getElementsByTagname('firstname');
> AMT>> $firstname_text_value = $firstname->firstChild->nodeValue;
> AMT>> }
> AMT>>
> AMT>> Compare that to:
> AMT>>
> AMT>> foreach($s->person as $person) {
> AMT>> $firstname_text_value = $person->firstname;
> AMT>> }
> AMT>>
> AMT>> You tell me which one "nobody can understand."
> Both can be understood, but in the first case you know wat is going on (so
> you can rely on $s->person being array and you would be able to do:
> $elements = $dom->getElementsByTagname('person');
> do_something_with($elements[0]);
> and in the second case there's so much magic you don't know what the hell
> is really going on. That's OK when you need to do just that, that stops to
> be OK when you want to slightly modify the behaviour and discover the
> magic is tightly coupled with particular case of use. For example, what
> exactly is $person->firstname there? Tag, or some attribute, or contents?
> What is $s->person - is it list of all tags with name 'person' contained
> in $s or is it element with ID 'person' in $s or maybe it is 'person'
> attribute of tag $s? How can I see it from that code? I can't.
print($xml->iWant->ToHave->TheFirstName->OfThisPerson());
Yeah that looks pretty stupid...
print($xml->Person->element["Name"]->Attributes["First"]);
or was it
print($xml->Person->element["Name"]->First->__toString);
i don't know!
Thats's the place SimpleXML was designed for. To allow you to write
easy code that does the object binding automatically:
print($xml->Person->Name->First);
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
