Dear Internals,
I would like to discuss a small RFC for reserving more types in PHP 7:
https://wiki.php.net/rfc/reserve_more_types_in_php_7
Welp, thanks for breaking my framework, everyone.
It just had to be case-insensitive too, hm?
- Nate
Dear Internals,
I would like to discuss a small RFC for reserving more types in PHP 7:
https://wiki.php.net/rfc/reserve_more_types_in_php_7Welp, thanks for breaking my framework, everyone.
It just had to be case-insensitive too, hm?
I'm not sure what you want us to say.
Dear Internals,
I would like to discuss a small RFC for reserving more types in PHP 7:
https://wiki.php.net/rfc/reserve_more_types_in_php_7Welp, thanks for breaking my framework, everyone.
It just had to be case-insensitive too, hm?
I'm not sure what you want us to say.
Well, it looks to me like all the discussion is around preventing class and namespace names like “string”, “float”, etc. Granted, PHP class names are case-insensitive, but how hard would it be to reserve these in a case-sensitive way?
Lithium, CakePHP, and Drupal all have String classes. These aren’t small projects. Not to mention the presumably untold numbers of developers who have hand-rolled ‘type’ classes into their projects while waiting around for scalar type-hinting support to land. And everyone’s cool with breaking all of these?
Has someone valiantly signed on to do LTS support for 5.6 beyond two years from now, and I’m just not aware of it? Or are we cool with letting all the dependent software that can’t afford to be upgraded just atrophy and die?
I get that PHP 7 is the big opportunity to break backward compatibility, but yeesh, really? It’s like we’re not even trying anymore.
There is the approved RFC at
https://wiki.php.net/rfc/context_sensitive_lexer which is listed as
"pending implementation" which should alleviate these BC breaks
significantly. The linked RFC mentions this one specifically under the
"Impact On Other RFCs" section.
Hi,
2015-04-26 17:00 GMT-03:00 Joshua Holmer jholmer.in@gmail.com:
There is the approved RFC at
https://wiki.php.net/rfc/context_sensitive_lexer which is listed as
"pending implementation" which should alleviate these BC breaks
significantly. The linked RFC mentions this one specifically under the
"Impact On Other RFCs" section.
I'm the author of the cited RFC and there is a clear misconception here and
in other threads: the "context sensitive lexer - CSL" RFC can prevent BC
breaks for classes with members named like $someClass->string(), but the
RFC doesn't prevent the BC breaks for class names.
Even if I manage to pass a sequel CSL RFC that aims to allow semi reserved
names for classes we will still have these type names reserved at compile
time. In resume, there is no way to allow classes and types with the same
name until we have case sensitive identifiers.
Márcio
Hi!
Well, it looks to me like all the discussion is around preventing
class and namespace names like “string”, “float”, etc. Granted, PHP
class names are case-insensitive, but how hard would it be to reserve
these in a case-sensitive way?
With current engine - I'd say it is hard. We can't really say "class
names are case insentitive unless it's "string" or "float" or "boolean"
in which case they are case sensitive". Imagine how code implementing
such logic would look like, not to talk about the inconsistencies...
Lithium, CakePHP, and Drupal all have String classes. These aren’t
Unfortunately, with scalar types we don't have much choice. I don't see
how scalar types and classes named "string" can coexist.
I get that PHP 7 is the big opportunity to break backward
compatibility, but yeesh, really? It’s like we’re not even trying
anymore.
There was a lot of discussion about this topic. Right now, unless
there's a proposal to fix it that works, I don't see what can be done
about it.
Stas Malyshev
smalyshev@gmail.com
On Mon, Apr 27, 2015 at 6:44 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
Well, it looks to me like all the discussion is around preventing
class and namespace names like “string”, “float”, etc. Granted, PHP
class names are case-insensitive, but how hard would it be to reserve
these in a case-sensitive way?With current engine - I'd say it is hard. We can't really say "class
names are case insentitive unless it's "string" or "float" or "boolean"
in which case they are case sensitive". Imagine how code implementing
such logic would look like, not to talk about the inconsistencies...Lithium, CakePHP, and Drupal all have String classes. These aren’t
Unfortunately, with scalar types we don't have much choice. I don't see
how scalar types and classes named "string" can coexist.I get that PHP 7 is the big opportunity to break backward
compatibility, but yeesh, really? It’s like we’re not even trying
anymore.There was a lot of discussion about this topic. Right now, unless
there's a proposal to fix it that works, I don't see what can be done
about it.
It should be possible to write something with PHP Parser detecting all the
occurances of "String/string" class usage to at least give a worklog of
entries that need to be changed, or maybe generate a patch file that can be
applied to the code base after review.
--
Stas Malyshev
smalyshev@gmail.com
There was a lot of discussion about this topic. Right now, unless
there's a proposal to fix it that works, I don't see what can be done
about it.It should be possible to write something with PHP Parser detecting all the
occurances of "String/string" class usage to at least give a worklog of
entries that need to be changed, or maybe generate a patch file that can be
applied to the code base after review.
We have already had a similar incidence of this problem with the
date/time stuff. The main problem then was it being introduced at the
wrong time. PHP7 is the right time but switching the names being use is
not an option. string IS probably the most difficult one, but any good
IDE will allow all of the existing names to be changed. What is possibly
an annoyance here is that this IS simply blocking the usage, rather than
providing a functional replacement?
Other 'priorities' seem to have pushed a single string handling solution
back down the pile :( The question should perhaps be does any of the
third part string classes provide a 'pear' style alternative which can
be later be converted to an internal function set?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
It should be possible to write something with PHP Parser detecting all the
occurances of "String/string" class usage to at least give a worklog of
entries that need to be changed, or maybe generate a patch file that can be
applied to the code base after review.
Sure, or just open a fairly recent IDE, right-click on class String,
click refactor/rename.
That alone should take care of most usages. Hopefully ;)
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi,
De : Stanislav Malyshev [mailto:smalyshev@gmail.com]
There was a lot of discussion about this topic. Right now, unless
there's a proposal to fix it that works, I don't see what can be done
about it.
I wrote a long message some months ago to explain why reserving names was, IMHO, the wrong way to go (internals@lists.php.net/msg75672.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg75672.html). The problem comes from authorizing bare class names as type hints. That’s history, none to blame here, it should just have been solved when type hints were extended to arrays, but, with the extension to scalars, it is now urgent.
Solving conflicts one by one, and discussing whether 'String' is a bad choice for a class name, or if it should be reserved in a case-sensitive way, won't solve anything. 'String' is just the first one to jump in. Consider 'Resource', 'Object'... All potential endless discussions to clutter the mailing list and make users afraid of switching to 7. Potential result : the old circle Johannes is talking about and the python 2/3 effect.
I think we need to consider we have a name conflict, as we are using the same name space for two different concepts, and decide a long-term strategy to address it, preferably before releasing 7.0. Once again, I propose what I still consider as the only long-term solution proposed so far : slowly, step by step, deprecate the usage of bare class names as type hints. It looks like a huge break, and it is, but we can make it smooth. Here are the steps I have in mind :
-
In 7.0, introduce the 'object' (accepts any object instance) and 'object(ClassName)' (similar to the bare 'ClassName') type hint syntaxes. Bare class names are still recognized and priority is given to class names (if a 'String' class is defined, every 'String' or even 'string' type hints will always refer to it). So, compatibility is preserved, even if class names conflict with scalar type hints. Prominent frameworks will easily change their 'String' type hints to 'object(String)' and be prepared for the next step. Anyway, they have several years to do it and the most important is that they keep their class names.
-
In a second step, probably in 8.0, and with a prior deprecation message introduced in a 7.x version to define, remove support for bare class names as type hints. This step can be refined later. The most important is to introduce the target syntax as soon as possible.
Regards
François
François Laupretre wrote on 28/04/2015 12:32:
Bare class names are still recognized and priority is given to class names (if a 'String' class is defined, every 'String' or even 'string' type hints will always refer to it).
This part is likely to be rather tricky to implement. How do you know if
a 'String' class is defined or not?
The Engine would have to do something like this:
- check in-scope use statements for resolutions of 'String' to a
qualified name - if in namespace scope, try class_exists(NAMESPACE '\String'),
invoking autoloader if registered - if not in namespace scope, check class_exists('String'), invoking
autoloader if registered - if class found, hint is an object instanceOf check
- else, hint is a scalar check
All of this (apart from resolving use statements) has to run every time
the hint is processed, since there is no limit on when a class can
become defined. The user has no way of avoiding this penalty, even if
they never intend to declare a String class.
In contrast, reserving the hint "string" allows the compiler to
immediately choose a scalar check, and an instanceOf check never needs
to run an autoloader, because if the class isn't declared, there can't
possibly be an instance of it.
Regards,
Rowan Collins
[IMSoP]
François Laupretre wrote on 28/04/2015 12:32:
Bare class names are still recognized and priority is given to class names (if a 'String' class is defined, every 'String' or even 'string' type hints will always refer to it).
This part is likely to be rather tricky to implement. How do you know if
a 'String' class is defined or not?The Engine would have to do something like this:
This also becomes funny with code like this:
<?php
function foo(String $bar) {}
foo($bar); // No class Sttttring,, $bar must be native string
include('some_file_which_defines_a_class_String_maybe_via_autoload_or_sth.php');
foo($bar); // Class String exists, $bar must be of that class
?>
Make things as deterministic as possible.
johannes
De : Rowan Collins [mailto:rowan.collins@gmail.com]
This part is likely to be rather tricky to implement. How do you know if
a 'String' class is defined or not?The Engine would have to do something like this:
- check in-scope use statements for resolutions of 'String' to a
qualified name- if in namespace scope, try class_exists(NAMESPACE '\String'),
invoking autoloader if registered- if not in namespace scope, check class_exists('String'), invoking
autoloader if registered- if class found, hint is an object instanceOf check
- else, hint is a scalar check
All of this (apart from resolving use statements) has to run every time
the hint is processed, since there is no limit on when a class can
become defined. The user has no way of avoiding this penalty, even if
they never intend to declare a String class.
That's right. The transitional phase would introduce a small performance penalty. But that's temporary : as soon as we remove support for bare class names, the runtime overhead and complexity disappears.
A simpler, but still acceptable solution, would be just to introduce the 'object' and 'object(Classname)' syntax. Then, we still consider that 'string' is reserved, the compiler recognizes it as a scalar hint, and we tell programmers they must switch their type hints to the new syntax when they conflict with a reserved name. Actually, the message would be that, because of potential conflicts, bare class names are still supported but discouraged and deprecated soon, whatever the class name. We lose the full BC but it may be acceptable for a major version. Then, it can be deprecated in 7.x and suppressed in 8.0. A side effect is that we don't have to reserve names anymore, which will avoid a lot of endless and sterile discussion. It would be simple and quick for prominent frameworks and software to switch to the new syntax, the most important being that they don't have to modify their class names. We can even backport the 'object(classname)' syntax to PHP 5 to make the migration path smoother.
If we accept it can still target 7.0, I propose to write an RFC just proposing to add this syntax.
I am sorry to insist but we really need to do something. Just look at the suggestion of considering 'string' as the only case-sensitive class name. Are you ready to discuss more and more silly workaround suggestions like this one ? While I am all for making class names case-sensitive (off-topic), distinguishing 'String' from 'string' is definitely a very bad reason ;).
I am especially interested by the opinion of Drupal, Wordpress, and other framework developers. Are there any out there ? Please comment.
Regards
François
François Laupretre wrote on 28/04/2015 14:35:
I am especially interested by the opinion of Drupal, Wordpress, and other framework developers. Are there any out there ? Please comment.
If you look in the rest of the thread, you'll see a few:
- Drupal's String class was part of Drupal 8, which is still in Beta,
and has been renamed/removed already - AFAIK, Wordpress has never had a class with any of the newly reserved
names (most of their classes begin WP_) - CakePHP has renamed "String" to "Text", and added an alias so both
names can be used in PHP5. Doesn't rule out them being interested in
alternative solutions, though. - The other framework mentioned as affected was Lithium, about which I
know nothing.
Regards,
Rowan Collins
[IMSoP]
I do know about Lithium, but honestly Nate I don't agree with your
complain. While I do understand the frustration of having to update
code because of changes in the underlying platform (PHP7 in this
case), I believe this is a change for the better, and to which
dependent code should adapt.
You have experienced this in the past yourself: wanting to introduce a
new feature in a framework you developed sometimes implied BC changes
which affected people who ended up not liking the fact that their code
had to be modified. But BC changes are needed, and something as big as
STH is definitely worth it. It is not by chance that its introduction
and ultimately acceptance into the PHP core has been received with
considerable excitement and energy.
Yes, some (small portions) of userland PHP code, such as the Lithium
framework (which by the way I probably have the biggest production
code that utilizes it) will be affected. The solution for such
frameworks? A simple class rename. Yes, that will imply that any
Lithium based code that's not updated will not be supported by PHP7,
but isn't that actually a good thing? Userland code should remain
updated, moving forward with the language.
François Laupretre wrote on 28/04/2015 14:35:
I am especially interested by the opinion of Drupal, Wordpress, and other
framework developers. Are there any out there ? Please comment.If you look in the rest of the thread, you'll see a few:
- Drupal's String class was part of Drupal 8, which is still in Beta, and
has been renamed/removed already- AFAIK, Wordpress has never had a class with any of the newly reserved
names (most of their classes begin WP_)- CakePHP has renamed "String" to "Text", and added an alias so both names
can be used in PHP5. Doesn't rule out them being interested in alternative
solutions, though.- The other framework mentioned as affected was Lithium, about which I know
nothing.Regards,
Rowan Collins
[IMSoP]
Hi François,
Am 28.04.2015 um 13:32 schrieb François Laupretre:
- In 7.0, introduce the 'object' (accepts any object instance) and 'object(ClassName)' (similar to the bare 'ClassName') type hint syntaxes.
I find this variant extremely nonintuitive and it conflicts with the
behavior of every relevant language (Java, C++) that has classes and
simple types.
I would like PHP to make all class/trait/interface names case-sensitive
and use only lower-case names for the scalar type hints (same for
object, array, etc.). This would solve most problems. Class names are
kind of case sensitive in applications that rely on autoloading on
platforms with case sensitive file systems.
Greets
Dennis
De : Dennis Birkholz [mailto:dennis@birkholz.biz]
I would like PHP to make all class/trait/interface names case-sensitive
and use only lower-case names for the scalar type hints (same for
object, array, etc.). This would solve most problems. Class names are
kind of case sensitive in applications that rely on autoloading on
platforms with case sensitive file systems.
-
I proposed making class names case-sensitive and it was clearly rejected, most considering it is a huge BC break for almost no benefit. I personally don't know any software which uses class names in a case-insensitive manner but it seems others do ! I am not sure, but scalar type hints were probably implemented as case-insensitive too. In other words, if you're ready to relaunch the case-sensitivity discussion, feel free to do it.
-
Anyway, basing name conflict resolution on naming conventions is not acceptable, in my opinion. PSR-1 is just a convention. We cannot resolve name conflicts in the core based on this. If we want to go that way, let's display an
E_STRICTmessage when encountering an all-lowercase class name, but that's another debate and I don't think anyone is willing to enforce PSR rules in the core.
Regards
François
De : Dennis Birkholz [mailto:dennis@birkholz.biz]
I would like PHP to make all class/trait/interface names case-sensitive
and use only lower-case names for the scalar type hints (same for
object, array, etc.). This would solve most problems. Class names are
kind of case sensitive in applications that rely on autoloading on
platforms with case sensitive file systems.
- I proposed making class names case-sensitive and it was clearly rejected, most considering it is a huge BC break for almost no benefit. I personally don't know any software which uses class names in a case-insensitive manner but it seems others do ! I am not sure, but scalar type hints were probably implemented as case-insensitive too. In other words, if you're ready to relaunch the case-sensitivity discussion, feel free to do it.
To be completely accurate, it was rejected for PHP 7. PHP 7 was
announced suddenly and rushed through. I think a BC break of this
magnitude in PHP 7 would be incredibly painful because of the
timetable. Whereas if we decide now that in PHP 8 all identifiers
will be case sensitive that's a different story because of the
timeline. Knowing years in advance that something will happen gives
you ample time to migrate (like we are doing with PHP 4 constructors
in the PHP 7 series; they are deprecated and support will be removed
in PHP 8).
De : morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] De la part
- I proposed making class names case-sensitive and it was clearly rejected,
most considering it is a huge BC break for almost no benefit. I personally
don't know any software which uses class names in a case-insensitive
manner but it seems others do ! I am not sure, but scalar type hints were
probably implemented as case-insensitive too. In other words, if you're
ready to relaunch the case-sensitivity discussion, feel free to do it.To be completely accurate, it was rejected for PHP 7. PHP 7 was
announced suddenly and rushed through. I think a BC break of this
magnitude in PHP 7 would be incredibly painful because of the
timetable. Whereas if we decide now that in PHP 8 all identifiers
will be case sensitive that's a different story because of the
timeline. Knowing years in advance that something will happen gives
you ample time to migrate (like we are doing with PHP 4 constructors
in the PHP 7 series; they are deprecated and support will be removed
in PHP 8).
Mmh, PHP 7 or not, the reaction was really : 'huge BC break for no benefit'. I'll try to propose it more in advance for 8.0, as you suggest, but I'm really not sure it has more success. Anyway, that's not a serious solution to solve type hint conflicts.
Regards
François
Dear Internals,
I would like to discuss a small RFC for reserving more types in PHP 7:
https://wiki.php.net/rfc/reserve_more_types_in_php_7Welp, thanks for breaking my framework, everyone.
It just had to be case-insensitive too, hm?
I'm not sure what you want us to say.
Well, it looks to me like all the discussion is around preventing class and
namespace names like “string”, “float”, etc. Granted, PHP class names are
case-insensitive, but how hard would it be to reserve these in a
case-sensitive way?
Not necessarily hard, but it would create an inconsistency with other
types. PHP has plenty of consistency problems already; do you really
want to add a new one?
Lithium, CakePHP, and Drupal all have String classes. These aren’t small
projects. Not to mention the presumably untold numbers of developers who
have hand-rolled ‘type’ classes into their projects while waiting around for
scalar type-hinting support to land. And everyone’s cool with breaking all
of these?
This was known at voting time, yes. Having an actual string type in
PHP was a separate RFC that was accepted -- realize that while my RFC
would have reserved it whether that other one passed or not the other
RFC did pass, so effectively the RFC you linked only reserved true,
false and null.
I get that PHP 7 is the big opportunity to break backward compatibility, but
yeesh, really? It’s like we’re not even trying anymore.
The number of code bases using a string class is quite small when you
compare it to the total number of PHP developers and code bases out
there.
I think you are blowing this out of proportion because you are
directly affected by it. I get it -- my website at work was really hit
hard in PHP 5, 5.3 and 5.4. We had some really crappy code that relied
on register globals, some deprecated session functions, magic quotes,
ext/mysql and other problems. After fixing each issue our codebase has
been better off.
If you can't afford to update an application then you need to
seriously think about that since that application apparently isn't
valuable enough for you to maintain it.
Hi,
This was known at voting time, yes.
and I hope voters understand what they are doing while voting and hope
they considered that. As long as we have this voting scheme we have to
follow the results else it's pointless.
The number of code bases using a string class is quite small when you
compare it to the total number of PHP developers and code bases out
there.I think you are blowing this out of proportion because you are
directly affected by it. I get it -- my website at work was really hit
hard in PHP 5, 5.3 and 5.4. We had some really crappy code that relied
on register globals, some deprecated session functions, magic quotes,
ext/mysql and other problems. After fixing each issue our codebase has
been better off.
It is true that evolving is useful to improve code bases. But mind: On a
private code bases that is simpler to do than with a system like
Wordpress with it's APIs and downstream consumers. If Wordpress is not
willing to update it probably won't work with PHP 7. Thus hosting
companies, distributors etc. keep PHP 5, which means Wordpress has no
motivation to update, which means hosting companies and distributors
won't. The old circle ... and see Python 2 vs 3 for the longterm effect.
That's why I think BC is very important and like the quote
"Compatibility is a feature" (Bjarne Stroustrup, creator of C++)
johannes
Lithium, CakePHP, and Drupal all have String classes.
I gather that Drupal's String class was actually a rather badly designed utility class, and its methods have been rehomed in more specific areas. AFAICS, it was only added in Drupal 8, which is still in beta, so there isn't a large historical code base referencing it, anyway.
Regards,
Rowan Collins
[IMSoP]
CakePHP has renamed its String class to Text and it was simple as this for us to be ready for PHP 7: https://github.com/cakephp/cakephp/blob/9ba845ef831c7f92519e5b233e294deeb0b2b53f/config/bootstrap.php#L21-L23 https://github.com/cakephp/cakephp/blob/9ba845ef831c7f92519e5b233e294deeb0b2b53f/config/bootstrap.php#L21-L23
Lithium, CakePHP, and Drupal all have String classes.
I gather that Drupal's String class was actually a rather badly designed utility class, and its methods have been rehomed in more specific areas. AFAICS, it was only added in Drupal 8, which is still in beta, so there isn't a large historical code base referencing it, anyway.
Regards,
Rowan Collins
[IMSoP]
Lithium, CakePHP, and Drupal all have String classes.
I gather that Drupal's String class was actually a rather badly designed utility class, and its methods have been rehomed in more specific areas. AFAICS, it was only added in Drupal 8, which is still in beta, so there isn't a large historical code base referencing it, anyway.
Regards,
Drupal's String class was added in Drupal 8, and was quickly renamed. So
quickly that I didn't even notice we'd done it. :-) The "badly
designed" claim is off topic and I will not respond to it.
--Larry Garfield
On 26 April 2015 20:36:12 GMT+01:00, Nate Abele
nate.abele@gmail.com wrote:
Lithium, CakePHP, and Drupal all have String classes.I gather that Drupal's String class was actually a rather badly
designed utility class, and its methods have been rehomed in more
specific areas. AFAICS, it was only added in Drupal 8, which is still
in beta, so there isn't a large historical code base referencing it,
anyway.Regards,
Drupal's String class was added in Drupal 8, and was quickly renamed.
So
quickly that I didn't even notice we'd done it. :-) The "badly
designed" claim is off topic and I will not respond to it.
Sorry, that was a poor choice of words, I wasn't meaning it critically. What I'd heard was that the opportunity was taken to evaluate the best home for each of the methods, rather than renaming the whole class to something else. Either way, the point as you say is that the problem has been quickly remedied and never hit production released code.
Regards,
Rowan Collins
[IMSoP]