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
