Pierre,

> De : Pierre Joye [mailto:pierre....@gmail.com]
>
> > I case we would designed a new language I would rise two hands.
> > Changing, syntax in an existent widely used language is an additional pain
> > for users.
> > Technically it shouldn't be very difficult to remove support for
> > case-insensitivity, and it'll even improve speed and memory consumption,
> > but I don't think it costs the compatibility break.
> 
> I fully agree  and why I will vote no on that. Even if I know many
> projects that won't even notice such changes. But I also have no idea
> how many 1000s projects out there won't be as happy.

Don't worry, I won't bother anyone with a vote at this stage. I have started an 
RFC to keep a track and explore the topic but it is a complex subject. It is 
even *many* more or less independent complex subjects.

Anyway, some may be easier than others, for different reasons  (just personal 
opinions, to be confirmed in each case) :

- Namespaces are relatively new. We might expect code using them to be 
'cleaner',
- We can probably quite easily deprecate support (internal and userland) for 
case-insensitive functions by just making null, false, and true case-sensitive 
and adding new NULL, FALSE, TRUE, Null, False, and True. Probably no need for 
fAlSe or tRUE :)
- __halt_compiler() does not represent much but has the benefit of being an 
easy case :)
- magic methods are already more risky but may be imagined with some 
case-sensitive aliases added.

The rest is more complex, and would necessitate extensive impact studies.

Regards

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to