FAQ

Derick Rethans schrieb:
derick Sat Oct 15 08:54:20 2005 EDT

Modified files:
/php-src NEWS
/ZendEngine2 zend_compile.c
Log:
- Changed type hints so that they take "= NULL" as default value.
It would be great if this could be merged to PHP_5_1 after PHP 5.1.0 is
out.

--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Search Discussions

  • Andi Gutmans at Oct 16, 2005 at 12:11 am
    Hey Marcus, Derick,

    After the millions of discussions on this topic it would have been
    better to share this patch with everyone before commiting.
    In any case, as I could never think of a better syntax to deal with
    the somewhat harmless ambiguity of default value and "allowing" null,
    I don't mind having this patch. It should be documented though that
    this syntax comes to serve both purposes.
    I do suggest though, that you perfect the patch to make sure that
    using values other than null is a compile-time error and not only
    caught at run-time. I'm talking about the following function decleration:

    function testNull(MyClass $obj = 1) {
    }

    Thanks,
    Andi
    At 05:54 AM 10/15/2005, Derick Rethans wrote:
    derick Sat Oct 15 08:54:20 2005 EDT

    Modified files:
    /php-src NEWS
    /ZendEngine2 zend_compile.c
    Log:
    - Changed type hints so that they take "= NULL" as default value.


    http://cvs.php.net/diff.php/php-src/NEWS?r1=1.2069&r2=1.2070&ty=u
    Index: php-src/NEWS
    diff -u php-src/NEWS:1.2069 php-src/NEWS:1.2070
    --- php-src/NEWS:1.2069 Mon Oct 3 08:07:19 2005
    +++ php-src/NEWS Sat Oct 15 08:54:18 2005
    @@ -2,6 +2,8 @@
    ?? ??? ????, PHP 6.0
    - Unicode support. (Andrei, Dmitriy, et al)
    +- Changed type hints so that they take "= NULL" as default value. (Marcus,
    + Derick)
    - Changed __toString() behavior to call it in all necessary places
    (Marcus, Dmitry)
    - Changed "instanceof" and "catch" operators, is_a() and is_subclass_of()
    http://cvs.php.net/diff.php/ZendEngine2/zend_compile.c?r1=1.667&r2=1.668&ty=u
    Index: ZendEngine2/zend_compile.c
    diff -u ZendEngine2/zend_compile.c:1.667 ZendEngine2/zend_compile.c:1.668
    --- ZendEngine2/zend_compile.c:1.667 Mon Oct 10 06:50:35 2005
    +++ ZendEngine2/zend_compile.c Sat Oct 15 08:54:19 2005
    @@ -17,7 +17,7 @@
    +----------------------------------------------------------------------+
    */

    -/* $Id: zend_compile.c,v 1.667 2005/10/10 10:50:35 dmitry Exp $ */
    +/* $Id: zend_compile.c,v 1.668 2005/10/15 12:54:19 derick Exp $ */

    #include <zend_language_parser.h>
    #include "zend.h"
    @@ -1337,7 +1337,7 @@
    cur_arg_info->class_name = NULL;
    cur_arg_info->class_name_len = 0;
    }
    - cur_arg_info->allow_null = 0;
    + cur_arg_info->allow_null = (op == ZEND_RECV_INIT &&
    (Z_TYPE(initialization->u.constant) == IS_NULL ||
    (Z_TYPE(initialization->u.constant) == IS_CONSTANT &&
    !strcasecmp(Z_STRVAL(initialization->u.constant), "NULL")))) ? 1 : 0;
    } else {
    cur_arg_info->class_name = NULL;
    cur_arg_info->class_name_len = 0;

    --
    Zend Engine CVS Mailing List (http://cvs.php.net/)
    To unsubscribe, visit: http://www.php.net/unsub.php

    Zend/PHP Conference & Expo
    Power Your Business with PHP
    October 18-21, 2005 - San Francisco
    http://zend.kbconferences.com/
  • Derick Rethans at Oct 16, 2005 at 12:23 am
    Hello Andi,
    On Sat, 15 Oct 2005, Andi Gutmans wrote:

    After the millions of discussions on this topic it would have been better to
    share this patch with everyone before commiting.
    I did, last week:
    http://news.php.net/php.internals/19482
    In any case, as I could never think of a better syntax to deal with the
    somewhat harmless ambiguity of default value and "allowing" null, I don't mind
    having this patch. It should be documented though that this syntax comes to
    serve both purposes.
    I do suggest though, that you perfect the patch to make sure that using values
    other than null is a compile-time error and not only caught at run-time. I'm
    talking about the following function decleration:

    function testNull(MyClass $obj = 1) {
    }
    Yes, that would make sense. I'll have a look at that.

    regards,
    Derick
  • Andi Gutmans at Oct 16, 2005 at 12:28 am
    Ouch, I missed that. Sorry.
    At 05:23 PM 10/15/2005, Derick Rethans wrote:
    Hello Andi,
    On Sat, 15 Oct 2005, Andi Gutmans wrote:

    After the millions of discussions on this topic it would have
    been better to
    share this patch with everyone before commiting.
    I did, last week:
    http://news.php.net/php.internals/19482
    In any case, as I could never think of a better syntax to deal with the
    somewhat harmless ambiguity of default value and "allowing" null,
    I don't mind
    having this patch. It should be documented though that this syntax comes to
    serve both purposes.
    I do suggest though, that you perfect the patch to make sure that
    using values
    other than null is a compile-time error and not only caught at
    run-time. I'm
    talking about the following function decleration:

    function testNull(MyClass $obj = 1) {
    }
    Yes, that would make sense. I'll have a look at that.

    regards,
    Derick

    --
    Derick Rethans
    http://derickrethans.nl | http://ez.no | http://xdebug.org

    Zend/PHP Conference & Expo
    Power Your Business with PHP
    October 18-21, 2005 - San Francisco
    http://zend.kbconferences.com/
  • Derick Rethans at Oct 16, 2005 at 9:41 pm

    On Sun, 16 Oct 2005, Derick Rethans wrote:

    In any case, as I could never think of a better syntax to deal with the
    somewhat harmless ambiguity of default value and "allowing" null, I don't mind
    having this patch. It should be documented though that this syntax comes to
    serve both purposes.
    I do suggest though, that you perfect the patch to make sure that using values
    other than null is a compile-time error and not only caught at run-time. I'm
    talking about the following function decleration:

    function testNull(MyClass $obj = 1) {
    }
    Yes, that would make sense. I'll have a look at that.
    And it doesn't work in unicode=on mode yet... this is another piece of
    code that will need to get two branches :I

    Derick
  • Sebastian Bergmann at Oct 16, 2005 at 9:15 pm

    Andi Gutmans schrieb:
    I'm talking about the following function decleration:

    function testNull(MyClass $obj = 1) {
    }
    The following should work, too, to allow optional, type-hinted Array
    parameters:

    function someMethod(Array $array = array()) {
    }

    --
    Sebastian Bergmann http://www.sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Derick Rethans at Oct 16, 2005 at 9:28 pm

    On Sun, 16 Oct 2005, Sebastian Bergmann wrote:

    Andi Gutmans schrieb:
    I'm talking about the following function decleration:

    function testNull(MyClass $obj = 1) {
    }
    The following should work, too, to allow optional, type-hinted Array
    parameters:

    function someMethod(Array $array = array()) {
    }
    That seems to work fine already:

    derick@kossu:/dat/dev/php/php-6.0dev$ cat /tmp/test.php
    <?php
    class P { }
    class T {
    function f(array $p = array()) {
    var_dump($p);
    }
    }

    $o=new T();
    $o->f();
    ?>
    derick@kossu:/dat/dev/php/php-6.0dev$ sapi/cli/php
    -derror_reporting=8191 /tmp/test.php
    array(0) {
    }

    regards,
    Derick
  • Sebastian Bergmann at Oct 17, 2005 at 3:33 am

    Derick Rethans schrieb:
    That seems to work fine already
    Even better :-)

    --
    Sebastian Bergmann http://www.sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Jani Taskinen at Oct 16, 2005 at 6:04 pm

    On Sat, 15 Oct 2005, Sebastian Bergmann wrote:
    Derick Rethans schrieb:
    derick Sat Oct 15 08:54:20 2005 EDT

    Modified files:
    /php-src NEWS
    /ZendEngine2 zend_compile.c
    Log:
    - Changed type hints so that they take "= NULL" as default value.
    It would be great if this could be merged to PHP_5_1 after PHP 5.1.0 is
    out.
    So you're proposing that PHP_5_1 branch will be PHP_5_2 branch then?

    --Jani
  • Sebastian Bergmann at Oct 16, 2005 at 7:01 pm

    Jani Taskinen schrieb:
    So you're proposing that PHP_5_1 branch will be PHP_5_2 branch then?
    No, I am proposing to have this change in PHP 5.1.1, as it is too late
    to have it in PHP 5.1.0.

    --
    Sebastian Bergmann http://www.sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Jani Taskinen at Oct 16, 2005 at 7:39 pm

    On Sun, 16 Oct 2005, Sebastian Bergmann wrote:
    Jani Taskinen schrieb:
    So you're proposing that PHP_5_1 branch will be PHP_5_2 branch then?
    No, I am proposing to have this change in PHP 5.1.1, as it is too late
    to have it in PHP 5.1.0.
    It's not a bugfix. So it can't be in a bugfix release..or have
    we changed the rules again? :)

    --Jani
  • Sebastian Bergmann at Oct 16, 2005 at 7:49 pm

    Jani Taskinen schrieb:
    So it can't be in a bugfix release.
    I can wish, right? :-)

    Too bad we're already this far along in the RC for PHP 5.1.0,
    Sebastian

    --
    Sebastian Bergmann http://www.sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Derick Rethans at Oct 16, 2005 at 8:20 pm

    On Sun, 16 Oct 2005, Jani Taskinen wrote:
    On Sun, 16 Oct 2005, Sebastian Bergmann wrote:


    Jani Taskinen schrieb:
    So you're proposing that PHP_5_1 branch will be PHP_5_2 branch then?
    No, I am proposing to have this change in PHP 5.1.1, as it is too late
    to have it in PHP 5.1.0.
    It's not a bugfix. So it can't be in a bugfix release..or have
    we changed the rules again? :)
    We can consider it as a bugfix, IMO the current typehints are "broken".

    Derick
  • Jani Taskinen at Oct 16, 2005 at 8:30 pm
    On Sun, 16 Oct 2005, Derick Rethans wrote:
    On Sun, 16 Oct 2005, Jani Taskinen wrote:
    On Sun, 16 Oct 2005, Sebastian Bergmann wrote:


    Jani Taskinen schrieb:
    So you're proposing that PHP_5_1 branch will be PHP_5_2 branch then?
    No, I am proposing to have this change in PHP 5.1.1, as it is too late
    to have it in PHP 5.1.0.
    It's not a bugfix. So it can't be in a bugfix release..or have
    we changed the rules again? :)
    We can consider it as a bugfix, IMO the current typehints are "broken".
    Then you should MFH to PHP_5_1, NOW.

    --Jani
  • Derick Rethans at Oct 16, 2005 at 8:33 pm

    On Sun, 16 Oct 2005, Jani Taskinen wrote:
    On Sun, 16 Oct 2005, Derick Rethans wrote:

    On Sun, 16 Oct 2005, Jani Taskinen wrote:
    On Sun, 16 Oct 2005, Sebastian Bergmann wrote:


    Jani Taskinen schrieb:
    So you're proposing that PHP_5_1 branch will be PHP_5_2 branch then?
    No, I am proposing to have this change in PHP 5.1.1, as it is too late
    to have it in PHP 5.1.0.
    It's not a bugfix. So it can't be in a bugfix release..or have
    we changed the rules again? :)
    We can consider it as a bugfix, IMO the current typehints are "broken".
    Then you should MFH to PHP_5_1, NOW.
    Yeah, after I address Andi's comments tomorrow - and pending Ilia's
    approval.

    Derick
  • Antony Dovgal at Oct 16, 2005 at 8:35 pm

    On 17.10.2005 00:30, Jani Taskinen wrote:
    On Sun, 16 Oct 2005, Derick Rethans wrote:

    On Sun, 16 Oct 2005, Jani Taskinen wrote:
    On Sun, 16 Oct 2005, Sebastian Bergmann wrote:


    Jani Taskinen schrieb:
    So you're proposing that PHP_5_1 branch will be PHP_5_2 branch then?
    No, I am proposing to have this change in PHP 5.1.1, as it is too late
    to have it in PHP 5.1.0.
    It's not a bugfix. So it can't be in a bugfix release..or have
    we changed the rules again? :)
    We can consider it as a bugfix, IMO the current typehints are "broken".
    Then you should MFH to PHP_5_1, NOW.
    Amen.

    --
    Wbr,
    Antony Dovgal
  • Jani Taskinen at Oct 16, 2005 at 8:37 pm
    Sorry for preaching to the choir.

    --Jani

    On Mon, 17 Oct 2005, Antony Dovgal wrote:

    On 17.10.2005 00:30, Jani Taskinen wrote:
    On Sun, 16 Oct 2005, Derick Rethans wrote:

    On Sun, 16 Oct 2005, Jani Taskinen wrote:
    On Sun, 16 Oct 2005, Sebastian Bergmann wrote:


    Jani Taskinen schrieb:
    So you're proposing that PHP_5_1 branch will be PHP_5_2 branch then?
    No, I am proposing to have this change in PHP 5.1.1, as it is too late
    to have it in PHP 5.1.0.
    It's not a bugfix. So it can't be in a bugfix release..or have
    we changed the rules again? :)
    We can consider it as a bugfix, IMO the current typehints are "broken".
    Then you should MFH to PHP_5_1, NOW.
    Amen.
    --
    Give me your money at @ <http://pecl.php.net/wishlist.php/sniper>
    Donating money may make me happier and friendlier for a limited period!
    Death to all 4 letter abbreviations starting with P!
  • Sebastian Bergmann at Oct 22, 2005 at 9:52 am

    Antony Dovgal schrieb:
    We can consider it as a bugfix, IMO the current typehints are
    "broken".
    Then you should MFH to PHP_5_1, NOW.
    Amen.
    Did we reach a conclusion here? I talked to Derick the other day and he
    said "maybe" for PHP 5.1.1, but not for PHP 5.1.0 because we're so far
    along in its RC phase.

    Either way, PHP 5.1.0 or PHP 5.1.1, is fine by me, although I'd prefer
    having it in PHP 5.1.0 so as not to change behaviour (even though it is
    a bugfix) in a PHP 5.1.X release. But I am happy as long as I do not
    have to wait until PHP 6 for this ;-)

    --
    Sebastian Bergmann http://www.sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 15, '05 at 1:30p
activeOct 22, '05 at 9:52a
posts18
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase