Re: [PHP-DEV] Pointers to understanding code base
On Sat, Feb 7, 2015 at 1:56 AM, Lester Caine les...@lsces.co.uk wrote:
OK slowly getting back into raw code again ...
Looking at imagick phpinfo problem ...
if (supported_formats) {
for (i = 0; i num_formats; i++) {
smart_string_appends(formats,
supported_formats[i]);
if (i != (num_formats - 1)) {
smart_string_appends(formats, , );
}
IMAGICK_FREE_MAGICK_MEMORY(supported_formats[i]);
}
smart_string_0(formats);
#ifdef ZEND_ENGINE_3
php_info_print_table_row(2, ImageMagick supported
formats, formats);
#else
php_info_print_table_row(2, ImageMagick supported
formats, formats.s);
#endif
smart_string_free(formats);
IMAGICK_FREE_MAGICK_MEMORY(supported_formats);
}
This one of the few places I can find smart_string_appends used, and I
can't work out just where it's code is? Although what it should be doing
is fairly self explanatory ... except why the dropping of the .s for
ZEND_ENGINE_3 ?
I hope this is the right pointer.
The String API changed completely in ZE3, see the Upgrading docs to PHPNG:
https://wiki.php.net/phpng-upgrading#strings
It takes much time wrapping your head around this new way, but I think in
the end its better than before.
supported_formats must have the list as it says there are 209 entries,
but why is there a problem doing something simple which works on the 5.x
builds.
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Lars, On 07/02/2015 04:36, Lars Strojny wrote: My main concern is that the declare statement is basically a better behaviour changing ini setting and PHPs history is paved with those. I very much hope for scalar type hinting, especially a strict variant but this is not what we should merge. Maybe it's just me, but I didn't quite understand the point you are making here. Are you saying that declares are more or less like ini settings? Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds a...@ajf.me wrote: Good evening, At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. Hello, I just realized it now (I brought it up in a different manner when there was discussion about the RFC), but I didn't notice there was a totally false statement about it in the RFC itself. You probably should fix it. I'm speaking about the Strict type checking, which is used by many popular programming languages, particularly ones which are statically-typed, such as Java, C#, Haskell, or Facebook's Hack. It is also used for non-scalar parameter type hints in PHP. With this approach, an argument is only accepted if its type is exactly the same as the parameter. paragraph. This is NOT true (at least for C# and Java), as you can read here in the documentations of respecitve languages so you should not compare the strict version of the typing implemented in PHP with other strongly typed languages, because the PHP's strict is stricter than strongly static typed languages. I really hope noone voted with the thought that the strict typing acts as it does in Java and C#. https://msdn.microsoft.com/en-us/library/y5b434w4.aspx http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2 Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Annotated PHP 5-7 extension diff
De : Pierre Joye [mailto:pierre@gmail.com] Not sure it will help. It is really about showing cases for deref, duplicate, convert, iterate, etc. The zpp, return values or functions/class/methods declaration are really the easy part here. I understand. I thought it would be a nice way to enhance the abstraction layer php-ext-gen provides, as I am missing use cases. Generating glue code is just one of the project objectives. The second one is to provide an abstraction layer allowing to duplicate as few code as possible when migrating an extension to PHP 7 (HHVM is also in scope). I already fully abstract resources, so that user code doesn't have to deal, for instance, with zend_resource structs. I also provide an API for persistent resources, which Zend does not provide. That's just an example. It can be done for many other areas. But, if you don't want to participate, I'll integrate that myself using your examples. Just a question : for your demo extension, would you write two branches or a single one with #ifdef directives ? Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Annotated PHP 5-7 extension diff
On Feb 7, 2015 5:57 PM, François Laupretre franc...@tekwire.net wrote: De : Pierre Joye [mailto:pierre@gmail.com] Not sure it will help. It is really about showing cases for deref, duplicate, convert, iterate, etc. The zpp, return values or functions/class/methods declaration are really the easy part here. I understand. I thought it would be a nice way to enhance the abstraction layer php-ext-gen provides, as I am missing use cases. Generating glue code is just one of the project objectives. The second one is to provide an abstraction layer allowing to duplicate as few code as possible when migrating an extension to PHP 7 (HHVM is also in scope). I already fully abstract resources, so that user code doesn't have to deal, for instance, with zend_resource structs. I also provide an API for persistent resources, which Zend does not provide. That's just an example. It can be done for many other areas. But, if you don't want to participate, I'll integrate that myself using your examples. It is more a time issue and a non believer in too much generation of codes. Just a question : for your demo extension, would you write two branches or a single one with #ifdef directives ? I ported one (not oss sadly) and I end up with separate files. One for 5.x, 7.x and common helpers. Cheers François
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Feb 7, 2015 5:01 PM, Tony Marston tonymars...@hotmail.com wrote: Stelian Mocanita wrote in message news:CAMc0WS6+1Y-5yJW2s=mw+yns6tn8m5ieaxe10mwnlrl0_dz...@mail.gmail.com... On Fri, Feb 6, 2015 at 12:57 AM, Andi Gutmans a...@zend.com wrote: The folks who really want all this great strict typing should head over to Oracle.com and download free open-source Java? I hear it's got a lot of strict typing features in it. Only downside is that it'll take them 10x longer to complete their projects. OK sorry. Had to say that :) I realize it's not the same... Sending people who want to have more structure in the language to Java is downright bad, not to mention that it sounds completely dictatorial. I would just put that in the next Zend newsletter to make it clear for your customers that there is a saner option. Stelian It is not as bad as saying PHP has been weakly typed for the past 20 years, but PHP 7 will be strictly typed, so every developer will have to change his entire codebase in order for his application to run under PHP 7. If you are one of those who cannot program in a language which doesn't have strict typing, then why are you using PHP in the first place? Why aren't you using Java as Andi suggested? If you want to change the typing mechanism in PHP then remember that it *IS* weakly typed whether you like it or not, and will always be so. If you want to introduce strict typing then it must be optional, and it must not interfere with any of the existing PHP 5 applications. Tony, I had to resist not to jump into this but here we go. Please double check the RFC, what it does, propose and its impact by default on existing codes. Call it doing your homework. Then reconsider your reply.
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Stelian Mocanita wrote in message news:CAMc0WS6+1Y-5yJW2s=mw+yns6tn8m5ieaxe10mwnlrl0_dz...@mail.gmail.com... On Fri, Feb 6, 2015 at 12:57 AM, Andi Gutmans a...@zend.com wrote: The folks who really want all this great strict typing should head over to Oracle.com and download free open-source Java? I hear it's got a lot of strict typing features in it. Only downside is that it'll take them 10x longer to complete their projects. OK sorry. Had to say that :) I realize it's not the same... Sending people who want to have more structure in the language to Java is downright bad, not to mention that it sounds completely dictatorial. I would just put that in the next Zend newsletter to make it clear for your customers that there is a saner option. Stelian It is not as bad as saying PHP has been weakly typed for the past 20 years, but PHP 7 will be strictly typed, so every developer will have to change his entire codebase in order for his application to run under PHP 7. If you are one of those who cannot program in a language which doesn't have strict typing, then why are you using PHP in the first place? Why aren't you using Java as Andi suggested? If you want to change the typing mechanism in PHP then remember that it *IS* weakly typed whether you like it or not, and will always be so. If you want to introduce strict typing then it must be optional, and it must not interfere with any of the existing PHP 5 applications. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pointers to understanding code base
Try again ... last attempt just vanished :( On 07/02/15 10:30, Benjamin Eberlei wrote: I hope this is the right pointer. The String API changed completely in ZE3, see the Upgrading docs to PHPNG: https://wiki.php.net/phpng-upgrading#strings It takes much time wrapping your head around this new way, but I think in the end its better than before. I've tried to work through that, but Not all of the extensions code have to be converted to use zend_string instead of char*. It's up to extensions maintainer to decide which type is more suitable in each particular case. does not help if one does not know how one decides ... The main problem is that the smart_string section seems to have an identity crisis? smart_str is till being used in the exmples. Any reaon for that? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Feb 7, 2015 6:46 PM, Matteo Beccati p...@beccati.com wrote: Hi Lars, On 07/02/2015 04:36, Lars Strojny wrote: My main concern is that the declare statement is basically a better behaviour changing ini setting and PHPs history is paved with those. I very much hope for scalar type hinting, especially a strict variant but this is not what we should merge. Maybe it's just me, but I didn't quite understand the point you are making here. Are you saying that declares are more or less like ini settings? Somehow related but for such things, a notion of package (aka the discussions we had back then about namespace vs package) would be amazingly handy here.
[PHP-DEV] Dragging the legacy users forward.
My personal experience of PHP4 is simply one of having been developing all my code in PHP5.0 to 5.2 but ensuring that the code also still run clean on the PHP4 host. It was not until 5.3 that it was necessary to freeze the code base for 5.2 for every PHP4 host and maintain that fork while 'taking advantage' of the new features of PHP5 that were not supported by PHP4. That is the code base that is currently populating the vast majority of PHP powered sites still, so while PHP4 is dead it's footprint still lives on. Moving code to a post PHP5.4 host is NOT simply a matter of configuring the configuration to hid the problems. Many features relied on by code up to 5.2 had been removed and so code HAS to be reworked ... or hosting remains with some pre5.4 compromise which accounts for the current usage of PHP5.3 PHP7 is proposing a LOT of shiny new features which will break much legacy code. So the question has to be just what is the plan regarding cross version support. I see that the general consensus is PHP5 should just run? But do we have to start taking greater care of third party libraries which as with the 5.2 to 5.4 switch means that two versions are needed? I've currently deliberately configured my development system so that PHP5 and PHP7 are running the same code set and once I have all the missing extensions I can start playing further, but I need to work out how to allow 'needs PHP7' libraries in parallel. There IS a clear speed advantage, but I'm not sure yet if that is PHP5.4 to later 5.x or simply 5 to 7 improvements. I'm don't see any reason to think it's not simply 5-7 so I can then check the impact of things like 'unconstrained integer', however THAT is going to require a lot more care with the code than simply 'it runs' :( In the past using 32 bit builds has been a fix for many problems, not just the windows platform ones, so removing that prop requires a lot more care! -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pointers to understanding code base
( email addresses used to be easy! - get the right one ) On 07/02/15 02:34, Dan Ackroyd wrote: Lester, If you are having issues with Imagick please report them here: https://github.com/mkoppanen/imagick Not only is that the right place to report issues with unreleased versions of Imagick, but also I tend to monitor issues there more closely than I do a mailing list. imagick is just one of the packages I am looking at. The whole point of this post was to get some help getting up to speed actually working with the php-src code base. None of my notes from PHP4-5 days make any sense as many of the methods used don't seem to match now ... such as processing strings! This one of the few places I can find smart_string_appends used, and I can't work out just where it's code is? lxr is your friend: http://lxr.php.net/xref/PHP_TRUNK/ext/standard/php_smart_string.h#79 Yep - got that - but converting it to English has me going around in circles. *IS* the whole process covered in that file ... some comments would be helpful. why is there a problem doing something simple which works on the 5.x builds. Apparently software can have bugs. Who knew! Seriously though, there was a bug displaying the phpinfo page caused by the migration to the 7, but it's fixed now. If you're still having issues, please open an issue in the link above. Come on - did you really post that? I am TRYING to spend some time being able to FIX the bugs since that seems to be the requirement these days. I have not yet seen a fix for imagick, but I think that may be down to the fact that we have several forks of the code rather than it being part of php-src. THAT is just another minefield for those of us who are trying to play catchup. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 07/02/15 11:07, Pierre Joye wrote: Please double check the RFC, what it does, propose and its impact by default on existing codes. Call it doing your homework. Then reconsider your reply. There has always been a continual tread of 'you do not have to use it' in a lot of what currently slows PHP down. I still see little use to reflections, but my use of docblock annotation is being damaged by the libraries I rely on 'seeing the light' and switching to the new way of working. Adding 'strict' in a manor that these third party libraries can enable it or not as they feel fit is not the point. The very nature of an integer is now in a state of flux and either libraries have to add in extra checking for overflows that simply asking is_int is no longer going to supply so mixing that up with yet more exceptions does not seem the right way to move the language forward? If some third party can use it *I* have to add it to the library of things I have to understand simply because I will end up inside that library at some point. Unless I can request a 'non-strict' version. It may surprise people if I say that I would be more than happy with a hint/check system in here that provides a practical set of types beyond a simple 'integer'. That would then replace the current set of checks I use and would remove the need to now be worrying if the integers I am passing are too big. This ALL goes back to PDO which created a wedge that has resulted in a growing number of abstraction layers for handing data from database, much of which needs a common base of scalar values in the arrays then handled in PHP, rather than creating their own versions of those scalar entries. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors Update
Hi Levi, I have updated the RFC for removing PHP 4 constructors[1]. Notably, I have pushed off the removal to PHP 8, and instead only deprecate them in PHP 7. The rationale is that eventual consistency in this matter is good enough for now, and going slow may help avoid a Python 2 vs 3 type disaster where older libraries aren't updated fast enough. I intend to put this to vote soon, as we are approaching the March feature freeze, so please chime in if you have been wanting to voice your opinion and haven't. Over-long email - sorry about it! ;) I strongly opposed this RFC in past. I've also seen people suggesting to grumpy old men like me that the time spent complaining was probably enough to fix our legacy codebases to replace PHP4-constructors. That is certainly not true in my case, but I've decided to accept the challenge and build a tool to convert PHP4-constructors to __construct, automating the required tasks as much as possible. Such work is an ongoing PR to PHP-CS-Fixer[1], which will hopefully be merged in the next few weeks. I've advertised it before, but I'd like to do it again, as I think it greatly reduces the impact of the BC break of your RFC. I've ran it on the (legacy) open source application I maintain and it detected and converted most of the classes[2]: 962 changed files with 351 additions and 884 deletions. The only manual changes I had to do were fixing a few calls to the grandparent constructors[3]. What I can tell from this experience is that dropping PHP4-constructors shouldn't be quite as bad as I thought it was, at least now that there's a tool that does most of the job for you. Adapting (all of) PEAR should be fairly straightforward in case someone is willing to do that. The real challenge I will have to face in the future is the removal of Scoped calls of non-static methods from incompatible $this context, which has been applied and temporarily reverted soon after. Many PEAR (and possibly non-PEAR) classes in our codebase have methods that have been designed to work both as static/non-static methods[4] which won't soon work any more in PHP7. Granted, I've voted yes on this one and I still would today, but I'd expect that fixing that code once the revert is reverted is going to be much trickier than just renaming a bunch of constructors. So, given the level of breakages that legacy apps are going to endure anyway, I'd be ok with this RFC targeting PHP7 too. Cheers [1] https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/970 [2] http://qrurl.it/r/kz5 [3] http://qrurl.it/r/kz6 [4] https://github.com/pear/pear-core/blob/stable/PEAR.php#L303 -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Security changes in PHP 7
I've been trying to catch up on the plans in PHP 7 for changes in security features and APIs and I got confused. Questions on my mind at the moment include: 1. Will there be a portable API for getting random bytes from the platform's CSPRNG? https://wiki.php.net/ideas/php6 lists as an addition: Reliable, userfriendly RNG APIs: Provide a userfriendly and reliable RNG APIs, available by default, on all supported platforms and for all usages (from weak to crypto safe). 2. What's going to happen to mcrypt? I see the vote to excise it did not pass. Does this mean that (i.e. imply that) PHP's plan is to keep a security lib that hasn't been maintained for 8 years for the next 5+ years? 3. Will the OpenSSL ext remain as it currently stands? There have been a few discussions about this but I'm not clear if any decisions have been made about changing it or providing a new API. 4. What does openssl_random_pseudo_bytes() really do in PHP? Where does it get random bytes from in the various different platforms? Is it going to change in PHP 7? 5. Is the weird Linux /dev/random[1] still supported? If so, is used by default in any PHP API? 6. I noticed some work on constant-time functions. Is this for security purposes, i.e. defeating remote timing attacks? Is there an RFC? Feature Freeze for PHP 7 is coming soon. I, for one, would value a summary of what's happening in PHP 7 with respect to security topics like but not limited to these. Some kinda of document detailing the plan, if there is one, would be real swell. Tom --- [1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Pavel, On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote: On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds a...@ajf.me wrote: Good evening, At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. I just realized it now (I brought it up in a different manner when there was discussion about the RFC), but I didn't notice there was a totally false statement about it in the RFC itself. You probably should fix it. I'm speaking about the Strict type checking, which is used by many popular programming languages, particularly ones which are statically-typed, such as Java, C#, Haskell, or Facebook's Hack. It is also used for non-scalar parameter type hints in PHP. With this approach, an argument is only accepted if its type is exactly the same as the parameter. paragraph. This is NOT true (at least for C# and Java), as you can read here in the documentations of respecitve languages so you should not compare the strict version of the typing implemented in PHP with other strongly typed languages, because the PHP's strict is stricter than strongly static typed languages. I really hope noone voted with the thought that the strict typing acts as it does in Java and C#. https://msdn.microsoft.com/en-us/library/y5b434w4.aspx http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2 I don’t think it’s unfair. There’s a limited set of permitted conversions in some strictly-typed languages, but it’s still strictly-typed. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, On 7 Feb 2015, at 20:47, Andrea Faulds a...@ajf.me wrote: On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote: I just realized it now (I brought it up in a different manner when there was discussion about the RFC), but I didn't notice there was a totally false statement about it in the RFC itself. You probably should fix it. I'm speaking about the Strict type checking, which is used by many popular programming languages, particularly ones which are statically-typed, such as Java, C#, Haskell, or Facebook's Hack. It is also used for non-scalar parameter type hints in PHP. With this approach, an argument is only accepted if its type is exactly the same as the parameter. paragraph. This is NOT true (at least for C# and Java), as you can read here in the documentations of respecitve languages so you should not compare the strict version of the typing implemented in PHP with other strongly typed languages, because the PHP's strict is stricter than strongly static typed languages. I really hope noone voted with the thought that the strict typing acts as it does in Java and C#. https://msdn.microsoft.com/en-us/library/y5b434w4.aspx http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2 I don’t think it’s unfair. There’s a limited set of permitted conversions in some strictly-typed languages, but it’s still strictly-typed. To add to the previous email: * Most of these conversions are between different sizes of the same type (float/double, char/short/int/long, etc.), but this is irrelevant to PHP which has only one size for each type * The other ones are between types (int to float) * Always allowing implicit conversions from float to int is very likely to cause data loss, so it’s not unreasonable for PHP to prevent this specific case * Always allowing implicit conversions from int to float is sometimes going to cause data loss, so it may also be reasonable for PHP to prevent this specific case * Requiring an exact type match has the least mental overhead, and allows types to be checked at compile-time Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Idea of optimizing php !empty(...) expression.
I use !empty() very often and decided to make a benchmark test. Here is the code and results: http://pastebin.com/fMhhdQiW if (!empty(...)) working on 23% slower than if (empty()) expression. So if create new operator not_empty() it will improve performance. The first question is: What do you think about optimizing !empty(...), do we need it ? And I see two way to make this happen. 1. Create new language entity not_empty. 2. Improve parser and help to handle !empty calls different way. It is obviously that option 2 is better. Is it real to optimize parser that way? Thanks! -- Best Regards, Oleg
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
I'm wishing more and more that the RFC doesn't pass (even though I'd
LOVE to have typehints in PHP as a userland developer) and someone
else will make a better version of typehints RFC for PHP 7, because
this one feels really like you took an ok-ish RFC (one that would be
good for PHP) and slapped a strict typing on it without enough
research about strong typing in other languages. And as I said myself
multiple times in the past, the declare syntax IS just ugly (and
changing how code works by writing one line is an ugly principle as
well, IMHO). :(
I am not sure I would go that far. Andrea did plenty of research and has
tons of experience in other languages, I just think this approach is
misguided. I also wonder just how many people of those who voted even
bothered to download and try the patch. I tried it a while back on some
existing code and it was a nightmare. Does everyone realize that these
simple things break?
tan(1);
echo strstr(test, est, 1);
Having absolutely no coercion for int to float and 0/1 to false/true,
especially for internal functions, is just too pedantic to me. I also
find this a bit hypocritical:
declare(strict_types=true);
outputs:
Fatal error: strict_types declaration must have 0 or 1 as its value
That is obviously nit-picking, but if we are going to get this pedantic...
And, you also have to realize that it isn't actually per file. For
example, this:
?php
function myErrorHandler($errno, $errstr, $errfile, $errline) {
if ($errno===E_RECOVERABLE_ERROR) {
echo \ncatchable fatal error\n;
return true;
}
return false;
}
set_error_handler('myErrorHandler');
echo tan(1);
declare(strict_types=1);
echo tan(1);
declare(strict_types=0);
echo tan(1);
This will output:
1.5574077246549
catchable fatal error
1.5574077246549
The RFC refers to it as a per-file directive, which just means it
doesn't apply to files you include after setting it. It doesn't mean
that the entire file is affected. You can flip in and out of strict mode
at will. Which isn't necessarily a bad thing, but it can certainly get
confusing.
For example. Since everyone has already voted, you can all tell me what
this does, right?
1)
?php
function do_something() {
declare(strict_types=1);
}
echo tan(1);
do_something();
echo tan(1);
How about this:
2)
?php
echo tan(1);
do_something();
echo tan(1);
function do_something() {
declare(strict_types=1);
}
or this?
3)
?php
function do_something() {
declare(strict_types=1);
}
echo tan(1);
echo tan(1);
Answers:
1) fatal error on the first tan(1)
2) no errors
3) same as 1)
Basically declare() does not respect function scope, but it doesn't let
you know that. There is a reason we haven't used declare() for anything
real.
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi! * Requiring an exact type match has the least mental overhead, and allows types to be checked at compile-time What compile-time you're talking about? PHP has no compile time. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi! I don’t think it’s unfair. There’s a limited set of permitted conversions in some strictly-typed languages, but it’s still strictly-typed. The main problem with strict typing as it is being proposed by strictness proponents is exactly that - there's no limited set permitted. It leads to absurd limitations like 1 not accepted where a float value is required, or where a boolean value is required. That's the essential problem with this proposal - it sacrifices the frequent use cases that make sense to nearly everybody for abstract bondage-and-discipline notion under misguided assumption that it would be a service to the users. In fact, if forced to use this API, people would probably just learn to do (float) each time they call such function, which makes them just do more work for something they could have - and already do have, in internal functions - for free. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Security changes in PHP 7
On Feb 8, 2015 12:48 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: 2. What's going to happen to mcrypt? I see the vote to excise it did not pass. Does this mean that (i.e. imply that) PHP's plan is to keep a security lib that hasn't been maintained for 8 years for the next 5+ years? Removed. Available as PECL module. Probably. Please check the RFC. It is not removed and unless some people changed their mind the horrible scenario described here will happen. And it will be longer than 5 years.
[PHP-DEV] Re: Idea of optimizing php !empty(...) expression.
Oleg Serov wrote: I use !empty() very often and decided to make a benchmark test. Here is the code and results: http://pastebin.com/fMhhdQiW if (!empty(...)) working on 23% slower than if (empty()) expression. So if create new operator not_empty() it will improve performance. The first question is: What do you think about optimizing !empty(...), do we need it ? And I see two way to make this happen. 1. Create new language entity not_empty. 2. Improve parser and help to handle !empty calls different way. It is obviously that option 2 is better. Is it real to optimize parser that way? I see a third way: optimize this on the OPcode level, i.e. BOOL_NOT(X) + JMPZ(T) - NOP, JMPNZ(X). That is already done by OPcache[1]. [1] http://lxr.php.net/xref/PHP_5_5/ext/opcache/Optimizer/block_pass.c#816 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Security changes in PHP 7
Hi Pierre, On Sun, Feb 8, 2015 at 3:04 PM, Pierre Joye pierre@gmail.com wrote: On Feb 8, 2015 12:48 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: 2. What's going to happen to mcrypt? I see the vote to excise it did not pass. Does this mean that (i.e. imply that) PHP's plan is to keep a security lib that hasn't been maintained for 8 years for the next 5+ years? Removed. Available as PECL module. Probably. Please check the RFC. It is not removed and unless some people changed their mind the horrible scenario described here will happen. And it will be longer than 5 years. https://wiki.php.net/start#extmcrypt Voted +1 -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Idea of optimizing php !empty(...) expression.
Hi Oleg, this is already accomplished. if (! exp) stat would usually be compiled to: 1: exp 2: NOT 3: JMPZ - 5 4: stat 5: ... But OpCache's built-in optimizer (https://github.com/php/php-src/blob/master/ext/opcache/Optimizer/block_pass.c) is able to recognize this during the block level analysis and creates the following opcodes for the Zend engine: 1: exp 2: JMPNZ - 4 3: stat 4: ... Please note that NOT+JMPZ are converted to an equivalent single opcode JMPNZ. An extra NOT_EMPTY opcode is therefore not necessary. I do not quite understand why you experience a performance difference, probably OpCache is not enabled or optimization flags are not properly set. Please see http://php.net/manual/en/book.opcache.php for more info. Cheers, Benjamin Coutu == Original == From: Oleg Serov sero...@gmail.com To: internals@lists.php.net Date: Sun, 08 Feb 2015 00:13:05 +0100 Subject: [PHP-DEV] Idea of optimizing php !empty(...) expression. I use !empty() very often and decided to make a benchmark test. Here is the code and results: http://pastebin.com/fMhhdQiW if (!empty(...)) working on 23% slower than if (empty()) expression. So if create new operator not_empty() it will improve performance. The first question is: What do you think about optimizing !empty(...), do we need it ? And I see two way to make this happen. 1. Create new language entity not_empty. 2. Improve parser and help to handle !empty calls different way. It is obviously that option 2 is better. Is it real to optimize parser that way? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Idea of optimizing php !empty(...) expression.
Thanks, with enabled opcache works fine. On 7 February 2015 at 19:35, Christoph Becker cmbecke...@gmx.de wrote: Oleg Serov wrote: I use !empty() very often and decided to make a benchmark test. Here is the code and results: http://pastebin.com/fMhhdQiW if (!empty(...)) working on 23% slower than if (empty()) expression. So if create new operator not_empty() it will improve performance. The first question is: What do you think about optimizing !empty(...), do we need it ? And I see two way to make this happen. 1. Create new language entity not_empty. 2. Improve parser and help to handle !empty calls different way. It is obviously that option 2 is better. Is it real to optimize parser that way? I see a third way: optimize this on the OPcode level, i.e. BOOL_NOT(X) + JMPZ(T) - NOP, JMPNZ(X). That is already done by OPcache[1]. [1] http://lxr.php.net/xref/PHP_5_5/ext/opcache/Optimizer/block_pass.c#816 -- Christoph M. Becker -- Best Regards, Oleg
Re: [PHP-DEV] Security changes in PHP 7
Hi Tom, On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster f...@thefsb.org wrote: 1. Will there be a portable API for getting random bytes from the platform's CSPRNG? https://wiki.php.net/ideas/php6 lists as an addition: Reliable, userfriendly RNG APIs: Provide a userfriendly and reliable RNG APIs, available by default, on all supported platforms and for all usages (from weak to crypto safe). Pierre, What the status? 2. What's going to happen to mcrypt? I see the vote to excise it did not pass. Does this mean that (i.e. imply that) PHP's plan is to keep a security lib that hasn't been maintained for 8 years for the next 5+ years? Removed. Available as PECL module. Probably. 3. Will the OpenSSL ext remain as it currently stands? There have been a few discussions about this but I'm not clear if any decisions have been made about changing it or providing a new API. Not sure on this 4. What does openssl_random_pseudo_bytes() really do in PHP? Where does it get random bytes from in the various different platforms? Is it going to change in PHP 7? It's depend on openssl. What openssl does is what it does. 5. Is the weird Linux /dev/random[1] still supported? If so, is used by default in any PHP API? Session module use it. /dev/urandom or /dev/arundom 6. I noticed some work on constant-time functions. Is this for security purposes, i.e. defeating remote timing attacks? Is there an RFC? No, but there is patch. Status? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Security changes in PHP 7
On Sun, Feb 8, 2015 at 1:43 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Pierre, On Sun, Feb 8, 2015 at 3:04 PM, Pierre Joye pierre@gmail.com wrote: On Feb 8, 2015 12:48 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: 2. What's going to happen to mcrypt? I see the vote to excise it did not pass. Does this mean that (i.e. imply that) PHP's plan is to keep a security lib that hasn't been maintained for 8 years for the next 5+ years? Removed. Available as PECL module. Probably. Please check the RFC. It is not removed and unless some people changed their mind the horrible scenario described here will happen. And it will be longer than 5 years. https://wiki.php.net/start#extmcrypt Voted +1 Not sure what this RFC is (did not dig the list as the link is wrong). However the latest on the topic is here and it is does not look remotely close to a approval: https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Security changes in PHP 7
Hi Pierre, On Sun, Feb 8, 2015 at 3:51 PM, Pierre Joye pierre@gmail.com wrote: Not sure what this RFC is (did not dig the list as the link is wrong). However the latest on the topic is here and it is does not look remotely close to a approval: https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts Sorry my copy buffer had wrong URL... I voted +1 for mcrypt. It's 12 vs. 13 now. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, On 7 Feb 2015, at 22:03, Pavel Kouřil pajou...@gmail.com wrote: On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds a...@ajf.me wrote: Hi, On 7 Feb 2015, at 20:47, Andrea Faulds a...@ajf.me wrote: On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote: I just realized it now (I brought it up in a different manner when there was discussion about the RFC), but I didn't notice there was a totally false statement about it in the RFC itself. You probably should fix it. I'm speaking about the Strict type checking, which is used by many popular programming languages, particularly ones which are statically-typed, such as Java, C#, Haskell, or Facebook's Hack. It is also used for non-scalar parameter type hints in PHP. With this approach, an argument is only accepted if its type is exactly the same as the parameter. paragraph. This is NOT true (at least for C# and Java), as you can read here in the documentations of respecitve languages so you should not compare the strict version of the typing implemented in PHP with other strongly typed languages, because the PHP's strict is stricter than strongly static typed languages. I really hope noone voted with the thought that the strict typing acts as it does in Java and C#. https://msdn.microsoft.com/en-us/library/y5b434w4.aspx http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2 I don’t think it’s unfair. There’s a limited set of permitted conversions in some strictly-typed languages, but it’s still strictly-typed. To add to the previous email: * Most of these conversions are between different sizes of the same type (float/double, char/short/int/long, etc.), but this is irrelevant to PHP which has only one size for each type * The other ones are between types (int to float) * Always allowing implicit conversions from float to int is very likely to cause data loss, so it’s not unreasonable for PHP to prevent this specific case * Always allowing implicit conversions from int to float is sometimes going to cause data loss, so it may also be reasonable for PHP to prevent this specific case * Requiring an exact type match has the least mental overhead, and allows types to be checked at compile-time Yeah, but you say in the RFC that With this approach, an argument is only accepted if its type is exactly the same as the parameter. when speaking about C# and Java - which is NOT true. C# and Java aren’t really considered weakly-typed. Technically they’re not “fully strict” I guess, but if you were to give example of strictly-typed languages, you’d probably include C# and Java in that list - so I did. You should have written that the way of strict typing in PHP is even more strict than Java's and C# one - because the way it's written now is unfortunately misinforming the readers of the RFC. It might be somewhat misleading. Really, what’s “weak” and what’s “strict” is rather subjective: C is sometimes considered weak, sometimes strict. I’d say it’s more “weak” because all sorts of definitely wrong conversions are allowed implicitly and merely generate warnings. C# and Java are more careful here, so I’d say they’re “strict” even though I suppose they do have a degree of weak typing. Also, there's no need to mention float - int, because that one is definitely wrong. But for the int (and long, etc) - float (and double) - how do the languages you mentioned in the RFC handle that conversion? From Microsoft’s documentation that you linked, it sounds like they just always convert and never error, so you’d get data loss in some cases (just like you do in PHP with an explicit cast). I'm wishing more and more that the RFC doesn't pass (even though I'd LOVE to have typehints in PHP as a userland developer) and someone else will make a better version of typehints RFC for PHP 7, because this one feels really like you took an ok-ish RFC (one that would be good for PHP) and slapped a strict typing on it without enough research about strong typing in other languages. I am familiar with other languages, I just disagree with their approach. And as I said myself multiple times in the past, the declare syntax IS just ugly (and changing how code works by writing one line is an ugly principle as well, IMHO). :( I prefer this approach to the inconsistency the other approaches suggested thus far lead to. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds a...@ajf.me wrote: Hi, On 7 Feb 2015, at 20:47, Andrea Faulds a...@ajf.me wrote: On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote: I just realized it now (I brought it up in a different manner when there was discussion about the RFC), but I didn't notice there was a totally false statement about it in the RFC itself. You probably should fix it. I'm speaking about the Strict type checking, which is used by many popular programming languages, particularly ones which are statically-typed, such as Java, C#, Haskell, or Facebook's Hack. It is also used for non-scalar parameter type hints in PHP. With this approach, an argument is only accepted if its type is exactly the same as the parameter. paragraph. This is NOT true (at least for C# and Java), as you can read here in the documentations of respecitve languages so you should not compare the strict version of the typing implemented in PHP with other strongly typed languages, because the PHP's strict is stricter than strongly static typed languages. I really hope noone voted with the thought that the strict typing acts as it does in Java and C#. https://msdn.microsoft.com/en-us/library/y5b434w4.aspx http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2 I don’t think it’s unfair. There’s a limited set of permitted conversions in some strictly-typed languages, but it’s still strictly-typed. To add to the previous email: * Most of these conversions are between different sizes of the same type (float/double, char/short/int/long, etc.), but this is irrelevant to PHP which has only one size for each type * The other ones are between types (int to float) * Always allowing implicit conversions from float to int is very likely to cause data loss, so it’s not unreasonable for PHP to prevent this specific case * Always allowing implicit conversions from int to float is sometimes going to cause data loss, so it may also be reasonable for PHP to prevent this specific case * Requiring an exact type match has the least mental overhead, and allows types to be checked at compile-time Yeah, but you say in the RFC that With this approach, an argument is only accepted if its type is exactly the same as the parameter. when speaking about C# and Java - which is NOT true. You should have written that the way of strict typing in PHP is even more strict than Java's and C# one - because the way it's written now is unfortunately misinforming the readers of the RFC. Also, there's no need to mention float - int, because that one is definitely wrong. But for the int (and long, etc) - float (and double) - how do the languages you mentioned in the RFC handle that conversion? I'm wishing more and more that the RFC doesn't pass (even though I'd LOVE to have typehints in PHP as a userland developer) and someone else will make a better version of typehints RFC for PHP 7, because this one feels really like you took an ok-ish RFC (one that would be good for PHP) and slapped a strict typing on it without enough research about strong typing in other languages. And as I said myself multiple times in the past, the declare syntax IS just ugly (and changing how code works by writing one line is an ugly principle as well, IMHO). :( Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Feb 8, 2015 10:52 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/07/2015 09:51 PM, Andrea Faulds wrote: tan(1); echo strstr(test, est, 1); Banning int-float and float-int is both a pain point and sometimes a life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you discover if your ints floats would be silently truncated (as I did with PictoSwap). I wouldn’t say that int-string not working is a problem, though. Seeing something like strstr(“test”, “est”, 1); is rather confusing. Looking at it, I’d think the third parameter is some sort of number for you to want to pass an integer to it. If I want a string, I’ll use one. This isn't int-string. This is int-boolean. The 3rd arg to strstr() is a boolean and passing 1 instead of true makes it blow up. It is very very common for people to pass 0 or 1 in place of true/false to all sorts of things in PHP. Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one sense (like encoding, but unlike ticks, it has no effect on the including or included files). However, it technically affects the remainder of the file, not the whole file. Well, no, not the remainder of the file either since it can be switched again. It only affects the part of the file between declares if there is a second one. For this specific weirdness it should really be fixed somehow, like for namespace. It has to be used at the top of a file. As it is a compile time thing, the extra check should not have much impact.
Re: [PHP-DEV] [VOTE] Scalar Type Hints
...cases that make sense to nearly everybody for abstract bondage-and-discipline notion Well, the 50 Shades of Grey movie is coming out soon, so let's wait and see how that does. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 02/07/2015 09:51 PM, Andrea Faulds wrote: tan(1); echo strstr(test, est, 1); Banning int-float and float-int is both a pain point and sometimes a life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you discover if your ints floats would be silently truncated (as I did with PictoSwap). I wouldn’t say that int-string not working is a problem, though. Seeing something like strstr(“test”, “est”, 1); is rather confusing. Looking at it, I’d think the third parameter is some sort of number for you to want to pass an integer to it. If I want a string, I’ll use one. This isn't int-string. This is int-boolean. The 3rd arg to strstr() is a boolean and passing 1 instead of true makes it blow up. It is very very common for people to pass 0 or 1 in place of true/false to all sorts of things in PHP. Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one sense (like encoding, but unlike ticks, it has no effect on the including or included files). However, it technically affects the remainder of the file, not the whole file. Well, no, not the remainder of the file either since it can be switched again. It only affects the part of the file between declares if there is a second one. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Rasmus,
On 8 Feb 2015, at 02:38, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
I'm wishing more and more that the RFC doesn't pass (even though I'd
LOVE to have typehints in PHP as a userland developer) and someone
else will make a better version of typehints RFC for PHP 7, because
this one feels really like you took an ok-ish RFC (one that would be
good for PHP) and slapped a strict typing on it without enough
research about strong typing in other languages. And as I said myself
multiple times in the past, the declare syntax IS just ugly (and
changing how code works by writing one line is an ugly principle as
well, IMHO). :(
I am not sure I would go that far. Andrea did plenty of research and has
tons of experience in other languages, I just think this approach is
misguided. I also wonder just how many people of those who voted even
bothered to download and try the patch. I tried it a while back on some
existing code and it was a nightmare. Does everyone realize that these
simple things break?
tan(1);
echo strstr(test, est, 1);
Banning int-float and float-int is both a pain point and sometimes a
life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you
discover if your ints floats would be silently truncated (as I did with
PictoSwap).
I wouldn’t say that int-string not working is a problem, though. Seeing
something like strstr(“test”, “est”, 1); is rather confusing. Looking at it,
I’d think the third parameter is some sort of number for you to want to pass an
integer to it. If I want a string, I’ll use one.
Having absolutely no coercion for int to float and 0/1 to false/true,
especially for internal functions, is just too pedantic to me. I also
find this a bit hypocritical:
declare(strict_types=true);
outputs:
Fatal error: strict_types declaration must have 0 or 1 as its value
That is obviously nit-picking, but if we are going to get this pedantic…
Yes, that is a cruel irony that I did notice when I changed it. I sacrificed
strictness/“correctness” there for brevity. The reason you can’t use a boolean
is that I think it’s better if only two forms are allowed (=0 and =1) - less
forms to remember, less ambiguity.
And, you also have to realize that it isn't actually per file. For
example, this:
?php
function myErrorHandler($errno, $errstr, $errfile, $errline) {
if ($errno===E_RECOVERABLE_ERROR) {
echo \ncatchable fatal error\n;
return true;
}
return false;
}
set_error_handler('myErrorHandler');
echo tan(1);
declare(strict_types=1);
echo tan(1);
declare(strict_types=0);
echo tan(1);
This will output:
1.5574077246549
catchable fatal error
1.5574077246549
The RFC refers to it as a per-file directive, which just means it
doesn't apply to files you include after setting it. It doesn't mean
that the entire file is affected. You can flip in and out of strict mode
at will. Which isn't necessarily a bad thing, but it can certainly get
confusing.
Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
sense (like encoding, but unlike ticks, it has no effect on the including or
included files). However, it technically affects the remainder of the file, not
the whole file.
For example. Since everyone has already voted, you can all tell me what
this does, right?
1)
?php
function do_something() {
declare(strict_types=1);
}
echo tan(1);
do_something();
echo tan(1);
I don’t understand why it’s even allowed for the declare() statement to be used
like that (why is a compile-time option allowed to be within a function? That’s
a recipe for disaster), but that would make the first tan(1); error and halt
program execution.
How about this:
2)
?php
echo tan(1);
do_something();
echo tan(1);
function do_something() {
declare(strict_types=1);
}
First two calls succeed. Again, declare()’s behaviour is weird… makes me wonder
who thought it was a good idea to allow this.
or this?
3)
?php
function do_something() {
declare(strict_types=1);
}
echo tan(1);
echo tan(1);
That would make the first tan(1); error and halt program execution.
Answers:
1) fatal error on the first tan(1)
2) no errors
3) same as 1)
Hooray, I guessed right.
Basically declare() does not respect function scope, but it doesn't let
you know that. There is a reason we haven't used declare() for anything
real.
I wonder if we should just remove this ability of declare(); or at least
produce some sort of warning (E_DEPRECATED? E_WARNING? E_STRICT?). It’s highly
misleading and I don’t really understand why it’s allowed.
Then again, that would cause problems for ticks, possibly?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi,
On 8 Feb 2015, at 02:51, Andrea Faulds a...@ajf.me wrote:
Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
sense (like encoding, but unlike ticks, it has no effect on the including or
included files). However, it technically affects the remainder of the file,
not the whole file.
A minor follow-up: the RFC does actually mention this specific point about
declare()’s behaviour:
By default, all PHP files are in weak type-checking mode. A new declare()
directive is added, strict_types, which takes either 1 or 0. If 1, strict
type-checking mode is used for function calls and return statements in the
remainder of the file. If 0, weak type-checking mode is used.
This directive also supports the declare() block syntax (e.g.
declare(strict_types=1) { foo(); }), in which case it will only affect
function calls and return statements within the block.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, On 8 Feb 2015, at 03:52, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/07/2015 09:51 PM, Andrea Faulds wrote: tan(1); echo strstr(test, est, 1); Banning int-float and float-int is both a pain point and sometimes a life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you discover if your ints floats would be silently truncated (as I did with PictoSwap). I wouldn’t say that int-string not working is a problem, though. Seeing something like strstr(“test”, “est”, 1); is rather confusing. Looking at it, I’d think the third parameter is some sort of number for you to want to pass an integer to it. If I want a string, I’ll use one. This isn't int-string. This is int-boolean. The 3rd arg to strstr() is a boolean and passing 1 instead of true makes it blow up. It is very very common for people to pass 0 or 1 in place of true/false to all sorts of things in PHP. Oh, my bad, I looked up strtr and not strstr. I’m not sure that disallowing implicit integer-boolean conversion is bad, though. That conversion will discard all data except whether the value is non-zero. If you opt in to strict typing, then you have chosen to always use the correct types. Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one sense (like encoding, but unlike ticks, it has no effect on the including or included files). However, it technically affects the remainder of the file, not the whole file. Well, no, not the remainder of the file either since it can be switched again. It only affects the part of the file between declares if there is a second one. Sure, that’s true, the option can be changed more than once. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sun, Feb 8, 2015 at 11:33 AM, Pierre Joye pierre@gmail.com wrote: Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one sense (like encoding, but unlike ticks, it has no effect on the including or included files). However, it technically affects the remainder of the file, not the whole file. Well, no, not the remainder of the file either since it can be switched again. It only affects the part of the file between declares if there is a second one. For this specific weirdness it should really be fixed somehow, like for namespace. It has to be used at the top of a file. As it is a compile time thing, the extra check should not have much impact. and it was also not correct that we never used declare for such things. http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_compile.c#3776 about encoding. And it has to get this exact kind of check for the exact same reasons. In other words, we can use the same solution. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dragging the legacy users forward.
Hi Lester, On Sat, Feb 7, 2015 at 9:36 PM, Lester Caine les...@lsces.co.uk wrote: PHP7 is proposing a LOT of shiny new features which will break much legacy code. So the question has to be just what is the plan regarding cross version support. I see that the general consensus is PHP5 should just run? Do you mean release 5.7 or extend life of 5.6? I'm +1 for both options. Extending 5.6 life may achieved consensus. Perhaps, 2 year security support? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
