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
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/
At 08:40 AM 3/15/2004 +0100, Jan Lehnardt wrote:
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?
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
Zitat von Andi Gutmans andi@zend.com:
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
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 andi@zend.com:
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
Zitat von Andi Gutmans andi@zend.com:
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:
Zitat von Andi Gutmans andi@zend.com:
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
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
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
"Andi Gutmans" andi@zend.com 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:
...
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).
...
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
Hello Luna,
Sunday, March 28, 2004, 6:56:00 PM, you wrote:
"Andi Gutmans" andi@zend.com 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:
...
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).
...
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.
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
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();'
Yoohoo!!! Wonderful, thanks! :)
(Dunno how I could miss this, but who cares now that PHP is PERFECT... :) )
Cheers,
Lunatic
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
<?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
Hello Timm,
this is fixed now.
marcus
Tuesday, March 16, 2004, 9:39:09 PM, you wrote:
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
<?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
Hello Timm,
this is fixed now.
Verified.
- Timm
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.
<?php
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
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,
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.<?php
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 mondayClemens
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:
<?php
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?
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
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:
<?php
error_reporting(E_STRICT);
interface Testable {
public function test($a, $b);
}
class Test implements Testable {
public function test($a) {
}
}
?>
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/