Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53914
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 87.106.212.190 cause and error)
Message-ID: <4E1C1CEC.2050802@hoa-project.net>
Date: Tue, 12 Jul 2011 12:07:40 +0200
Reply-To: ivan.enderlin@hoa-project.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: Patrick ALLAERT <patrickallaert@php.net>, 
 Stas Malyshev <smalyshev@sugarcrm.com>,
 PHP Internals <internals@lists.php.net>
References: <CACwt+Jc=yGjr_YQ-i_gDs5DyUhGajTHxa5hJ1g4qfEWDyhvBaw@mail.gmail.com> <CAEZPtU6G3W--vncmu4qJ5V8fERkad+6O5S-n+g+jgcyNJNeubg@mail.gmail.com>
In-Reply-To: <CAEZPtU6G3W--vncmu4qJ5V8fERkad+6O5S-n+g+jgcyNJNeubg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Make primitive type names reserved words (Was: Re:
 [PHP-DEV] [RFC] 5.4 features for vote (long))
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")

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=20
rejected. But maybe we can add new magic methods, such as: __toBool(),=20
__toInt(), __toFloat() etc. User can use int(), float() etc. if he=20
needs/wants to, and we are always able to do same things (e.g. adding=20
future features).
Moreover, PHP has a dynamic typing system. Having tokens as reserved=20
keywords appears obviously logical to me, but why having type names as=20
reserved keywords? Sounds like we do not assume our =93type position=94. =

That's why adding magic methods looks like a better way to solve this=20
problem.

Thougs?

Best regards.


PS: I cannot change my vote on https://wiki.php.net/todo/php54/vote, is=20
it a known issue?

> On Sun, Jul 10, 2011 at 6:41 PM, Patrick ALLAERT<patrickallaert@php.net=
>  wrote:
>> 2011/6/17 Stas Malyshev<smalyshev@sugarcrm.com>:
>>
>> [snip]
>>
>>> 2. Make primitive type names reserved words (in case we ever want som=
e form
>>> of scalar typing or anything else with scalar types). Using them as
>>> identifiers would return parse error for now. May have BC implication=
s.
>> 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
>>
>>
>
>

--=20
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/