# RC1 of RC1 - Thread: https://externals.io/message/8516 - Original archive: https://news-web.php.net/php.internals/8516 - Started by Andi Gutmans on 2004-03-15T06:10:10+00:00 - Messages: 19 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #8516 — Andi Gutmans — 2004-03-15T06:10:10+00:00 URL: https://externals.io/message/8516#8516 Hey, I rolled RC1 of RC1 (didn't change the version from -dev on purpose because RC1RC1 is kind of odd and I didn't want it to confuse people :). I will roll RC1 on the 17th so if there are "serious" show stoppers speak up. The .tar.gz/.tar.bz2 are available at http://snaps.php.net/~andi Edin, can you put up Windows binaries someplace (the tag is php_5_0_0RC1RC1). Andi --- ## #8517 — Jan Lehnardt — 2004-03-15T07:40:52+00:00 URL: https://externals.io/message/8516#8517 · In reply to: #8516 Hi, > The .tar.gz/.tar.bz2 are available at http://snaps.php.net/~andi if I understood correctly, we'll be providing two packages, once 5.0.0 is released. One with libxml2 bundled and one without; shouldn't we begin with that at RC stage? regards, Jan -- GPG Key: BB96 56B0 Q: Thank Jan? - A: http://geschenke.an.dasmoped.net/ --- ## #8518 — Andi Gutmans — 2004-03-15T11:41:42+00:00 URL: https://externals.io/message/8516#8518 · In reply to: #8516 At 08:40 AM 3/15/2004 +0100, Jan Lehnardt wrote: >Hi, > > > […] > >if I understood correctly, we'll be providing two packages, once >5.0.0 is released. One with libxml2 bundled and one without; >shouldn't we begin with that at RC stage? Yeah, I think that would be a nice idea. However, it does require tweaking of makedist and the build, the latter I am not sure I would want to do so close to the RC. If someone has a nice way of doing it which we can easily check over the next couple of days then speak up :) Andi --- ## #8520 — Jan Schneider — 2004-03-15T12:52:37+00:00 URL: https://externals.io/message/8516#8520 · In reply to: #8516 Zitat von Andi Gutmans : > I will roll RC1 on the 17th so if there are "serious" show stoppers speak up. Dunno what you consider "serious", but bug 26666 http://bugs.php.net/bug.php?id=26666 is on the ze2 level. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft --- ## #8521 — Andi Gutmans — 2004-03-15T13:06:34+00:00 URL: https://externals.io/message/8516#8521 · In reply to: #8516 I fixed `get_object_vars()` a couple of days ago. Can you check if this still occurs? Andi At 01:52 PM 3/15/2004 +0100, Jan Schneider wrote: >Zitat von Andi Gutmans : > > > […] > >Dunno what you consider "serious", but bug 26666 >http://bugs.php.net/bug.php?id=26666 is on the ze2 level. > >Jan. > >-- >http://www.horde.org - The Horde Project >http://www.ammma.de - Neue Wege des Lernens >http://www.tip4all.de - Deine private Tippgemeinschaft --- ## #8522 — Jan Schneider — 2004-03-15T13:29:59+00:00 URL: https://externals.io/message/8516#8522 · In reply to: #8521 Zitat von Andi Gutmans : > I fixed `get_object_vars()` a couple of days ago. Can you check if this still > occurs? No, that seems to have fixed it, thanks! > At 01:52 PM 3/15/2004 +0100, Jan Schneider wrote: > > […] Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft --- ## #8523 — Hans Lellelid — 2004-03-15T15:07:29+00:00 URL: https://externals.io/message/8516#8523 · In reply to: #8516 I notice that in the new RC1, the following reference to class constants is no longer possible: class MyClass { const MY_CONST = 1; function __construct() { echo MY_CONST; } } You must now use self::MY_CONST to reference the class constant. While I can see that the pre-RC1 behavior would not provide a way to access global constant if class had const of same name ... I figured I'd ask anyway whether this change is intended or a side-effect of some other fix. I fall into the category of people who were really enjoying not having to specify self:: before (so now I have a lot of code to fix, apparently). Thanks- Hans --- ## #8524 — Andi Gutmans — 2004-03-15T15:41:17+00:00 URL: https://externals.io/message/8516#8524 · In reply to: #8516 At 10:07 AM 3/15/2004 -0500, Hans Lellelid wrote: >I notice that in the new RC1, the following reference to class constants >is no longer possible: > >class MyClass { > const MY_CONST = 1; > function __construct() { > echo MY_CONST; > } >} > >You must now use self::MY_CONST to reference the class constant. While I >can see that the pre-RC1 behavior would not provide a way to access global >constant if class had const of same name ... I figured I'd ask anyway >whether this change is intended or a side-effect of some other fix. I >fall into the category of people who were really enjoying not having to >specify self:: before (so now I have a lot of code to fix, apparently). Hey, I fixed it intentionally. That piece of code was left over from the days of our broken namespaces implementation where we would do two lookups. Methods were fixed a long time ago but we forgot to remove the old code from constants. Andi --- ## #8543 — Timm Friebe — 2004-03-16T20:39:09+00:00 URL: https://externals.io/message/8516#8543 · In reply to: #8516 > Hey, > > I rolled RC1 of RC1 (didn't change the version from -dev on purpose because > RC1RC1 is kind of odd and I didn't want it to confuse people :). > I will roll RC1 on the 17th so if there are "serious" show stoppers speak up. thekid@friebes:~/devel/php/tests > cat ob.php thekid@friebes:~/devel/php/tests > php-dev ob.php Segmentation fault (core dumped) Program received signal SIGSEGV, Segmentation fault. 0x8252e24 in zend_call_function (fci=0xbfbff63c, fci_cache=0x0, tsrm_ls=0x8389050) at /usr/home/thekid/devel/php/php/Zend/zend_execute_API.c:648 /usr/home/thekid/devel/php/php/Zend/zend_execute_API.c:648:19515:beg:0x8252e24 (gdb) bt #0 0x8252e24 in zend_call_function (fci=0xbfbff63c, fci_cache=0x0, tsrm_ls=0x8389050) at /usr/home/thekid/devel/php/php/Zend/zend_execute_API.c:648 #1 0x82528b7 in call_user_function_ex (function_table=0x839c2c0, object_pp=0x0, function_name=0x83b3658, retval_ptr_ptr=0xbfbff710, param_count=2, params=0xbfbff6c0, no_separation=1, symbol_table=0x0, tsrm_ls=0x8389050) at /usr/home/thekid/devel/php/php/Zend/zend_execute_API.c:546 #2 0x821bce9 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0 '\000', tsrm_ls=0x8389050) at /usr/home/thekid/devel/php/php/main/output.c:240 #3 0x821c3ef in php_end_ob_buffers (send_buffer=1 '\001', tsrm_ls=0x8389050) at /usr/home/thekid/devel/php/php/main/output.c:336 #4 0x820a474 in php_request_shutdown (dummy=0x0) at /usr/home/thekid/devel/php/php/main/main.c:1195 #5 0x82953cc in main (argc=2, argv=0xbfbffa80) at /usr/home/thekid/devel/php/php/sapi/cli/php_cli.c:1046 - Timm --- ## #8545 — Marcus Boerger — 2004-03-16T21:28:02+00:00 URL: https://externals.io/message/8516#8545 · In reply to: #8543 Hello Timm, this is fixed now. marcus Tuesday, March 16, 2004, 9:39:09 PM, you wrote: > > > […] > thekid@friebes:~/devel/php/tests > cat ob.php > class test { > function output($buf) { > return $buf; > } > } > ob_start(array('test', 'output')); ?>> > thekid@friebes:~/devel/php/tests > php-dev ob.php > Segmentation fault (core dumped) > Program received signal SIGSEGV, Segmentation fault. > 0x8252e24 in zend_call_function (fci=0xbfbff63c, fci_cache=0x0, > tsrm_ls=0x8389050) at > /usr/home/thekid/devel/php/php/Zend/zend_execute_API.c:648 > /usr/home/thekid/devel/php/php/Zend/zend_execute_API.c:648:19515:beg:0x8252e24 > (gdb) bt > #0 0x8252e24 in zend_call_function (fci=0xbfbff63c, fci_cache=0x0, > tsrm_ls=0x8389050) at > /usr/home/thekid/devel/php/php/Zend/zend_execute_API.c:648 > #1 0x82528b7 in call_user_function_ex (function_table=0x839c2c0, > object_pp=0x0, function_name=0x83b3658, retval_ptr_ptr=0xbfbff710, > param_count=2, params=0xbfbff6c0, no_separation=1, symbol_table=0x0, > tsrm_ls=0x8389050) at > /usr/home/thekid/devel/php/php/Zend/zend_execute_API.c:546 > #2 0x821bce9 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0 > '\000', tsrm_ls=0x8389050) at > /usr/home/thekid/devel/php/php/main/output.c:240 > #3 0x821c3ef in php_end_ob_buffers (send_buffer=1 '\001', > tsrm_ls=0x8389050) at /usr/home/thekid/devel/php/php/main/output.c:336 > #4 0x820a474 in php_request_shutdown (dummy=0x0) at > /usr/home/thekid/devel/php/php/main/main.c:1195 > #5 0x82953cc in main (argc=2, argv=0xbfbffa80) at > /usr/home/thekid/devel/php/php/sapi/cli/php_cli.c:1046 > - Timm -- Best regards, Marcus mailto:helly@php.net --- ## #8546 — Timm Friebe — 2004-03-16T21:30:49+00:00 URL: https://externals.io/message/8516#8546 · In reply to: #8545 > Hello Timm, > > this is fixed now. Verified. - Timm --- ## #8554 — Clemens Gutweiler — 2004-03-17T10:57:51+00:00 URL: https://externals.io/message/8516#8554 · In reply to: #8516 Hi, > From: Andi Gutmans [mailto:andi@zend.com] > I rolled RC1 of RC1 (didn't change the version from -dev on > purpose because > RC1RC1 is kind of odd and I didn't want it to confuse people :). > I will roll RC1 on the 17th so if there are "serious" show > stoppers speak up. wakeup( 'monday' ); ?> Shouldn't this throw an fatal error because wakeup isn't complete implemented? Current HEAD: $ /usr/local/php-5-fastcgi-200303171147/bin/php -f /web/finalconstruct.php wake up on monday Clemens --- ## #8555 — Andi Gutmans — 2004-03-17T11:10:52+00:00 URL: https://externals.io/message/8516#8555 · In reply to: #8516 Only if you use E_STRICT. There was a long discussion about this on internals@ a few weeks ago. At 11:57 AM 3/17/2004 +0100, Clemens Gutweiler wrote: >Hi, > > > […] > > > […] > > > interface person { > function wakeup( $day, $time ); > } > > class hugo implements person { > function wakeup( $day ) { > printf( "wake up on $day\n" ); > } > } > > $hugo = new hugo; > $hugo->wakeup( 'monday' ); > >?> > >Shouldn't this throw an fatal error because wakeup isn't complete >implemented? > >Current HEAD: > >$ /usr/local/php-5-fastcgi-200303171147/bin/php -f >/web/finalconstruct.php >wake up on monday > >Clemens --- ## #8556 — Hans Lellelid — 2004-03-17T12:16:01+00:00 URL: https://externals.io/message/8516#8556 · In reply to: #8555 Hi - Andi Gutmans wrote: > Only if you use E_STRICT. There was a long discussion about this on > internals@ a few weeks ago. > > At 11:57 AM 3/17/2004 +0100, Clemens Gutweiler wrote: > > > […] I must have missed / mis-understood the final decision on that. I would have also expected that this code would still be raising E_FATAL. I thought that the decision to not enforce strict signatures was for class inheritance (becuase of common practice of overriding parent signatures in PHP4), but that interfaces would enforce signatures (but might allow for additional optional params in methods of implementing classes). Hans --- ## #8599 — Sebastian Bergmann — 2004-03-19T09:42:18+00:00 URL: https://externals.io/message/8516#8599 · In reply to: #8555 Andi Gutmans wrote: > Only if you use E_STRICT. Am I missing something (bear with me, I am still on medication :-) but the following code does not print a warning here: -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ --- ## #8600 — Derick Rethans — 2004-03-19T09:48:04+00:00 URL: https://externals.io/message/8516#8600 > Andi Gutmans wrote: > > […] > > Am I missing something (bear with me, I am still on medication :-) but > the following code does not print a warning here: Because E_Strict is set at run time, and the warnings are thrown at compile time :) Derick --- ## #8807 — Luna Kid — 2004-03-28T16:56:00+00:00 URL: https://externals.io/message/8516#8807 · In reply to: #8524 "Andi Gutmans" wrote in message news:5.1.0.14.2.20040315174015.0a198dd0@127.0.0.1... > At 10:07 AM 3/15/2004 -0500, Hans Lellelid wrote: > > […] > ... > I fixed it intentionally. That piece of code was left over from the days of > our broken namespaces implementation where we would do two lookups. Methods > were fixed a long time ago but we forgot to remove the old code from constants. > > Andi Well, I guess there is no easy solution, but anyhow, this is still very unfortunate. The basic "Don't Repeat Yourself" (or "DRY") principle, which could forunately eliminate the function Classname() { // constructor syntax replacing it with the much cleaner and saner __construct (THANKS!!!), now fails to prevent creeping in of another sort of harmful hardcoded redundancy to our code... I'd say I'd rather pay the price of any double lookup any day than loading my code with useless duplication of information. As a cheap and effective compromise, would that be a possible to introduce something like a __thisclass keyword so that those of us who are concerned about code duplication could avoid this newly introduced unnecessary repeating of class names when qualifying consts within the defining class? This way (writing __thisclass::MYCONST instead of MyParticularClassName::CONST we could freely decide to favor clean style, or performance, depending on the specific situation. Whichever way, thanks very much for your efforts, guys! The Luna Kid --- ## #8808 — Marcus Boerger — 2004-03-28T17:10:50+00:00 URL: https://externals.io/message/8516#8808 · In reply to: #8807 Hello Luna, Sunday, March 28, 2004, 6:56:00 PM, you wrote: > "Andi Gutmans" wrote in message > news:5.1.0.14.2.20040315174015.0a198dd0@127.0.0.1... > > […] > Well, I guess there is no easy solution, but anyhow, this is still very unfortunate. > The basic "Don't Repeat Yourself" (or "DRY") principle, which could forunately > eliminate the > function Classname() { // constructor > syntax replacing it with the much cleaner and saner __construct (THANKS!!!), > now fails to prevent creeping in of another sort of harmful hardcoded redundancy > to our code... > I'd say I'd rather pay the price of any double lookup any day than loading my code > with useless duplication of information. > As a cheap and effective compromise, would that be a possible to introduce something > like a > __thisclass > keyword so that those of us who are concerned about code duplication could avoid > this newly introduced unnecessary repeating of class names when qualifying consts > within the defining class? > This way (writing __thisclass::MYCONST instead of MyParticularClassName::CONST > we could freely decide to favor clean style, or performance, depending on the specific > situation. No need for that we have 'self': php -r 'class c { const c="Hello\n"; static function f() { return self::c; }} echo c::f();' -- Best regards, Marcus mailto:helly@php.net --- ## #8810 — Luna Kid — 2004-03-28T17:21:29+00:00 URL: https://externals.io/message/8516#8810 · In reply to: #8808 > > […] > > No need for that we have 'self': > php -r 'class c { const c="Hello\n"; static function f() { return self::c; }} echo c::f();' Yoohoo!!! Wonderful, thanks! :) (Dunno how I could miss this, but who cares now that PHP is PERFECT... :) ) Cheers, Lunatic