FAQ
2011/6/17 Stas Malyshev [snip]
2. Make primitive type names reserved words (in case we ever want some form
of scalar typing or anything else with scalar types). Using them as
identifiers would return parse error for now. May have BC implications.
I am not sure it is a good idea to make them reserved words without a
clear reason for doing so.

I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:

namespace \Types {
class Int {
// ...
}
class Float {
// ...
}
class String {
// ...
}
// ...
}

Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?

I would be +1 if this could be done for the global namespace only.
However, -1 if this would break the usage of classes like \Types\Int,
\Types\String, ... would break.

Please, rethink your vote taking this into account. I don't think it
is required to hurry up on that decision while we still don't have a
*clear* proposition for scalar type hinting.

Cheers,
Patrick

[snip]

Search Discussions

  • Sammy Moshe at Jul 10, 2011 at 4:57 pm
    There's going to be a ton of code in the wild that will break if primitive
    types become reserved words.
    On Sun, Jul 10, 2011 at 11:41 AM, Patrick ALLAERT wrote:

    2011/6/17 Stas Malyshev <smalyshev@sugarcrm.com>:

    [snip]
    2. Make primitive type names reserved words (in case we ever want some form
    of scalar typing or anything else with scalar types). Using them as
    identifiers would return parse error for now. May have BC implications.
    I am not sure it is a good idea to make them reserved words without a
    clear reason for doing so.

    I'm sure some projects have defined classes with those keywords in
    some namespace (to ensure they wouldn't conflict with possible PHP
    built-in stuff) like in:

    namespace \Types {
    class Int {
    // ...
    }
    class Float {
    // ...
    }
    class String {
    // ...
    }
    // ...
    }

    Developer may have taken care of defining them in a specific
    namespace, would it be possible to not break their application while
    making them reserved keywords in the global namespace only?

    I would be +1 if this could be done for the global namespace only.
    However, -1 if this would break the usage of classes like \Types\Int,
    \Types\String, ... would break.

    Please, rethink your vote taking this into account. I don't think it
    is required to hurry up on that decision while we still don't have a
    *clear* proposition for scalar type hinting.

    Cheers,
    Patrick

    [snip]

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Nikita Popov at Jul 10, 2011 at 5:41 pm
    Well, I generally think that PHP should be less strict about reserved
    keywords. The number
    of reserved keywords increases with every further release of PHP. For
    example PHP 5.4
    introduces "trait" and "insteadof". PHP 5.3 introduced even more. Every new
    keyword PHP
    introduces both breaks old code and reduces the naming possibilities for
    classes and methods.

    I don't think that it's possible to refrain from adding further keywords.
    The language grows and
    with it the list of keywords.

    But I do think that it should be possible to prevent these additions from
    breaking old code or
    restricting userland naming.

    E.g. Writing

    class Evaluator {
    public function eval() {

    }
    }

    Does in no way create an ambiguity with the eval language construct PHP
    implements.

    But still PHP doesn't allow writing the above code. It would make sense to
    allow the
    use of the keyword in such situations. Actually PHP already does this in one
    place:
    The token after T_OPJECT_OPERATOR is never interpreted as a keyword. I.e.
    one can
    write $this->eval() (and define a magic __call method for 'eval').

    I don't know whether this is actually possible, but I've at least already
    seen a patch
    (http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname case
    linked
    from a feature request (https://bugs.php.net/bug.php?id=28261).

    MfG Nikita
  • Stas Malyshev at Jul 10, 2011 at 7:50 pm
    Hi!
    On 7/10/11 10:41 AM, Nikita Popov wrote:
    I don't know whether this is actually possible, but I've at least
    already seen a patch
    (http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname
    case linked
    from a feature request (https://bugs.php.net/bug.php?id=28261).
    If this patch indeed works, I don't see why we couldn't add it. Needs to
    be extensively checked, but if it works - why not?
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Lars Strojny at Jul 10, 2011 at 9:38 pm
    Very good find of an inconsistency. Does the testsuite reveal something
    strange with that patch?

    Am 10.07.11 19:41 schrieb "Nikita Popov" unter <nikita.ppv@googlemail.com>:
    Well, I generally think that PHP should be less strict about reserved
    keywords. The number
    of reserved keywords increases with every further release of PHP. For
    example PHP 5.4
    introduces "trait" and "insteadof". PHP 5.3 introduced even more. Every
    new
    keyword PHP
    introduces both breaks old code and reduces the naming possibilities for
    classes and methods.

    I don't think that it's possible to refrain from adding further keywords.
    The language grows and
    with it the list of keywords.

    But I do think that it should be possible to prevent these additions from
    breaking old code or
    restricting userland naming.

    E.g. Writing

    class Evaluator {
    public function eval() {

    }
    }

    Does in no way create an ambiguity with the eval language construct PHP
    implements.

    But still PHP doesn't allow writing the above code. It would make sense to
    allow the
    use of the keyword in such situations. Actually PHP already does this in
    one
    place:
    The token after T_OPJECT_OPERATOR is never interpreted as a keyword. I.e.
    one can
    write $this->eval() (and define a magic __call method for 'eval').

    I don't know whether this is actually possible, but I've at least already
    seen a patch
    (http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname
    case
    linked
    from a feature request (https://bugs.php.net/bug.php?id=28261).

    MfG Nikita
  • Nikita Popov at Jul 10, 2011 at 9:51 pm

    On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny wrote:
    Very good find of an inconsistency. Does the testsuite reveal something
    strange with that patch?

    I didn't test that patch, just found it in the bugtracker.
    cellog@php.net would be a better person to ask, as he wrote it. But
    just from glancing at it I could imagine that it would break
    token_get_all() as CG(active_class_entry) wouldn't be set
    appropriately (though that's just a guess).

    MfG Nikita
  • Lars Strojny at Jul 10, 2011 at 10:36 pm
    Hi everybody,

    Attached is the patch against current trunk with a testcase, tokenizer
    tests do not break. If nobody objects, could somebody with commit access
    to Zend could commit this patch?

    With regards,
    Lars

    Am 10.07.11 23:51 schrieb "Nikita Popov" unter <nikita.ppv@googlemail.com>:
    On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny wrote:

    Very good find of an inconsistency. Does the testsuite reveal something
    strange with that patch?

    I didn't test that patch, just found it in the bugtracker.
    cellog@php.net would be a better person to ask, as he wrote it. But
    just from glancing at it I could imagine that it would break
    token_get_all() as CG(active_class_entry) wouldn't be set
    appropriately (though that's just a guess).

    MfG Nikita

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Lars Strojny at Jul 10, 2011 at 10:39 pm
    And again, as .txt

    Am 11.07.11 00:36 schrieb "Lars Strojny" unter <lars@strojny.net>:
    Hi everybody,

    Attached is the patch against current trunk with a testcase, tokenizer
    tests do not break. If nobody objects, could somebody with commit access
    to Zend could commit this patch?

    With regards,
    Lars

    Am 10.07.11 23:51 schrieb "Nikita Popov" unter
    <nikita.ppv@googlemail.com>:
    On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny wrote:

    Very good find of an inconsistency. Does the testsuite reveal something
    strange with that patch?

    I didn't test that patch, just found it in the bugtracker.
    cellog@php.net would be a better person to ask, as he wrote it. But
    just from glancing at it I could imagine that it would break
    token_get_all() as CG(active_class_entry) wouldn't be set
    appropriately (though that's just a guess).

    MfG Nikita

    --
    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
  • Felipe Pena at Jul 10, 2011 at 10:43 pm

    2011/7/10 Lars Strojny <lars@strojny.net>:
    Hi everybody,

    Attached is the patch against current trunk with a testcase, tokenizer
    tests do not break. If nobody objects, could somebody with commit access
    to Zend could commit this patch?
    Wait, wait.

    Tokenizer surely is broken, it will identify a method name 'include'
    as T_INCLUDE.

    --
    Regards,
    Felipe Pena
  • Felipe Pena at Jul 10, 2011 at 10:42 pm
    Hi,

    2011/7/10 Nikita Popov <nikita.ppv@googlemail.com>:
    On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny wrote:

    Very good find of an inconsistency. Does the testsuite reveal something
    strange with that patch?

    I didn't test that patch, just found it in the bugtracker.
    cellog@php.net would be a better person to ask, as he wrote it. But
    just from glancing at it I could imagine that it would break
    token_get_all() as CG(active_class_entry) wouldn't be set
    appropriately (though that's just a guess).
    Yes, you are right. We cannot rely on CG(active_class_entry) data.

    I'm against this patch, because we will just add more inconsistency.
    Allow reserved words in method name, OK. But what about class
    name/namespace name etc?

    And in the begin of thread the topic was type name as class name,
    nothing to do with methods.

    --
    Regards,
    Felipe Pena
  • Lars Strojny at Jul 10, 2011 at 10:50 pm
    Hi Felipe,

    Am 11.07.11 00:41 schrieb "Felipe Pena" unter <felipensp@gmail.com>:
    I'm against this patch, because we will just add more inconsistency.
    Allow reserved words in method name, OK. But what about class
    name/namespace name etc?
    Good argument, namespace names and class names should be treated similar.
    Would you object a patch doing it for class names, interface names and
    namespaces?

    With regards,
    Lars
  • Felipe Pena at Jul 10, 2011 at 11:08 pm
    Hi,

    2011/7/10 Lars Strojny <lars@strojny.net>:
    Hi Felipe,

    Am 11.07.11 00:41 schrieb "Felipe Pena" unter <felipensp@gmail.com>:
    I'm against this patch, because we will just add more inconsistency.
    Allow reserved words in method name, OK. But what about class
    name/namespace name etc?
    Good argument, namespace names and class names should be treated similar.
    Would you object a patch doing it for class names, interface names and
    namespaces?
    To handle the class name in a method call turn out tricky. For example:

    include::list();

    When matching 'include' we have to check if it's (ignoring whitespaces
    and comments) an 'include ".."', 'include(...)', 'include::'. This
    will require massive use of lookahead, which lead to handling trailing
    context in the scanner, for each current reserved words. It's not so
    simple.

    Using re2c we can to match 'include' only if followed by something
    using the r/s syntax, but this doesn't solve all. As the one could
    use: include /* foobar */ ::list() - and even being quite weird, it
    should keep working.

    Complexity++

    --
    Regards,
    Felipe Pena
  • Stas Malyshev at Jul 10, 2011 at 11:46 pm
    Hi!
    On 7/10/11 4:07 PM, Felipe Pena wrote:
    To handle the class name in a method call turn out tricky. For example:

    include::list();
    Agreed, class names would be trouble. Same with any token that can be
    first in the expression/statement. However, I think methods might be
    relatively safe, if we make tokenizer, etc. work properly.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Johannes Schlüter at Jul 12, 2011 at 8:48 am

    On Sun, 2011-07-10 at 19:41 +0200, Nikita Popov wrote:
    E.g. Writing

    class Evaluator {
    public function eval() {

    }
    }

    Does in no way create an ambiguity with the eval language construct PHP
    implements.
    For a method this is correct. But for a normal function this is
    different:

    <?php
    function eval() {
    }
    eval(); // will call the language construct
    ?>

    And i consider it "strange" to allow different names for functions and
    methods. And yes I'm aware that
    $eval = 'eval'; $eval();
    would call the function.

    I fear consistency issues.

    johannes
  • Matthew Weier O'Phinney at Jul 12, 2011 at 2:18 pm

    On 2011-07-12, Johannes Schlüter wrote:
    On Sun, 2011-07-10 at 19:41 +0200, Nikita Popov wrote:
    E.g. Writing

    class Evaluator {
    public function eval() {

    }
    }

    Does in no way create an ambiguity with the eval language construct
    PHP implements.
    For a method this is correct. But for a normal function this is
    different:

    <?php
    function eval() {
    }
    eval(); // will call the language construct
    ?>
    But what about this?

    namespace Foo
    {
    function eval($name)
    {
    echo $name;
    }

    eval('matthew');
    }

    The manual doesn't really differentiate between language constructs and
    functions, and as such, I can see somebody reading the namespace section
    of the manual and feeling this should be valid -- but currently, it
    results in a parse error.

    It seems to me we need a context-sensitive lexer.
    And i consider it "strange" to allow different names for functions and
    methods. And yes I'm aware that
    $eval = 'eval'; $eval();
    would call the function.

    I fear consistency issues.

    --
    Matthew Weier O'Phinney
    Project Lead | matthew@zend.com
    Zend Framework | http://framework.zend.com/
    PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
  • Stas Malyshev at Jul 10, 2011 at 7:44 pm
    Hi!
    On 7/10/11 9:41 AM, Patrick ALLAERT wrote:
    I'm sure some projects have defined classes with those keywords in
    some namespace (to ensure they wouldn't conflict with possible PHP
    built-in stuff) like in:

    namespace \Types {
    class Int {
    // ...
    }
    class Float {
    // ...
    }
    class String {
    // ...
    }
    // ...
    }
    We probably can do it so String is OK, but string is not. But yes, if we
    ever have scalar typing, it would conflict with such types I imagine.
    But this may be a problem for whoever would venture to create that
    patch, if it ever happens.
    Developer may have taken care of defining them in a specific
    namespace, would it be possible to not break their application while
    making them reserved keywords in the global namespace only?
    I don't think there's such thing in PHP as namespaced keywords. Keywords
    are processed by the language parser, which knows next to nothing of
    namespaces.
    We could, maybe, prohibit creation of classes with names identical to
    type names, which is different from making it reserved word, and on that
    stage we know the full class name.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Matthew Weier O'Phinney at Jul 11, 2011 at 3:08 pm

    On 2011-07-10, Stas Malyshev wrote:
    On 7/10/11 9:41 AM, Patrick ALLAERT wrote:
    Developer may have taken care of defining them in a specific
    namespace, would it be possible to not break their application while
    making them reserved keywords in the global namespace only?
    I don't think there's such thing in PHP as namespaced keywords. Keywords
    are processed by the language parser, which knows next to nothing of
    namespaces.
    We could, maybe, prohibit creation of classes with names identical to
    type names, which is different from making it reserved word, and on that
    stage we know the full class name.
    I think that's a bad idea. The point of namespaces is to allow us to
    override classes (and functions, and constants) within that namespace.
    If I can't do this:

    namespace Foo
    {
    class String
    {
    }
    }

    then I'd consider the implementation too restrictive.

    --
    Matthew Weier O'Phinney
    Project Lead | matthew@zend.com
    Zend Framework | http://framework.zend.com/
    PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
  • Ferenc Kovacs at Jul 11, 2011 at 3:14 pm

    On Mon, Jul 11, 2011 at 5:08 PM, Matthew Weier O'Phinney wrote:
    On 2011-07-10, Stas Malyshev wrote:
    On 7/10/11 9:41 AM, Patrick ALLAERT wrote:
    Developer may have taken care of defining them in a specific
    namespace, would it be possible to not break their application while
    making them reserved keywords in the global namespace only?
    I don't think there's such thing in PHP as namespaced keywords. Keywords
    are processed by the language parser, which knows next to nothing of
    namespaces.
    We could, maybe, prohibit creation of classes with names identical to
    type names, which is different from making it reserved word, and on that
    stage we know the full class name.
    I think that's a bad idea. The point of namespaces is to allow us to
    override classes (and functions, and constants) within that namespace.
    If I can't do this:

    namespace Foo
    {
    class String
    {
    }
    }

    then I'd consider the implementation too restrictive.
    the parser is a little bit dumb, and the namespaces isn't really first
    class citizens in php AFAIK, so it's not a deliberate restriction imo,
    just a technical, which could be solved.


    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Patrick ALLAERT at Jul 11, 2011 at 8:21 pm

    2011/7/11 Ferenc Kovacs <tyra3l@gmail.com>:
    On Mon, Jul 11, 2011 at 5:08 PM, Matthew Weier O'Phinney
    [snip]
    I think that's a bad idea. The point of namespaces is to allow us to
    override classes (and functions, and constants) within that namespace.
    If I can't do this:

    namespace Foo
    {
    class String
    {
    }
    }

    then I'd consider the implementation too restrictive.
    This is exactly my concern.
    the parser is a little bit dumb, and the namespaces isn't really first
    class citizens in php AFAIK, so it's not a deliberate restriction imo,
    just a technical, which could be solved.
    The parser being dumb wouldn't be a reason to make code which works
    fine on 5.3, break on 5.4 and then again working on 5.5 because of
    words being keyworded for the sake of "a future implementation" which
    doesn't explain whether it would break that kind of namespaced
    classes.

    Regards,
    Patrick
  • Derick Rethans at Jul 13, 2011 at 4:53 pm

    On Sun, 10 Jul 2011, Stas Malyshev wrote:

    Hi!
    On 7/10/11 9:41 AM, Patrick ALLAERT wrote:
    I'm sure some projects have defined classes with those keywords in
    some namespace (to ensure they wouldn't conflict with possible PHP
    built-in stuff) like in:

    namespace \Types {
    class Int {
    // ...
    }
    class Float {
    // ...
    }
    class String {
    // ...
    }
    // ...
    }
    We probably can do it so String is OK, but string is not.
    Are you suggesting to make class names case sensitive now? I don't think
    that that's what you meant, but it clearly shows that the "probably can"
    is "cannot" in your sentence above.

    cheers,
    Derick
  • Pierre Joye at Jul 10, 2011 at 9:17 pm
    hi,

    As I could agree on this fact, I can't find any existing project
    having int(eger), float&co as class, namespaced or not. Do you have
    any example at hand?

    Cheers,
    On Sun, Jul 10, 2011 at 6:41 PM, Patrick ALLAERT wrote:
    2011/6/17 Stas Malyshev <smalyshev@sugarcrm.com>:

    [snip]
    2. Make primitive type names reserved words (in case we ever want some form
    of scalar typing or anything else with scalar types). Using them as
    identifiers would return parse error for now. May have BC implications.
    I am not sure it is a good idea to make them reserved words without a
    clear reason for doing so.

    I'm sure some projects have defined classes with those keywords in
    some namespace (to ensure they wouldn't conflict with possible PHP
    built-in stuff) like in:

    namespace \Types {
    class Int {
    // ...
    }
    class Float {
    // ...
    }
    class String {
    // ...
    }
    // ...
    }

    Developer may have taken care of defining them in a specific
    namespace, would it be possible to not break their application while
    making them reserved keywords in the global namespace only?

    I would be +1 if this could be done for the global namespace only.
    However, -1 if this would break the usage of classes like \Types\Int,
    \Types\String, ... would break.

    Please, rethink your vote taking this into account. I don't think it
    is required to hurry up on that decision while we still don't have a
    *clear* proposition for scalar type hinting.

    Cheers,
    Patrick

    [snip]

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Ferenc Kovacs at Jul 10, 2011 at 9:25 pm

    On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye wrote:
    hi,

    As I could agree on this fact, I can't find any existing project
    having int(eger), float&co as class, namespaced or not. Do you have
    any example at hand?

    Cheers,
    https://github.com/search?type=Code&language=PHP&q=%22class+int%22&repo=&langOverride=&x=0&y=0&start_value=1

    not too many though.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Pierre Joye at Jul 10, 2011 at 9:38 pm
    ZF and ODM do it and inside namespace. We should be sure that these
    cases still work, as NS exists for this exact purpose.

    Cheers,
    On Sun, Jul 10, 2011 at 11:24 PM, Ferenc Kovacs wrote:
    On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye wrote:
    hi,

    As I could agree on this fact, I can't find any existing project
    having int(eger), float&co as class, namespaced or not. Do you have
    any example at hand?

    Cheers,
    https://github.com/search?type=Code&language=PHP&q=%22class+int%22&repo=&langOverride=&x=0&y=0&start_value=1

    not too many though.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Jan Schneider at Jul 11, 2011 at 8:15 am

    Zitat von Ferenc Kovacs <tyra3l@gmail.com>:
    On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye wrote:
    hi,

    As I could agree on this fact, I can't find any existing project
    having int(eger), float&co as class, namespaced or not. Do you have
    any example at hand?

    Cheers,
    https://github.com/search?type=Code&language=PHP&q=%22class+int%22&repo=&langOverride=&x=0&y=0&start_value=1

    not too many though.
    Try that for String and it reveals a different picture. Horde 3 used
    that too FWIW.

    Jan.

    --
    Do you need professional PHP or Horde consulting?
    http://horde.org/consulting/
  • Pierre Joye at Jul 11, 2011 at 8:26 am

    On Mon, Jul 11, 2011 at 10:15 AM, Jan Schneider wrote:
    Zitat von Ferenc Kovacs <tyra3l@gmail.com>:
    On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye <pierre.php@gmail.com>
    wrote:
    hi,

    As I could agree on this fact, I can't find any existing project
    having int(eger), float&co as class, namespaced or not. Do you have
    any example at hand?

    Cheers,

    https://github.com/search?type=Code&language=PHP&q=%22class+int%22&repo=&langOverride=&x=0&y=0&start_value=1

    not too many though.
    Try that for String and it reveals a different picture. Horde 3 used that
    too FWIW.

    Jan.
    Even the php5 versions of Horde? That's rather bad given the so strong
    and loud warnings we gave about using common names w/o namespace, by
    the time of the date problem.

    Cheers,
  • Jan Schneider at Jul 12, 2011 at 11:17 am

    Zitat von Pierre Joye <pierre.php@gmail.com>:
    On Mon, Jul 11, 2011 at 10:15 AM, Jan Schneider wrote:

    Zitat von Ferenc Kovacs <tyra3l@gmail.com>:
    On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye <pierre.php@gmail.com>
    wrote:
    hi,

    As I could agree on this fact, I can't find any existing project
    having int(eger), float&co as class, namespaced or not. Do you have
    any example at hand?

    Cheers,

    https://github.com/search?type=Code&language=PHP&q=%22class+int%22&repo=&langOverride=&x=0&y=0&start_value=1

    not too many though.
    Try that for String and it reveals a different picture. Horde 3 used that
    too FWIW.

    Jan.
    Even the php5 versions of Horde? That's rather bad given the so strong
    and loud warnings we gave about using common names w/o namespace, by
    the time of the date problem.
    No, of course not. That's why I didn't voice an opinion, I just found
    it worth mentioning. Horde 3 users can stick with PHP 5.3, while Horde
    4 users are not affected at all.

    It's still used in a lot of other code though, see the github search.

    Jan.

    --
    Do you need professional PHP or Horde consulting?
    http://horde.org/consulting/
  • Pierre Joye at Jul 12, 2011 at 9:09 am
    hi,

    As of now I do not think we should allow this change, whether the RFC
    is accepted or not does not matter as it will badly break BC. Unless
    there is a patch allowing this change without affecting existing code
    (main point being namespaced code working smoothly), this RFC should
    be rejected.

    Cheers,
    On Sun, Jul 10, 2011 at 6:41 PM, Patrick ALLAERT wrote:
    2011/6/17 Stas Malyshev <smalyshev@sugarcrm.com>:

    [snip]
    2. Make primitive type names reserved words (in case we ever want some form
    of scalar typing or anything else with scalar types). Using them as
    identifiers would return parse error for now. May have BC implications.
    I am not sure it is a good idea to make them reserved words without a
    clear reason for doing so.

    I'm sure some projects have defined classes with those keywords in
    some namespace (to ensure they wouldn't conflict with possible PHP
    built-in stuff) like in:

    namespace \Types {
    class Int {
    // ...
    }
    class Float {
    // ...
    }
    class String {
    // ...
    }
    // ...
    }

    Developer may have taken care of defining them in a specific
    namespace, would it be possible to not break their application while
    making them reserved keywords in the global namespace only?

    I would be +1 if this could be done for the global namespace only.
    However, -1 if this would break the usage of classes like \Types\Int,
    \Types\String, ... would break.

    Please, rethink your vote taking this into account. I don't think it
    is required to hurry up on that decision while we still don't have a
    *clear* proposition for scalar type hinting.

    Cheers,
    Patrick

    [snip]

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Ivan Enderlin @ Hoa at Jul 12, 2011 at 10:07 am

    On 12/07/11 11:09, Pierre Joye wrote:
    hi, Hi,
    As of now I do not think we should allow this change, whether the RFC
    is accepted or not does not matter as it will badly break BC. Unless
    there is a patch allowing this change without affecting existing code
    (main point being namespaced code working smoothly), this RFC should
    be rejected.
    With these new elements, I agree the fact that the RFC should be
    rejected. But maybe we can add new magic methods, such as: __toBool(),
    __toInt(), __toFloat() etc. User can use int(), float() etc. if he
    needs/wants to, and we are always able to do same things (e.g. adding
    future features).
    Moreover, PHP has a dynamic typing system. Having tokens as reserved
    keywords appears obviously logical to me, but why having type names as
    reserved keywords? Sounds like we do not assume our “type position”.
    That's why adding magic methods looks like a better way to solve this
    problem.

    Thougs?

    Best regards.


    PS: I cannot change my vote on https://wiki.php.net/todo/php54/vote, is
    it a known issue?
    On Sun, Jul 10, 2011 at 6:41 PM, Patrick ALLAERTwrote:
    2011/6/17 Stas Malyshev<smalyshev@sugarcrm.com>:

    [snip]
    2. Make primitive type names reserved words (in case we ever want some form
    of scalar typing or anything else with scalar types). Using them as
    identifiers would return parse error for now. May have BC implications.
    I am not sure it is a good idea to make them reserved words without a
    clear reason for doing so.

    I'm sure some projects have defined classes with those keywords in
    some namespace (to ensure they wouldn't conflict with possible PHP
    built-in stuff) like in:

    namespace \Types {
    class Int {
    // ...
    }
    class Float {
    // ...
    }
    class String {
    // ...
    }
    // ...
    }

    Developer may have taken care of defining them in a specific
    namespace, would it be possible to not break their application while
    making them reserved keywords in the global namespace only?

    I would be +1 if this could be done for the global namespace only.
    However, -1 if this would break the usage of classes like \Types\Int,
    \Types\String, ... would break.

    Please, rethink your vote taking this into account. I don't think it
    is required to hurry up on that decision while we still don't have a
    *clear* proposition for scalar type hinting.

    Cheers,
    Patrick

    [snip]

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    --
    Ivan Enderlin
    Developer of Hoa Framework
    http://hoa.42/ or http://hoa-project.net/

    Member of HTML and WebApps Working Group of W3C
    http://w3.org/
  • Ferenc Kovacs at Jul 12, 2011 at 10:12 am

    PS: I cannot change my vote on https://wiki.php.net/todo/php54/vote, is it a
    known issue?
    if you don't have @php.net account, or 'voting' group membership in
    the wiki, then you cannot vote, or change your vote.
    this change was made yesterday to fix the issue that the technical
    restriction for the voting in the wiki isn't in pair with our accepted
    voting RFC.
    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Ivan Enderlin @ Hoa at Jul 12, 2011 at 10:37 am

    On 12/07/11 12:12, Ferenc Kovacs wrote:
    PS: I cannot change my vote on https://wiki.php.net/todo/php54/vote, is it a
    known issue?
    if you don't have @php.net account, or 'voting' group membership in
    the wiki, then you cannot vote, or change your vote.
    this change was made yesterday to fix the issue that the technical
    restriction for the voting in the wiki isn't in pair with our accepted
    voting RFC.
    And how can I join the “voting” group :-) ?

    --
    Ivan Enderlin
    Developer of Hoa Framework
    http://hoa.42/ or http://hoa-project.net/

    Member of HTML and WebApps Working Group of W3C
    http://w3.org/
  • Bruno CHALOPIN at Jul 12, 2011 at 12:35 pm
    Hi,
    On Tue, 12 Jul 2011 11:09:33 +0200, Pierre Joye wrote:

    As of now I do not think we should allow this change, whether the RFC is
    accepted or not does not matter as it will badly break BC. Unless there
    is a patch allowing this change without affecting existing code (main
    point being namespaced code working smoothly), this RFC should be
    rejected.
    I agree with that. Perhaps the first step is to raise an E_NOTICE or
    E_STRICT and in the next major release, the E_PARSE.

    Cheers,
    Bruno
  • David Soria Parra at Jul 12, 2011 at 6:02 pm

    On 2011-07-12, Pierre Joye wrote:
    hi,

    As of now I do not think we should allow this change, whether the RFC
    is accepted or not does not matter as it will badly break BC. Unless
    there is a patch allowing this change without affecting existing code
    (main point being namespaced code working smoothly), this RFC should
    be rejected.

    Cheers,

    I think this change has too much of an impact on backward compatibility.
    As long as we don't have a concrete implementation, I think we should
    let string, int not be reserved words. Argumentes were already presented.

    ps.: Pierre you might want to consider changing your vote in the wiki
  • Hannes Magnusson at Jul 13, 2011 at 4:35 pm

    On Tue, Jul 12, 2011 at 20:02, David Soria Parra wrote:
    On 2011-07-12, Pierre Joye wrote:
    hi,

    As of now I do not think we should allow this change, whether the RFC
    is accepted or not does not matter as it will badly break BC. Unless
    there is a patch allowing this change without affecting existing code
    (main point being namespaced code working smoothly), this RFC should
    be rejected.

    Cheers,

    I think this change has too much of an impact on backward compatibility.
    As long as we don't have a concrete implementation, I think we should
    let string, int not be reserved words. Argumentes were already presented.

    ps.: Pierre you might want to consider changing your vote in the wiki

    This thread is an excellent example why attempting to reach consensus
    by discussing things is important.
    Voting should be considered as an desperate last resort, not the
    primary mechanism.

    http://producingoss.com/en/consensus-democracy.html has several very
    related points.

    -Hannes
  • Stas Malyshev at Jul 13, 2011 at 4:41 pm
    Hi!
    On 7/13/11 9:35 AM, Hannes Magnusson wrote:
    This thread is an excellent example why attempting to reach consensus
    by discussing things is important.
    Voting should be considered as an desperate last resort, not the
    primary mechanism.

    http://producingoss.com/en/consensus-democracy.html has several very
    related points.
    That was the idea, but the problem is people ignore discussions on the
    list and only wake up when vote is to be closed soon :)
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Philip Olson at Jul 13, 2011 at 4:51 pm

    On Jul 13, 2011, at 9:35 AM, Hannes Magnusson wrote:
    On Tue, Jul 12, 2011 at 20:02, David Soria Parra wrote:
    On 2011-07-12, Pierre Joye wrote:
    hi,

    As of now I do not think we should allow this change, whether the RFC
    is accepted or not does not matter as it will badly break BC. Unless
    there is a patch allowing this change without affecting existing code
    (main point being namespaced code working smoothly), this RFC should
    be rejected.

    Cheers,

    I think this change has too much of an impact on backward compatibility.
    As long as we don't have a concrete implementation, I think we should
    let string, int not be reserved words. Argumentes were already presented.

    ps.: Pierre you might want to consider changing your vote in the wiki

    This thread is an excellent example why attempting to reach consensus
    by discussing things is important.
    Voting should be considered as an desperate last resort, not the
    primary mechanism.

    http://producingoss.com/en/consensus-democracy.html has several very
    related points.
    And each topic deserves its own thread, whereas this [original] thread lumped 10 separate topics together.

    Regards,
    Philip
  • Pierre Joye at Jul 13, 2011 at 5:30 pm
    hi Hannes,

    On Wed, Jul 13, 2011 at 6:35 PM, Hannes Magnusson
    wrote:
    On Tue, Jul 12, 2011 at 20:02, David Soria Parra wrote:
    On 2011-07-12, Pierre Joye wrote:
    hi,

    As of now I do not think we should allow this change, whether the RFC
    is accepted or not does not matter as it will badly break BC. Unless
    there is a patch allowing this change without affecting existing code
    (main point being namespaced code working smoothly), this RFC should
    be rejected.

    Cheers,

    I think this change has too much of an impact on backward compatibility.
    As long as we don't have a concrete implementation, I think we should
    let string, int not be reserved words. Argumentes were already presented.

    ps.: Pierre you might want to consider changing your vote in the wiki

    This thread is an excellent example why attempting to reach consensus
    by discussing things is important.
    Voting should be considered as an desperate last resort, not the
    primary mechanism.

    http://producingoss.com/en/consensus-democracy.html has several very
    related points.
    I disagree and this exact issue shows that the voting and controlling
    is actually working well, very well. As it is covered by the two
    recently adopted RFCs.

    Cheers,
  • Rasmus Lerdorf at Jul 13, 2011 at 5:54 pm

    On 07/13/2011 10:30 AM, Pierre Joye wrote:
    I disagree and this exact issue shows that the voting and controlling
    is actually working well, very well. As it is covered by the two
    recently adopted RFCs.
    I'm not sure how you come to the conclusion that it is working well.
    This particular change is clearly not feasible for 5.4, yet the votes
    are 37-19 for doing it right now.

    -Rasmus
  • Pierre Joye at Jul 13, 2011 at 6:17 pm

    On Wed, Jul 13, 2011 at 7:53 PM, Rasmus Lerdorf wrote:
    On 07/13/2011 10:30 AM, Pierre Joye wrote:
    I disagree and this exact issue shows that the voting and controlling
    is actually working well, very well. As it is covered by the two
    recently adopted RFCs.
    I'm not sure how you come to the conclusion that it is working well.
    This particular change is clearly not feasible for 5.4, yet the votes
    are 37-19 for doing it right now.
    Maybe read my reply in this exact thread?

    I said that due the BC problem, discovered or discussed later, forces
    us to reject this RFC.

    Cheers,
  • Rasmus Lerdorf at Jul 13, 2011 at 6:35 pm

    On 07/13/2011 11:17 AM, Pierre Joye wrote:
    On Wed, Jul 13, 2011 at 7:53 PM, Rasmus Lerdorf wrote:
    On 07/13/2011 10:30 AM, Pierre Joye wrote:
    I disagree and this exact issue shows that the voting and controlling
    is actually working well, very well. As it is covered by the two
    recently adopted RFCs.
    I'm not sure how you come to the conclusion that it is working well.
    This particular change is clearly not feasible for 5.4, yet the votes
    are 37-19 for doing it right now.
    Maybe read my reply in this exact thread?

    I said that due the BC problem, discovered or discussed later, forces
    us to reject this RFC.
    What do you mean discovered or discussed later? Anybody who bothered to
    read the RFC should have seen the BC problem. It's not like it was
    hiding in small letters somewhere.

    And most of the other votes are unanimous which make them rather
    pointless as well.

    -Rasmus
  • Pierre Joye at Jul 13, 2011 at 6:50 pm

    On Wed, Jul 13, 2011 at 8:36 PM, Rasmus Lerdorf wrote:
    On 07/13/2011 11:17 AM, Pierre Joye wrote:
    On Wed, Jul 13, 2011 at 7:53 PM, Rasmus Lerdorf wrote:
    On 07/13/2011 10:30 AM, Pierre Joye wrote:
    I disagree and this exact issue shows that the voting and controlling
    is actually working well, very well. As it is covered by the two
    recently adopted RFCs.
    I'm not sure how you come to the conclusion that it is working well.
    This particular change is clearly not feasible for 5.4, yet the votes
    are 37-19 for doing it right now.
    Maybe read my reply in this exact thread?

    I said that due the BC problem, discovered or discussed later, forces
    us to reject this RFC.
    What do you mean discovered or discussed later? Anybody who bothered to
    read the RFC should have seen the BC problem. It's not like it was
    hiding in small letters somewhere.
    We have some issues here. One is that I can't find the RFC for this
    proposal. Many of these votes are made out of the 5.4 todos instead of
    having clear and obvious (as you wish) RFCs. That was a mistake. But
    that's a new thing, we are learning.

    However, while making these primitives keywords sounded like a good
    and easy step, not being able to use them inside a namespace is a not
    acceptable BC break. It was also not obvious that NS won't be
    supported.
    And most of the other votes are unanimous which make them rather
    pointless as well.
    Are you saying that widely approved thing are pointless or we could
    have foreseen the results for each of them? Better to have a vote and
    got a massive support than nothing and sit in the middle of nowhere
    forever.

    Cheers,
  • Rasmus Lerdorf at Jul 13, 2011 at 7:18 pm

    On 07/13/2011 11:50 AM, Pierre Joye wrote:
    Are you saying that widely approved thing are pointless or we could
    have foreseen the results for each of them? Better to have a vote and
    got a massive support than nothing and sit in the middle of nowhere
    forever.
    I'm saying that many of these in the past were handled by a, "Hey guys,
    any objections to adding E_STRICT to E_ALL in 5.4?" email which would
    get a couple of, "go for it" replies and no objections, followed by the
    change being committed. To me the voting is only needed when we have
    trouble reaching a quick consensus and not for every little thing.

    -Rasmus
  • Pierre Joye at Jul 13, 2011 at 7:23 pm

    On Wed, Jul 13, 2011 at 9:19 PM, Rasmus Lerdorf wrote:
    On 07/13/2011 11:50 AM, Pierre Joye wrote:
    Are you saying that widely approved thing are pointless or we could
    have foreseen the results for each of them? Better to have a vote and
    got a massive support than nothing and sit in the middle of nowhere
    forever.
    I'm saying that many of these in the past were handled by a, "Hey guys,
    any objections to adding E_STRICT to E_ALL in 5.4?" email which would
    get a couple of, "go for it" replies and no objections, followed by the
    change being committed. To me the voting is only needed when we have
    trouble reaching a quick consensus and not for every little thing.
    Yes, got it, they were rhetorical questions :). However doing it this
    way spares us time in the long run. While one or another proposal
    could get large and immediate adoption, it makes the whole thing
    clearer for the developers not following internals@ daily or to our
    users.
  • Rasmus Lerdorf at Jul 13, 2011 at 7:27 pm

    On 07/13/2011 12:23 PM, Pierre Joye wrote:
    On Wed, Jul 13, 2011 at 9:19 PM, Rasmus Lerdorf wrote:
    On 07/13/2011 11:50 AM, Pierre Joye wrote:
    Are you saying that widely approved thing are pointless or we could
    have foreseen the results for each of them? Better to have a vote and
    got a massive support than nothing and sit in the middle of nowhere
    forever.
    I'm saying that many of these in the past were handled by a, "Hey guys,
    any objections to adding E_STRICT to E_ALL in 5.4?" email which would
    get a couple of, "go for it" replies and no objections, followed by the
    change being committed. To me the voting is only needed when we have
    trouble reaching a quick consensus and not for every little thing.
    Yes, got it, they were rhetorical questions :). However doing it this
    way spares us time in the long run. While one or another proposal
    could get large and immediate adoption, it makes the whole thing
    clearer for the developers not following internals@ daily or to our
    users.
    Right, but these folks that don't follow the discussions are the same 37
    people who voted for the Primitives change. How is that helpful?

    I think a vote should be a big deal. Anything that comes up for a vote
    should have a healthy discussion and an extremely well-fleshed out RFC
    which includes both sides of the argument culled from the healthy
    discussion. And the voting page should heavily encourage people to
    actually read the RFC in its entirety before voting.

    -Rasmus
  • Pierre Joye at Jul 13, 2011 at 7:30 pm

    On Wed, Jul 13, 2011 at 9:28 PM, Rasmus Lerdorf wrote:

    Right, but these folks that don't follow the discussions are the same 37
    people who voted for the Primitives change. How is that helpful?
    Many of the votes there are not from developers. We have explained
    what happened earlier this week. I don't think it is necessary to
    discuss this problem again here as it is fixed (Tyrael implemented the
    voting ACL and is now used).
    I think a vote should be a big deal. Anything that comes up for a vote
    should have a healthy discussion and an extremely well-fleshed out RFC
    which includes both sides of the argument culled from the healthy
    discussion. And the voting page should heavily encourage people to
    actually read the RFC in its entirety before voting.
    Fully agreed and that's what the voting RFC says as well. And why I
    said that simple todos should not have been submitted to votes except
    those requiring RFC due to their complexity or whatever else.

    Cheers,
  • Pierre Joye at Jul 13, 2011 at 7:24 pm
    ah forgot to mention that indeed not all todos should have be done via
    a RFC, that would not help us, not at all. But the primitive one, for
    example, must have one.
    On Wed, Jul 13, 2011 at 9:19 PM, Rasmus Lerdorf wrote:
    On 07/13/2011 11:50 AM, Pierre Joye wrote:
    Are you saying that widely approved thing are pointless or we could
    have foreseen the results for each of them? Better to have a vote and
    got a massive support than nothing and sit in the middle of nowhere
    forever.
    I'm saying that many of these in the past were handled by a, "Hey guys,
    any objections to adding E_STRICT to E_ALL in 5.4?" email which would
    get a couple of, "go for it" replies and no objections, followed by the
    change being committed. To me the voting is only needed when we have
    trouble reaching a quick consensus and not for every little thing.

    -Rasmus


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Related Discussions

People

Translate

site design / logo © 2022 Grokbase