# Make primitive type names reserved words (Was: Re: [RFC] 5.4 features for vote (long)) - Thread: https://externals.io/message/53797 - Original archive: https://news-web.php.net/php.internals/53797 - Started by Patrick ALLAERT on 2011-07-10T16:41:10+00:00 - Messages: 36 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/53797.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53797 — Patrick ALLAERT — 2011-07-10T16:41:10+00:00 URL: https://externals.io/message/53797#53797 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] --- ## #53798 — Sammy Moshe — 2011-07-10T16:57:38+00:00 URL: https://externals.io/message/53797#53798 · In reply to: #53797 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 : > > [snip] > > > […] > form > > […] > > 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] --- ## #53801 — Nikita Popov — 2011-07-10T17:41:10+00:00 URL: https://externals.io/message/53797#53801 · In reply to: #53797 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 --- ## #53804 — Stas Malyshev — 2011-07-10T19:44:47+00:00 URL: https://externals.io/message/53797#53804 · In reply to: #53797 Hi! > 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 --- ## #53805 — Stas Malyshev — 2011-07-10T19:50:51+00:00 URL: https://externals.io/message/53797#53805 · In reply to: #53801 Hi! > 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 --- ## #53809 — Pierre Joye — 2011-07-10T21:17:13+00:00 URL: https://externals.io/message/53797#53809 · In reply to: #53797 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, > 2011/6/17 Stas Malyshev : > > [snip] > > > […] > > 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] > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53810 — Ferenc Kovacs — 2011-07-10T21:24:59+00:00 URL: https://externals.io/message/53797#53810 · In reply to: #53809 > 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 --- ## #53812 — Pierre Joye — 2011-07-10T21:38:42+00:00 URL: https://externals.io/message/53797#53812 · In reply to: #53810 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, > > > […] > > 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 --- ## #53833 — Jan Schneider — 2011-07-11T08:15:00+00:00 URL: https://externals.io/message/53797#53833 · In reply to: #53810 Zitat von Ferenc Kovacs : > > > […] > > 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/ --- ## #53839 — Pierre Joye — 2011-07-11T08:26:49+00:00 URL: https://externals.io/message/53797#53839 · In reply to: #53833 > > Zitat von Ferenc Kovacs : > > > […] > > 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, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53874 — Matthew Weier O'Phinney — 2011-07-11T15:08:43+00:00 URL: https://externals.io/message/53797#53874 · In reply to: #53804 > > > […] > > 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 --- ## #53878 — Ferenc Kovacs — 2011-07-11T15:14:23+00:00 URL: https://externals.io/message/53797#53878 · In reply to: #53874 On Mon, Jul 11, 2011 at 5:08 PM, Matthew Weier O'Phinney wrote: > > > […] > > 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 --- ## #53891 — Patrick ALLAERT — 2011-07-11T20:21:11+00:00 URL: https://externals.io/message/53797#53891 · In reply to: #53878 2011/7/11 Ferenc Kovacs : > On Mon, Jul 11, 2011 at 5:08 PM, Matthew Weier O'Phinney [snip] > > […] 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 --- ## #53911 — johannes@schlueters.de — 2011-07-12T08:48:17+00:00 URL: https://externals.io/message/53797#53911 · In reply to: #53801 > 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: 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 --- ## #53912 — Pierre Joye — 2011-07-12T09:09:33+00:00 URL: https://externals.io/message/53797#53912 · In reply to: #53797 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, > 2011/6/17 Stas Malyshev : > > [snip] > > > […] > > 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] > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53914 — Ivan Enderlin @ Hoa — 2011-07-12T10:07:40+00:00 URL: https://externals.io/message/53797#53914 · In reply to: #53912 > 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? > > > […] > > -- 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/ --- ## #53915 — Ferenc Kovacs — 2011-07-12T10:12:16+00:00 URL: https://externals.io/message/53797#53915 · In reply to: #53914 > > 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 --- ## #53916 — Ivan Enderlin @ Hoa — 2011-07-12T10:37:02+00:00 URL: https://externals.io/message/53797#53916 · In reply to: #53915 > > […] > 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/ --- ## #53917 — Jan Schneider — 2011-07-12T11:16:53+00:00 URL: https://externals.io/message/53797#53917 · In reply to: #53839 Zitat von Pierre Joye : > > > […] > > 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/ --- ## #53918 — Bruno CHALOPIN — 2011-07-12T12:35:27+00:00 URL: https://externals.io/message/53797#53918 · In reply to: #53912 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. 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 --- ## #53919 — Matthew Weier O'Phinney — 2011-07-12T14:18:13+00:00 URL: https://externals.io/message/53797#53919 · In reply to: #53911 > > > […] > > For a method this is correct. But for a normal function this is > different: > > 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 --- ## #53920 — David Soria Parra — 2011-07-12T18:02:57+00:00 URL: https://externals.io/message/53797#53920 · In reply to: #53912 > 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 --- ## #53927 — Hannes Magnusson — 2011-07-13T16:35:30+00:00 URL: https://externals.io/message/53797#53927 · In reply to: #53920 > > > […] > > > 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 --- ## #53928 — Stas Malyshev — 2011-07-13T16:41:44+00:00 URL: https://externals.io/message/53797#53928 · In reply to: #53927 Hi! > 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 --- ## #53929 — Philip Olson — 2011-07-13T16:51:03+00:00 URL: https://externals.io/message/53797#53929 · In reply to: #53927 > > > […] > > > 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 --- Next page: https://externals.io/message/53797.md?page=2