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