Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Tue, Jul 12, 2011 at 20:02, David Soria Parra d...@php.net wrote: On 2011-07-12, Pierre Joye pierre@gmail.com 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Jul 13, 2011, at 9:35 AM, Hannes Magnusson wrote: On Tue, Jul 12, 2011 at 20:02, David Soria Parra d...@php.net wrote: On 2011-07-12, Pierre Joye pierre@gmail.com 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
hi Hannes, On Wed, Jul 13, 2011 at 6:35 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, Jul 12, 2011 at 20:02, David Soria Parra d...@php.net wrote: On 2011-07-12, Pierre Joye pierre@gmail.com 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, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Wed, Jul 13, 2011 at 7:53 PM, Rasmus Lerdorf syst...@php.net 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, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On 07/13/2011 11:17 AM, Pierre Joye wrote: On Wed, Jul 13, 2011 at 7:53 PM, Rasmus Lerdorf syst...@php.net 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Wed, Jul 13, 2011 at 8:36 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/13/2011 11:17 AM, Pierre Joye wrote: On Wed, Jul 13, 2011 at 7:53 PM, Rasmus Lerdorf syst...@php.net 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, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Wed, Jul 13, 2011 at 9:19 PM, Rasmus Lerdorf ras...@lerdorf.com 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. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 ras...@lerdorf.com 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On 07/13/2011 12:23 PM, Pierre Joye wrote: On Wed, Jul 13, 2011 at 9:19 PM, Rasmus Lerdorf ras...@lerdorf.com 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Wed, Jul 13, 2011 at 9:28 PM, Rasmus Lerdorf ras...@lerdorf.com 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 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 patrickalla...@php.net wrote:
2011/6/17 Stas Malyshev smalys...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 ALLAERTpatrickalla...@php.net wrote:
2011/6/17 Stas Malyshevsmalys...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Zitat von Pierre Joye pierre@gmail.com: On Mon, Jul 11, 2011 at 10:15 AM, Jan Schneider j...@horde.org wrote: Zitat von Ferenc Kovacs tyr...@gmail.com: On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye pierre@gmail.com wrote: hi, As I could agree on this fact, I can't find any existing project having int(eger), floatco as class, namespaced or not. Do you have any example at hand? Cheers, https://github.com/search?type=Codelanguage=PHPq=%22class+int%22repo=langOverride=x=0y=0start_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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On 2011-07-12, Johannes Schlüter johan...@schlueters.de 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| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On 2011-07-12, Pierre Joye pierre@gmail.com 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Zitat von Ferenc Kovacs tyr...@gmail.com: On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye pierre@gmail.com wrote: hi, As I could agree on this fact, I can't find any existing project having int(eger), floatco as class, namespaced or not. Do you have any example at hand? Cheers, https://github.com/search?type=Codelanguage=PHPq=%22class+int%22repo=langOverride=x=0y=0start_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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Mon, Jul 11, 2011 at 10:15 AM, Jan Schneider j...@horde.org wrote: Zitat von Ferenc Kovacs tyr...@gmail.com: On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye pierre@gmail.com wrote: hi, As I could agree on this fact, I can't find any existing project having int(eger), floatco as class, namespaced or not. Do you have any example at hand? Cheers, https://github.com/search?type=Codelanguage=PHPq=%22class+int%22repo=langOverride=x=0y=0start_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, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP Outreach Project (Was: Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long)))
On 11 July 2011 09:26, Pierre Joye pierre@gmail.com wrote: On Mon, Jul 11, 2011 at 10:15 AM, Jan Schneider j...@horde.org wrote: 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. Do we need a sort of out-reach program here? Something that will be more active in announcing the various potential BC changes that are going to happen in PHP? Rather then just having the projects/leaders/developers pull from our various sources, we (as in the PHP group) actively subscribe to THEIR lists/FB/twitter/etc. If this is feasible and supported, I think that any BC we introduce needs to have support to give details on workarounds. In some cases, this could be as simple as renaming a class/function/method/etc. In other cases, more work dependent upon the actual project. I would recommend only pushing of BC info. New features/enhancements/etc. that are non-bc (from our perspective and research), should not be pushed. This means that if I (as a third party developer) get the call from PHP saying We will be breaking classes called string! I really really need to do something about it. It may be a pull list is fine/enough, but I guess we already have these and yet modern projects are still not preparing themselves. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 patrickalla...@php.netwrote:
2011/6/17 Stas Malyshev smalys...@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
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
hi,
As I could agree on this fact, I can't find any existing project
having int(eger), floatco as class, namespaced or not. Do you have
any example at hand?
Cheers,
On Sun, Jul 10, 2011 at 6:41 PM, Patrick ALLAERT patrickalla...@php.net wrote:
2011/6/17 Stas Malyshev smalys...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye pierre@gmail.com wrote: hi, As I could agree on this fact, I can't find any existing project having int(eger), floatco as class, namespaced or not. Do you have any example at hand? Cheers, https://github.com/search?type=Codelanguage=PHPq=%22class+int%22repo=langOverride=x=0y=0start_value=1 not too many though. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 tyr...@gmail.com wrote: On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye pierre@gmail.com wrote: hi, As I could agree on this fact, I can't find any existing project having int(eger), floatco as class, namespaced or not. Do you have any example at hand? Cheers, https://github.com/search?type=Codelanguage=PHPq=%22class+int%22repo=langOverride=x=0y=0start_value=1 not too many though. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny l...@strojny.net 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. cel...@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
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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@googlemail.com: On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny l...@strojny.net 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. cel...@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
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
And again, as .txt
Am 11.07.11 00:36 schrieb Lars Strojny unter l...@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@googlemail.com:
On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny l...@strojny.net 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.
cel...@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
Index: Zend/zend_language_scanner.l
===
--- Zend/zend_language_scanner.l(revision 313122)
+++ Zend/zend_language_scanner.l(working copy)
@@ -1007,6 +1007,9 @@
}
ST_IN_SCRIPTINGfunction {
+ if (CG(active_class_entry)) {
+ yy_push_state(ST_LOOKING_FOR_PROPERTY TSRMLS_CC);
+ }
return T_FUNCTION;
}
@@ -1163,6 +1166,14 @@
return T_OBJECT_OPERATOR;
}
+ST_LOOKING_FOR_PROPERTY{WHITESPACE} {
+ zendlval-value.str.val = yytext; /* no copying - intentional */
+ zendlval-value.str.len = yyleng;
+ zendlval-type = IS_STRING;
+ HANDLE_NEWLINES(yytext, yyleng);
+ return T_WHITESPACE;
+}
+
ST_LOOKING_FOR_PROPERTY{LABEL} {
yy_pop_state(TSRMLS_C);
zend_copy_value(zendlval, yytext, yyleng);
@@ -1177,6 +1188,7 @@
}
ST_IN_SCRIPTING:: {
+ yy_push_state(ST_LOOKING_FOR_PROPERTY TSRMLS_CC);
return T_PAAMAYIM_NEKUDOTAYIM;
}
Index: Zend/tests/bug28261.phpt
===
--- Zend/tests/bug28261.phpt(revision 0)
+++ Zend/tests/bug28261.phpt(revision 0)
@@ -0,0 +1,57 @@
+--TEST--
+Bug #28261: Lifting reserved keyword restriction for method names
+--FILE--
+?php
+class Test
+{
+ public function eval()
+ {
+ return __METHOD__;
+ }
+
+ public function include()
+ {
+ return __METHOD__;
+ }
+
+ public function print()
+ {
+ return __METHOD__;
+ }
+}
+
+class Test2
+{
+ public function EVAL()
+ {
+ return __METHOD__;
+ }
+ public function INCLUDE()
+ {
+ return __METHOD__;
+ }
+ public function PRINT()
+ {
+ return __METHOD__;
+ }
+}
+
+$o = new Test();
+printf(%s\n, $o-eval());
+printf(%s\n, $o-include());
+printf(%s\n, $o-print());
+
+$o = new Test2();
+printf(%s\n, $o-EVAL());
+printf(%s\n, $o-INCLUDE());
+printf(%s\n, $o-PRINT());
+?
+=DONE=
+--EXPECT--
+Test::eval
+Test::include
+Test::print
+Test2::EVAL
+Test2::INCLUDE
+Test2::PRINT
+=DONE=
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Hi, 2011/7/10 Nikita Popov nikita@googlemail.com: On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny l...@strojny.net 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. cel...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
2011/7/10 Lars Strojny l...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Hi Felipe, Am 11.07.11 00:41 schrieb Felipe Pena unter felipe...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Hi, 2011/7/10 Lars Strojny l...@strojny.net: Hi Felipe, Am 11.07.11 00:41 schrieb Felipe Pena unter felipe...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
