RC1 of RC1

Jan Lehnardt

22 years ago

Hi,
On 15 Mar 2004, at 7:10, Andi Gutmans wrote:

> 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/

Andi Gutmans

22 years ago

At 08:40 AM 3/15/2004 +0100, Jan Lehnardt wrote:

>Hi,
>On 15 Mar 2004, at 7:10, Andi Gutmans wrote:
>>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

Jan Schneider

22 years ago

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

Andi Gutmans

22 years ago

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:

Jan Schneider

22 years ago

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

Hans Lellelid

22 years ago

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

Andi Gutmans

22 years ago

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

Luna Kid

22 years ago

"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

Marcus Börger

22 years ago

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

Luna Kid

22 years ago

> > 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

Timm Friebe

22 years ago

On Mon, 2004-03-15 at 07:10, Andi Gutmans 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

Marcus Börger

22 years ago

Hello Timm,

this is fixed now.

marcus

Tuesday, March 16, 2004, 9:39:09 PM, you wrote:

> On Mon, 2004-03-15 at 07:10, Andi Gutmans 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

Timm Friebe

22 years ago

On Tue, 2004-03-16 at 22:28, Marcus Boerger wrote:

> Hello Timm,
>
> this is fixed now.

Verified.

- Timm

Clemens Gutweiler

22 years ago

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

Andi Gutmans

22 years ago

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:

Hans Lellelid

22 years ago

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

22 years ago

Nope. The final decision was to only check this during E_STRICT because
there's no reason why inheritance should be different from implementation.
People here felt that due to PHP not supporting function overloading we
should not be very strict, and therefore, only give this warning in E_STRICT.
I don't want to reopen this decision because as you can see in the
archives, it was a long thread :)
Andi

At 07:16 AM 3/17/2004 -0500, Hans Lellelid wrote:

Hans Lellelid

22 years ago

Andi Gutmans wrote:

> Nope. The final decision was to only check this during E_STRICT
> because there's no reason why inheritance should be different from
> implementation. People here felt that due to PHP not supporting
> function overloading we should not be very strict, and therefore, only
> give this warning in E_STRICT.
> I don't want to reopen this decision because as you can see in the
> archives, it was a long thread :)

Absolutely, agree about re-opening.  Ok -- just wanted to check & make
sure I understood (so that code wouldn't break again, etc.).  This makes
sense to me; early on I was one of the people (maybe the only one,
actually) saying that extending interfaces should be allowed to override
signatures.  While many people wanted to stone me for that heresy, it's
the same principle -- that because PHP doesn't support overloading
things like that are necessary.

Thanks,
Hans

Sebastian Bergmann

22 years ago

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/