On 2010-11-23, Derick Rethans <der...@php.net> wrote: > On Mon, 22 Nov 2010, Felipe Pena wrote: > > . classes named as any of the type hint scalar types > > do not work anymore > > aka class int {} > > Yeah, there is a slight hint of a BC break in case you have a class > named "int" or "float" etc. But there is: > http://uk.php.net/manual/en/userlandnaming.tips.php > > Perhaps we can reduce the current list of classes: > int, integer, real, double, string, binary, scalar, array, object, > bool, boolean > to what the manual uses though (for prototypes): > int, float, string, binary, scalar, array, object, bool > (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
Sorry, but this is actually a pretty grave BC break. Currently, you can do the following: namespace Foo\Validator; class Int {} Because of the changes proposed, this would no longer work, breaking code that currently works with 5.3. I'd only expect a break like this when jumping to a major version -- and even then, I'd think that adding new keywords for such common names would need a *lot* of justification. As Sebastian noted, it seems this should be addressed with the new lexer; I'd argue that if the current type hinting must introduce new keywords, it should wait until the new lexer is in place in order to insulate end-users from such changes. <snip> > > We also have no plan about what will or will not be 5.4. This looks > > familiar, this is exactly how we begun 5.3 and it tooks literally > > years to be released. There is also actually no agreement to begin > > with 5.4 now. > > Yes, but instead of defining "what is PHP 5.4", why not just go with > what we have? Everything that's not in thre is for PHP-next-next again. > > > 5.4 should be hold off until we solved the listed issues and the > > release management RFC gets discussed and hopefully approved. > > Why do you need a release management RFC? We've made releases for more > than a decade just fine. > > Stalling every time doesn't get us anywhere. IMO we should just go with > it. Which means as a rough guide: > > - copy over APC/pecl_http > - branch on thursday > - alpha next week > - build a list of things that needs doing in 5.4 to get it ready (with > possible options to get rid of apc/pecl_http if they are not up to > date enough) > > I am absolutely against stalling again! I call shenanigans. This is *exactly* why a release process is desired and necessary -- because right now, there are BC breaks in trunk, only a vague idea about what may or may not be ready, and competing ideas about what constitutes grounds for branching. "Just go with it" may work for a few people, but that sort of attitude leaves those whose features were skipped over or who were away from the list and/or IRC for a few days wondering what happened later. With a defined release process, *everyone* knows what must be done, by when, making the process more transparent and *gasp* democratic. -- 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