On Thu, Sep 12, 2013 at 10:55 PM, Nikita Popov <nikita....@gmail.com> wrote:
> I tend to agree with Johannes. I tend to agree too but I never really liked this keywords restriction. > Supporting different sets of keywords in > different locations is pretty confusing. Imho we should add this kind of > support only in places where a) we can support all keywords and b) it is > unlikely that supporting keywords there will cause issues in the future. b) can't be proofed, also the keyword problem being future ready is also a shiny myth. It is a moving target. > One such case are method names. Methods with keyword names are currently > callable using $foo->array(), because the identifier after > T_OBJECT_OPERATOR is always a T_STRING. But while you can call them, it is > currently not possible to define them as real methods. Instead you need to > forward them via __call magic, which is rather ugly. Internal classes on > the other hand can and do define methods with reserved-keyword names. E.g. > there is a Generator::throw() method. This exact case is actually a very good reason to accept this proposal. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
