[PHP-DEV] hints and constraints
Been tied up with a family matter for the last couple of days, so I've not been able to read all 200 posts in my in box for internals. Whilst I've been away from the computer I've had time to contemplate, and I think we need to summarise the discussions in a different way. A number of disjointed threads currently exist, which are actually more closely related! When PHP5 was evolving, the majority of systems were still 32bit constrained, although 64bit hardware was well established. At that time an 'integer' was also constrained to 32bit. The evolution to 64bit has again in hindsight not been well handled and currently promoting an integer to float to gain access to a 64 bit integer has a number of black holes, so care has to be taken NOT to allow that when dealing with a BIGINT value. The development of 64bit builds has now muddied the water further as a check has to be made as to just what the constraints are on an integer before progressing. Code written for a 64bit build may not work as expected on a 32bit one, and it was this black hole I was originally trying to address. Can I please rename the 'big integer' rfc to 'unconstrained integer' for two reasons. One BIGINT does have well established definitions in the last 10+ years of PHP and other code bases. Two - it more accurately defines the situation which then allows other discussions to be clearer. If the current 'constrained' integer is promoted to 'unconstrained', it introduces another layer of checking which up until now has not been necessary. Where the bulk of the code currently assumes an integer is 32bit, all of that code now needs to be reviewed to see what the effect of now passing an unconstrained integer will be. There is a demand for 'strict' which to a certain extent I can understand, but if that is combined with an unconstrained integer definition, then a large section of the code base will need to be reworked to add back the natural checking that the 32bit constraint provides. If I am passing variables between functions, then I need to add some additional checks, but both of these moves add another level of complexity which is not 'constrained' by the core framework. If I want to 'hint' that a parameter is an integer then personally that is a 32bit constrained value. Similarly 64bit is bigint and 16bit is smallint. If the only hint or strict check is 'unconstrained integer' then I see little value in even bothering with it, but if I can hint at 'integer' and know that any other database system is providing the same constrained integer then it has some purpose. While it would be nice simply to ignore any limit, in practice we have a well defined set of limits, which currently PHP does not respect as well as it should do. I would be a little happier to accept hints and constraints that had a practical use, but I don't see any of the current proposals providing a useful endpoint, only asking us to create even more code to restore clean operation of legacy code! At the very least, some means of providing a central 'constraint' method which can be switched on in much the way that 'strict' is currently being proposed, but I don't feel that is 'the PHP way' and some of the flexibility PHP currently provides is actually constrined in a much more practical manor than the current proposals. -- 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] hints and constraints
On 05/02/15 11:37, Andrea Faulds wrote: > Hi Lester, > >> On 5 Feb 2015, at 10:58, Lester Caine wrote: >> >> Can I please rename the 'big integer' rfc to 'unconstrained integer' for >> two reasons. One BIGINT does have well established definitions in the >> last 10+ years of PHP and other code bases. > > This is not true. The terms ‘arbitrary-precision integer’, ‘bignum’ and > ‘bigint’ have quite well-defined meanings. Yes, “bigint” is also used in SQL > to mean a 64-bit integer, but SQL is the odd one out, and anyone who has read > the RFC will understand that it is not the SQL kind we are talking about. All my C++ has smallint, int and bigint ... and has for years. >> Two - it more accurately >> defines the situation which then allows other discussions to be clearer. > > The current description isn’t totally inaccurate, but I had considered > renaming the RFC since “big integer support” implies we don’t already have > support for big integers, though we do in the form of ext/gmp. A better title > for the RFC might be “make PHP integer type be arbitrary-precision”. Still, > it’s a minor issue at best. Current integer variable has a constrained value. 64bit 'fixes' have created a new set of rules to go with that. gmp support removes those limits ... >> If the current 'constrained' integer is promoted to 'unconstrained', it >> introduces another layer of checking which up until now has not been >> necessary. Where the bulk of the code currently assumes an integer is >> 32bit, all of that code now needs to be reviewed to see what the effect >> of now passing an unconstrained integer will be. > > That code is also broken on 64-bit platforms, and has been for a decade. > Actually, longer: x86 wasn’t the first architecture to support 64-bit, but it > supporting it certainly increased the prominence of 64-bit computing. Broken in a way that was managable, but it is only in the last few years that windows itself has become 64bit although 32bit builds are still required in a number of marketplaces since 64bit ones don't work. That the transition has not been handled well applies everywhere! >> There is a demand for 'strict' which to a certain extent I can >> understand, but if that is combined with an unconstrained integer >> definition, then a large section of the code base will need to be >> reworked to add back the natural checking that the 32bit constraint >> provides. > > Again, there isn’t a 32-bit constraint, PHP only has an integer constraint. > Actually, PHP has never had an integer type hint, so I don’t know what you > mean by “add back the natural checking” - there was never any such check. CURRENTLY when an integer is too big it becomes a float. Check for float used to flag up that the integer was bigger than 32 bit because one was running a 32bit version of PHP but now flags up that some extra checks are needed, but is_int identifies a constrained integer. >> If I am passing variables between functions, then I need to >> add some additional checks, but both of these moves add another level of >> complexity which is not 'constrained' by the core framework. If I want >> to 'hint' that a parameter is an integer then personally that is a 32bit >> constrained value. > > Only if you’re on a 32-bit system. PHP has had 64-bit integers for a long > time now. See above. >> Similarly 64bit is bigint and 16bit is smallint. If >> the only hint or strict check is 'unconstrained integer' then I see >> little value in even bothering with it, but if I can hint at 'integer' >> and know that any other database system is providing the same >> constrained integer then it has some purpose. > > Hints have usefulness beyond that of typing SQL data. Actually, you really > shouldn’t rely on PHP to ensure your integers fit database fields anyway. > Databases offer 8-bit, 16-bit, 32-bit, 64-bit, sometimes even larger sizes. > At any given time, PHP’s integer type is only going to correspond to one of > those, or perhaps none of those. PHP isn’t obligated to provide you with > types for multiple integer sizes. It’s a dynamic language that doesn’t need > such things, it only needs one size of integer. PHP is designed for rapid > development of applications and for ease of use, not for ultra-high > performance. If you want to ensure an integer fits in a database column, that > is your, or the database’s, responsibility. This is an area where PDO was supposed to help, but I still prefer ADOdb's handling of this. That will need major work to make work with your model of PHP7 :( *I* would like to be able to handle the real wor
Re: [PHP-DEV] hints and constraints
On 05/02/15 16:24, Rowan Collins wrote: >> The simple answer here is that there is not a 'single' definition of >> integer ... > > True. But the definition of "integer" in PHP is, and has been for many > years, "as big as this build can handle". With Andrea's patch, all > systems can handle really really big integers, which seems like a big > win to me. Have no argument with the statement - but implementing it creates a need for a BC compatible constrained integer. So we have the situation where the option for an unconstrained integer is already available via the extension, so does it make sense to make it the default since it also requires a lot more code to handle the constrained cases. The problems between 32 and 64 bit builds still needs to be handled where other 'integer' values don't have the luxury unlimited counts, but simply ignoring the limits does not make sense. The discussion is a little like debate as to if mbstring should be part of core or remain an add-on. Who gets the biggest gain or loss from each option? Just as in my book there is no single 'integer' constraint, there is no single 'string' constraint. A string length/position can't be stored in an unconstrained integer, so we need a constrained holder for that and it's limits depend on the type of string being stored and the platform. -- 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] Annotated PHP 5->7 extension diff
On 05/02/15 22:28, Rasmus Lerdorf wrote: > https://gist.github.com/anonymous/15cbc9947edb4f0a71fd > > Any suggestions for how to handle annotating it? We could turn it into a > fake PR and mark it up using github's PR comments. But is there > something more suited for this out there? A few extra notes on the commit would have helped. And breaking down some of the bigger changes to individual 'reasons'. But http://hg.lsces.org.uk/hg/php-memcached/rev/c3c53d0ef330 is just a little easier to read and I can scroll through the changes. It DOES need a good set of examples to work from, and the assortment of changes to imagick are more difficult to understand. -- 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] Re: [RFC][DISCUSSION] script() and script_once()
On 06/02/15 05:01, Yasuo Ohgaki wrote: >> But it is the key point. It is not PHP role to do it. PHP is not >> > alone. It is a server configuration job. But I have said that already >> > many times, we got our points :) > I understand your point. > > We need both OS and PHP feature for perfection. Both of them are required. > > Current PHP just reads & executes all accessible files by include. > I think you understand my point, too :) The question is essentially CAN one prevent PHP on it's own from running things it shouldn't. In order to prevent people who do not understand the security risks from 'making a mistake'. The answer is probably only yes for a distribution that only comes from PHP. Other distributions are not following guidelines now so expecting them to do in the future is questionable? This is more about education of the whole infrastructure but I don't see the point of yet another load mechanism? I thought we had introduced all the necessary restrictions on include and require already? From a 'nannying' point of view I would have thought it was that hole which needed plugging since the people you are trying to protect will not use a new mechanism anyway? I hope that I have my own installations configured such that one can't upload material on-line that can be accessed but having to ensure third party libraries are using 'script' rather than 'include/require' seems a little problematic ... -- 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] Annotated PHP 5->7 extension diff
On 06/02/15 16:16, Dan Ackroyd wrote: > Also, I found it useful when converting Imagick to have a checklist of > everything that needed to be done, in a simple format, rather than the > full explanation of the changes at Is that in a publishable format Dan? I'm looking to pull magickwand up as well but still a little lost on what needs doing ... Also I still have not fathomed out why I don't get a list of extensions for imagick ... -- 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
[PHP-DEV] Pointers to understanding code base
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 ? 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] 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] 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
[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] [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] Dragging the legacy users forward.
On 08/02/15 06:37, Yasuo Ohgaki wrote: > Hi Lester, > > 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? Well I don't remember any such restriction on PHP4? Although there is still a compatibility library to emulate some later features where PHP4 did not provide them. But we are only talking about 'PHP4' being stable up to PHP5.2 and quoting periods here is irrelevant. Nobody is currently taking any notice of the fact HP5.2 and 5.3 are no longer supported and it's that the removal of features was badly managed that has created this problem. >From a day to day survival point of view I have to decide what to do with currently functional sites that ARE still on PHP5.2 hosting. The bulk of the sites that have been moved to PHP5.4 still require regular work because people keep finding fault with one mobile device or another not displaying 'bootstrap3' properly which is another major upgrade path that is the MAIN reason for reworking sites and the one that prevents simple sticking plasters to hack PHP changes. I spent most of yesterday trying to get a key component of a financial site into a format that it could even be used on a mobile phone. And failed, so now I have to find another way to meet the LEGAL requirement that the customer has to comply with. So in general no I'm not talking about having to fix PHP5 code to some PHP7 compliant state, I AM talking about current PHP5 code simply working as PHP4 did into PHP5 hosting! CURRENTLY my php7 test site is running PHP5.4 live code so I don't think I'm out of line here, but if something goes in which causes my php7 test site to crash then I would prefer that to be sorted by PHP7 rather than having to upgrade to some as yet unavailable PHP5.x, although I would be more than happy if I can simply amend the live code and make both work. -- 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] Dragging the legacy users forward.
On 08/02/15 11:43, Ralf Lang wrote: > A lot of sites sticked with PHP5.3 because they were driven by > enterprise platforms which by definition won't upgrade during the life > cycle. That had its own costs and aches which are entirely not PHP's fault. > >> > PHP7 is proposing a LOT of shiny new features which will break much >> > legacy code. > Which features hurt you? Which features break code which would have been > best practice by php 5.0.0? Currently it is impossible to run the PHP5.2 code base on PHP5.4. That is a simple fact. So I can't do between 5.2 and 5.4 what I am currently doing between 5.4 and 7. The code has to be reworked ... so what ever anybody says PHP5 .4 *IS* PHP6 in terms of major breaks. 'Best Practice' is at best dependent on just what style of working a particular faction wants. Is 'strict typing' an example of future best practice? Is e_strict compliant code best practice? It is that which I base the move from 5.2 to 5.4 on. If I add a library using namespaces often things fail to work so I stick with the 'non-namespace' version? Best practice these days is I suppose to be using composer for everything? None of this was around by 5.0.0 days yet the bulk of my framework code is well over 10 years old and at one time one could select you preferred database install and run. Nowadays just keeping a small subset of database engines working is all we can manage. PHP is no longer the simple user friendly base that it once was! -- 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] Dragging the legacy users forward.
On 08/02/15 19:00, Rowan Collins wrote: > We have a single code base happily running on 5.2, 5.3, 5.4, and I think > even 5.5, so it is definitely possible with some code bases. There were > a few pieces that had to be changed to work right under 5.3 and 5.4, but > none for which the new solution didn't also work under 5.2 (or, at > least, for which a compromise didn't exist which worked under both). > Call-time pass-by-reference was all over the place, for instance, but > rarely actually needed, and if it was, replacing it with a > pass-by-reference declaration would leave you with something working > fine under 5.2. Rewriting the the code to make it work is exactly what is taking the time, but I DID also adopt the standard that e_strict would be required and up until that time all the code I was involved with ran with display_errors ON which was a conscious choice to pick up problems that crept in when they happened rather than having to trawl through hundreds of log files every few days. Remove 'register_globals' and a site breaks until such time as the code is reworked, but that code also needs to be brought up to a better standard rather than simply hacking the register_globals and other removed or backwards incompatible problems. Since a large part of the code I am now supporting I did not write, simply trying to decipher some of the strange tricks coders used to get up to is a nightmare, and some of the new 'styles' of writing things are going to make things considerably worse for those who are going to have to maintain this code in the future. There are several pages of things that were good practice in PHP5.0 code which will now give white screens if one tries to run them on a 'good practice' PHP5.4 setup. Fortunately I think that I've already covered most of the later problems in trying to make the legacy code clean e_strict code so switching from 5.4 to 5.6 should not cause a problem, but I'm not ready to move production beyond 5.4 as yet. If I was only worried about a couple of sites then things would be different, but the current catalogue is some 120 different sites some of which are pigging ASP and I will be glad when I can finally pull them over to PHP. -- 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
[PHP-DEV] Managing builds via Eclipse
Does anybody have a working Eclipse setup for building php-src and extensions? I keep hitting 'phpsrc' when I try using google which just about sums up how bad google is these days :( As soon as one tries to drill down all one gets is pages with php in the url ... -- 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] Dragging the legacy users forward.
On 09/02/15 00:05, Rowan Collins wrote: >> Some of the new 'styles' of writing things are >> going to make things considerably worse for those who are going to have >> to maintain this code in the future. > > If you're writing code that you know will be hard to maintain in the > future, you're doing something wrong. If by slavishly following a style > guide you've ended up with a poor architecture, you need a better style > guide, or a better understanding of why those styles are preferred. > > Alternatively, I may have misunderstood that sentence, in which case I > apologise in advance. Something *I* have been asking for for the last few years IS a better 'style guide' ... There are a growing number of 'styles' and the current debate is to allow even more! Just about every framework has a different style of handling database abstraction, and that seems to change every major version as well. All of my own code is based around ADOdb, but now it seems THAT is not an acceptable style of code these days. Anyway I now have PHP56.lsces.org.uk running with the latest PHP5. It's throwing megabytes of data into the error log but there ACTUALLY seem to be less in the php7 error log ... need to figure that out, but I've currently hit the latest brick wall as mbstring is not compiling! Most of the others have compiled fine, but currently there is a blank front page until I can work out what is going wrong ... that and smarty is throwing errors ... -- 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 09/02/15 10:44, Andrea Faulds wrote: > There is no consensus whatsoever. To suggest there is would be to grossly > exaggerate. I am just happy that to force change through a 2/3rds majority is required. If there was a consensus then the debate would not have been so extensive, but while the continuing chant of 'you don't have to use it' prevails, we end up with a lot of additional overheads just to keep a small number of users happy. In the case of this vote, the vote itself IS flawed as two different additions ARE being pushed together, and personally I feel that the yes vote IS being distorted by those who want weak typing and could not care less about strong typing. That neither of the proposed solutions actually provide a complete solution for either camp is a shame. I do understand why many of these extras can't simply be user selectable extensions, but just how many of the 'core' modules are actually needed for a basic PHP server. Yes I need 'typing' but I need a version that handles the types I am using not some rather limited subset, and improvements in PHP7 has increased the need for a proper typing system which scalar type hints does nothing to address :( -- 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] Annotated PHP 5->7 extension diff
On 09/02/15 15:03, Jan Ehrhardt wrote: > Despite the extensive list of changes, imagick does not compile anymore > with the current PHP7 git head (Win32 VC11). OK another day wasted but I am getting the development platform stable. http://lsces.org.uk/phpinfo.php is my production copy, but has a broken imagick and an out of date smarty library. http://php7.lsces.org.uk/phpinfo.php has everything it needs and is currently only giving nginx errors in the log http://php56.lsces.org.uk/phpinfo.php has the latest 5.6 from git but mbstring will not compile http://php6.lsces.org.uk/phpinfo.php is the distributed PHP5.6.5 dump and everything seems to be working same as php7 build, except imagick crashes phpinfo() as does the php56 build. Just need to restore the production copy to fully functional before I get back to debugging the new stuff. ( Have some facilities set up in Eclipse but would still appreciate some input on that for compiling source rather than managing php projects ) -- 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
[PHP-DEV] Design by Contract and scalar types ...
May as well do something practical while I am testing ... http://php7.lsces.org.uk/wiki/view/The+good+old+days+...+annotation+without+overheads First thing to pick up ... PHP7 is a good 20% faster than the current PHP5.6.5 but I'm seeing no speed difference between 5.6.5 and 5.4.20, so as long as can leapfrog the remaining PHP5.x builds then all of the time upgrading TO 5.4 is not a waste. But the main reason for posting this was the recent comments that strict types has nothing to do with annotation. It was EVERYTHING to do with annotation and project design. Every value I pass to the verify function has to be validated for much more than just integer or string, so how do I pass the correct information for this single function. content_id would have been a 32bit integer in the 90's, but the upgrade of SQL sequences to 64bit has changed that. user id's are still 32bit integers, and create and edit are timestamps which are another contentious area when trying to work cross database. Mine are 32bit day + 32bit time, so a pair of current integers, but stored as a 64bit value in the database. title is a 250 character string, and while ip is v4 at present v6 needs to be catered for in PHP7. I see nowhere here that a few limited strict tags provides any help, but every value passed currently will need additional code if the integer checking becomes an unconstrained object. Much has been made of adding a class string to handle all the extra unicode processing, but I am now thinking that a properly exposed string and integer class which has the ability to assign constraint checks does make sense. Then use of an integer value on a 32bit platform can error when the actual value is too big for the target use. THAT is what strict type checking is about! -- 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] Annotated PHP 5->7 extension diff
On 09/02/15 15:03, Jan Ehrhardt wrote: > Despite the extensive list of changes, imagick does not compile anymore > with the current PHP7 git head (Win32 VC11). Jan ... try the latest code from Dan ... Just got both php7 and php5.6.5 running including a populated phpinfo on each so I'm moving on ... -- 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] Design by Contract
On 09/02/15 23:47, Yasuo Ohgaki wrote: > The RFC draft is ready. > https://wiki.php.net/rfc/dbc2 > These contracts are evaluated development time only. Therefore, there is no > performance penalty with DbC. Sorry but that makes no sense to me at all. If this is something only to use with an IDE then why does it have to have anything that is visible at 'run time'? This seems to be going down the track of "we will be compiling this eventually" and that is just not what PHP *IS* about. These are more hints, but assume that at runtime what they define is not relevant? ALL of this discussion on type hinting how ever it is handled is simply sidestepping the major plus on PHP with associative arrays. I see no point expanding every database record read to 'magic access functions' for multiple variables and it *IS* the scalar values stored in these arrays that needs the 'hint/constraint' control. I am getting even more confused about just what all the different factions are trying to achieve. Yes I know I can totally ignore all of it, but with my current tools losing traction because of all the 'better ways of working' what in my opinion IS the best way to allow different factions to add their own pet style is drowning simple clean solutions such as docblock. -- 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
[PHP-DEV] zend_get_parameters_ex rework
in interbase/ibase_blobs.c > zval *blob_arg, *string_arg; > ibase_blob *ib_blob; > > RESET_ERRMSG; > > if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, &blob_arg, > &string_arg) == FAILURE) { > WRONG_PARAM_COUNT; > } > > ZEND_FETCH_RESOURCE(ib_blob, ibase_blob *, blob_arg, -1, "Interbase > blob", le_blob); I've got that if changes to > if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rr", > &blob_arg, &string_arg)) { > return; > } But I suspect I need to change the *string_arg to a character string so 'rc' and add a string_len field. At least that is what I think I'm seeing from the samples I have found. -- 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] Design by Contract
On 11/02/15 07:58, Stanislav Malyshev wrote: > We've spent several years rejecting annotations because no information > can be in comments, not even a little bit, not even a tiny. I find that a strange comment, since I've been using annotation in PHP from day one. The phpdoc material helped me get started all those years ago since every third party library had it as part of their coding style from PHP4 days. All of the current demands ... and I think they are demands! ... stamp on past history and load even more work on everybody to have to support all these new features. Even if dbc is wrapped in comment blocks to hide it it's potential presence in third party parts of a project means that all tools have to be modified and my use of phpdoc is further eroded. I see all these comments about 'D' and 'Effiel' and my ONLY thought is ... Then bloody use that! ... Even the people demanding strict typing! DbC does not have to modify the core code to be usable by those wanting it. In the same way that phpdoc has never needed that. BUT a means of expanding the /* */ wrapper to include extra types over the /** tag may be appropriate, then people can use their own preferred annotation system, and other tools can simply 'switch off' where appropriate. While I don't feel 'compiling' is the right way forward for PHP projects, the 'min' processing of files as applied to just about every other scripting element does make sense as a half way house to opcode caching. ( and some help with actually fixing php7 in code would be appreciated! ) -- 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][DISCUSSION] Script only includes
On 11/02/15 09:34, Derick Rethans wrote: >> Some of you are tired with this topic, but please take a look the RFC >> > >> > [RFC] Script only includes - this is 3rd version. >> > https://wiki.php.net/rfc/script_only_include >> > >> > Please let me know what you like or dislike. > Con: > - It introduces an INI option that changes PHP's behaviour. > - How do you know what is a PHP script? Surely not be checking that the > first 4 chars are "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] zend_get_parameters_ex rework
On 10/02/15 14:31, Lester Caine wrote: > in interbase/ibase_blobs.c > >> zval *blob_arg, *string_arg; >> ibase_blob *ib_blob; >> >> RESET_ERRMSG; >> >> if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, &blob_arg, >> &string_arg) == FAILURE) { >> WRONG_PARAM_COUNT; >> } >> >> ZEND_FETCH_RESOURCE(ib_blob, ibase_blob *, blob_arg, -1, "Interbase >> blob", le_blob); > > I've got that if changes to > >> if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rr", >> &blob_arg, &string_arg)) { >> return; >> } > > But I suspect I need to change the *string_arg to a character string so > 'rc' and add a string_len field. At least that is what I think I'm > seeing from the samples I have found. OK I've got a patch for master, but I know that the changes are not complete! http://hg.lsces.org.uk/hg/php-src/rev/8ec9101f59b6 I've still got a question about the &string_arg on line 1.9 and if it should be changed to a string but that change needs working through the following code. Also is what I'm doing here php7 only? so should there be wrappers for a PHP5 build? I think that all this leaves is all the complaints about 'NULL' and integer initialization makes integer from pointer without a cast and assignment makes integer from pointer without a cast -- 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] Design by Contract
On 11/02/15 14:14, François Laupretre wrote: >> All of the current demands ... and I think they are demands! ... stamp >> > on past history and load even more work on everybody to have to support >> > all these new features. Even if dbc is wrapped in comment blocks to hide >> > it it's potential presence in third party parts of a project means that >> > all tools have to be modified and my use of phpdoc is further eroded. > The proposal to embed DbC conditions in phpdoc is just defining new '@' > keywords. That's the implicit way such a basic annotation system works : > tools ignore the lines they don't understand. I ran phpDocumentor on > DbC-commented script files, and it still produces the same documentation. > It's supposed to be the same with everyone extending phpdoc syntax. > > So, I don't understand why you should modify any of your tools. While phpDocumentor can ignore elements it does not understand, that information would be useful to maintain, so some modification of it's parsing would be appropriate. But I was referring more to the other proposals for adding essentially the same information, and how that might be hidden in non-docblock comment packets. But currently some tools are lagging behind even current changes in PHP and phpDocumentor does not get everything right already. I can't get a clean set of documents currently with either the original version or the Mk2 version of phpDocumentor on code that has produced clean documents in the past. Just another area that needs time spending to work out what now need updating which does not affect the working code. -- 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 11/02/15 21:46, Andrea Faulds wrote: > Anthony Ferrara also had his own analysis which showed some of the problems > with weak type hinting, and where strict types can be beneficial: > http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html What is the point of using a 'Better static analyzer' when the bulk of the material being worked with simply can't be processed 'statically'? The only result of this passing that I can see is that PHP will start to develop two completely different code bases. Anthony closes by saying that is EXACTLY what he will do ... -- 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] zend_get_parameters_ex rework
On 12/02/15 10:10, Yasuo Ohgaki wrote: > > 1.9 +if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, > "rr", &blob_arg, &string_arg)) { > > I don't read the code and just curious. > The "string_arg" isn't string? Why you specify "r" (resource)? Is it > badly named parameter or some kind of string resource? This is the bit I have asked about a couple of times already ;) That value is passed to a second function _php_ibase_blob_add which expects a zval, but I don't think that this is necessary now? It is a block of data rather than a text string as such and may include unicode or other binary data. What it does has not changed since 1990's only how PHP handles it. > It may be easier for you and us, if you could use github. My local repo is just a mirror of git.php.net and I can work from that locally direct off eclipse which includes stuff I will never backup to github. 'You don't have to use git' was one of the promises when that was force on us ... I have an account, but forking php-src just to work on a couple of extensions is pointless. Back to code ... https://github.com/php/php-src/blob/master/ext/interbase/ibase_blobs.c Line 318 passes string_arg to function at 131 ( this is so much easier using eclipse to navigate :) ) The other compile problem I have is the complaints about casting pointers to integer ... -- 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] zend_get_parameters_ex rework
On 12/02/15 11:35, Nikita Popov wrote: > I've still got a question about the &string_arg on line 1.9 and if it > should be changed to a string but that change needs working through the > following code. > > > Yes, this should be changed to a string. E.g. use the 'S' zpp modifier > and declare the variable as 'zend_string *str'. Then modify the places > where it is used from Z_STRVAL_P(...) to str->val and Z_STRLEN_P(...) to > str->len. OK that makes sense ... and I though I was on a roll, except while I can convert one of the uses, another is feed by a zval which I then need to convert to a zend_string, but I think I can just change b_val to Z_STR*(b_val) but the compiler is saying that Z_STR is not defined? I've spent half an hour trying to dig around but not managed to find what I should be using :( -- 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] Legal date generated from illegal date
On 13/02/15 04:03, Yasuo Ohgaki wrote: > I see controversial behavior here, unserialize raises error while new > DateTime('-00-00') doesn't. > > If it's a bug, I'll just file it as a bug. Yasuo Management of dates is controversial in a lot more areas than just using the wrong calendar in prior times ;) Each database uses it's own way to handle dates and time internally, and most default actions are different, add to which using second as the base for dates is just wrong anyway, but we have to live with what is currently available. The area that needs fixing first is the underlying OS functions rather than continually trying to patch the top level, but we perhaps need to document better just where the joins are ... just how many days were there from 0BC to today ... -- 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] zend_get_parameters_ex rework
On 13/02/15 16:40, Jan Ehrhardt wrote: > It still gives some warnings at compile time. Most of them are caused by > > ib_link = (ibase_db_link *)zend_fetch_resource2_ex(IBG(default_link),\ > LE_LINK, le_link, le_plink); > > warning C4024: 'zend_fetch_resource2_ex' : different types for formal > and actual parameter 1. I could not find a way to fix this. > > A comparable warning in interbase.c - PHP_FUNCTION(ibase_gen_id) might > be easier to solve, I see now. I'm sure it is just a mater of 'casting' the pointers used on the interface to match the new PHP rules. I'll be having a go myself later ... got to earn some money first :) -- 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][VOTE] Group Use Declarations
On 13/02/15 16:41, Andrea Faulds wrote: > But with Marcio’s proposal, we could instead write this: > > use function SomeLibrary\Math\{sin, cos, tan, degrees, radius}; Well it used to be simply ... require SomeLibrary\math.php; -- 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][VOTE] Group Use Declarations
On 13/02/15 17:27, Andrea Faulds wrote: >>> But with Marcio’s proposal, we could instead write this: >>> >> >>> >>use function SomeLibrary\Math\{sin, cos, tan, degrees, radius}; >> > >> > Well it used to be simply ... >> > >> > require SomeLibrary\math.php; > I can’t say I miss the days of putting everything in the global namespace. > Makes it impossible to use two libraries with conflicting function names. Well one fix would be to have all the namespace stuff in the math.php file? All the use function stuff just loaded via the secondary file. But the other way of looking at is 'why do we have so many different libraries all doing the same thing?' Currently database abstraction is a complete mess simply because there is not now a standard way of doing things :( If you have to use two libraries with conflicting names is that not because there are problems with both libraries if you need to use both? -- 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][VOTE] Group Use Declarations
On 13/02/15 17:46, Sebastian B.-Hagensen wrote: >>> I can’t say I miss the days of putting everything in the global namespace. >>> Makes it impossible to use two libraries with conflicting function names. >> > >> > Well one fix would be to have all the namespace stuff in the math.php >> > file? All the use function stuff just loaded via the secondary file. > You would still need to import those functions into the current > namespace. Hence this rfc My point is "WHY" ... can't we simply import an include file which does all the rest. As Pierre says, some of these are becoming totally unwieldy, yet I can still include ADOdb and Smarty with two lines of code in my start up ... Just another example of where things have become hard work which now needs additional fixes. Yes this RFC is probably needed, but isn't the whole process wrong? Can't we restore the simple way of working in PHP7 where it does not need to wrap around other things quite so closely? -- 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][VOTE] Group Use Declarations
On 13/02/15 21:16, Nikita Nefedov wrote: >> Can't we restore the simple way of working in PHP7 >> where it does not need to wrap around other things quite so closely? > > Hi Lester, > > This way if doing things on php didn't go anywhere, people just stopped > using it because they saw better alternatives. I could accept that statement if there was any actual evidence! The problem today is not 'better alternatives' but rather the new bread of developers who's interest is in the tools themselves rather than actually using the results in practice. The split at the moment is one of usability over language aesthetics. The very fact that 'you don't have to use namespace or strict typing' means that for the majority of users there is no need to change ... except the library developers are continually moving the goal posts so that we HAVE to use some features, or at least be up to speed on the third party use of those features where we ARE reliant on third party libraries for many things. The small stepping stones down a path that is NOT pulling everybody else into the same vision is what is now threatening to blow PHP out of the water. I do really feel that some things are going too far and need their own 'space' along side PHP rather than being forced onto the rest of use who simply want a stable language to work with. PHPNG is the sort of improvement that was needed - speed. Even namespaces are not essential to that target as simply adding a tag to any library function is more than adequate, and even the fact that procedural functions seem to be getting a little more respect shows that totally OO PHP is not yet a user demand. -- 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 14/02/15 01:16, Andrea Faulds wrote: >> - About the 'numeric' type you would introduce in a future RFC, would you >> (in strict mode) allow everything accepted by is_numeric() or is it just a >> shortcut for 'int|float’ ? > The idea is just int or float (except in weak mode of course, where it needs > to accept strings etc.). But that makes the naming possibly misleading. I’d > prefer “number”, but that’d be a BC issue I expect. But that’s for a > different RFC. Just how often have we had 'But that’s for a different RFC' in the past where things have not been fully thought out for a major feature. There are a number of areas that either required reworking or changes later because the whole problem had not been thought out. The whole idea of 'hinting/checking' is so important and I would take things a lot more seriously if there was a way of hinting at what a function required rather than some nebulous wrapper which may even change itself. strict typing is used by compiled languages to ensure that the right SIZE of parameter is passed. Simply saying 'int' and then even allowing some unconstrained object to be passed is not my idea of data management! The fact that this issue as had the biggest vote I have ever seen shows how passionate people are about it and not having a vote on the matter does irritate me, but I do have a get out clause, I don't have to use PHP7 which is a shame because what I have working so far IS good. This is going to be like PDO, half baked and missing the point. Just like PDO we need a decent library that manages type constraint properly and that will be even more important if the vote on bigint goes through and destroys what remaining size management we do have! The vast majority of parameters DO have a limit on their size. -- 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] Proposing [constructive] solutions (was: I quit)
On 16/02/15 15:31, François Laupretre wrote: >> - There is a lack of expertise at the core level of the code, so >> > collaboration on each feature is low. RFCs tend to have a single >> > sponsor, who has to see the whole process through to the end. > - One thing we can encourage, while indirect in this case, is writing more > comments in code. With PHP 7, Sara's book is almost unusable and nobody will > write another one soon. 'UPGRADING' and friends are fine but far from > sufficient, especially for newcomers. The only solution I imagine is adding > comments in the code. I know it is annoying when you don't have much time, > but comments can be improved at any time. They can be written by the feature > author, but also by other people, who needed a (too) long time to understand > a feature, and write explanations to help followers. As an example, I spent > some time understanding the multi-level architecture of str_[i]replace > functions and added a lot of comments along with the patch I will propose. > Actually, everywhere you spend time understanding what's going on, more > comments are needed. That's really important because, today, the code > contains almost no comments except function prototypes. That’s ant work and I > am far from perfect about comments in my own code, but it can make a difference, especially making the project more attractive for newcomers (and we *need* new blood). Having been expanding docblock annotation in production code for many years many of the current discussions cause me a number of problems with the move to change just how we document in production. I've been back inside the code again simply trying to keep my own KEY elements available and it really does take a long time to understand some of the way the code is currently structured. The phpng changes seem to be tied up with a number changes to style of things rather than implementing the change, but it *IS* only the person who developed the change that can totally understand how to change every other extension in the same style :( Currently I lost track of the bits I should be using as current notes and searching just pulls up phpng or even older guides, so it would be nice to have a single index for PHP7 with all of the good samples linked. Oh and currently I can't even get master to compile ... which it was doing here Friday ... -- 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
[PHP-DEV] Done something wrong ...
I've synced with current git and seem to have the files I expect for interbase, but when trying to run a clean build of the core stuff it no longer compiles ... For example /srv/repo/php-src_master/ext/opcache/ZendAccelerator.c:2005:19: error: ‘zend_array’ has no member named ‘pDestructor’ Seems to be due to changes for HashTable? But what have I missed? -- 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] Done something wrong ...
On 16/02/15 18:34, Ferenc Kovacs wrote: > On Mon, Feb 16, 2015 at 6:55 PM, Lester Caine wrote: > >> I've synced with current git and seem to have the files I expect for >> interbase, but when trying to run a clean build of the core stuff it no >> longer compiles ... >> >> For example >> /srv/repo/php-src_master/ext/opcache/ZendAccelerator.c:2005:19: error: >> ‘zend_array’ has no member named ‘pDestructor’ >> Seems to be due to changes for HashTable? But what have I missed? > try a fresh build after ./vcsclean OK I'm working off multiple local copies of the code base so vcsclean is not usable. I suspect it would wipe the eclipse project files anyway. SO it's a matter of working out what does not get wiped by make distclean ? Although it's probably just as easy to drop the eclipse files onto a new dump of the code - which is what I've currently done, but I still can't compile interbase now :( -- 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] Done something wrong ...
On 16/02/15 20:24, Martin Jansen wrote: >> OK I'm working off multiple local copies of the code base so vcsclean is >> > not usable. I suspect it would wipe the eclipse project files anyway. > IIRC vcsclean essentially runs `git clean -f -X`. That last parameter is > important because it instructs git to only remove files that are ignored > via .gitignore. Your manually created files will stay. Thanks for that Martin ... turns out hg purge can do the same thing via hggit plugin ;) Just needed the kick in the right direction. -- 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
[PHP-DEV] Compile problems - Was Switch jumptable optimization
On 16/02/15 23:55, Rasmus Lerdorf wrote: >> this doesn't really look related to my patch. Did you do something wrong >> > when cloning my branch? Or forget a make clean or similar? >> > >> > Locally it works for me and echoes 1 as expected. > Ah, looks like you are right. A full distclean cleared it up. I had just > done a distclean, but I had built once before applying your patch. > Crappy Makefile deps.. It seems not even running distclean clears down everything that needs removing for some of the changes currently going through. ./vcsclean does not work for me since I'm running Hg locally, but an hg purge /all did clean everything up, so obviously there is something in the .gitignore file that should also be in the distclean list? Or should distclean actually be using .gitignore as it's 'clean' list? Anyway I now have a working build of PHP7 again having wasted a couple more days trying to track down what was wrong. -- 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] Reviving scalar type hints
On 17/02/15 06:20, Sara Golemon wrote: > * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as > standard (like numeric), others user-definable) And also ... int4, int8 and similar for correctly constrained values. In an ideal world the whole SQL standard types would be available, but this at least would allow int to become an unconstrained object if people want that. It's the whole "we can fix it later" that I don't like ... especially when other votes are changing the goal posts in parallel. -- 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] Reviving scalar type hints
On 17/02/15 14:49, Andrey Andreev wrote: >> I agree. It's more of a question of eliminating potentially dangerous >> > conversions than just being lossless. >> > > Agreed as well. However, while bool -> int conversion one of the > reasons why many people want strict type-hints, it also often makes > sense and is quite widespread. There's no silver bullet for that > problem. Returning 'not-zero/empty' as true and 'zero' as false is one of the natural things to use in PHP and I don't think any other language has that flexibility? It is also why some of the other 'little changes' such as hard coded IS_TRUE and IS_FALSE are actually somewhat alien! Certainly is does not play well with my methods of working, but then I prefer a function to return a result rather than crash out with an exception ... Although -ve values are even more useful than a simple 'zero' return and that may replace a string return. -- 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] Reviving scalar type hints
On 17/02/15 15:30, François Laupretre wrote: >> Returning 'not-zero/empty' as true and 'zero' as false is one of the >> > natural things to use in PHP and I don't think any other language has >> > that flexibility? > You didn't read it right. > > I was talking of conversions *from* bool, not *to* bool. (int -> bool) is > fine and will be preserved, but I propose to remove (bool -> int). You will > still return numbers as bool, and non-zero will still be converted to true. > Relax :) My current practice up until now has been to use 'return false' when an action failed, but the main return would be a number of records or string of data. So you are now blocking that activity ... I'm reading to right, but you are not thinking all possibilities through. But I think I'm starting to see it broken already with the other changes to the core :( I'm not returning 'IS_FALSE' so I'm probably going to have to change the 'false' to '0' anyway so as to avoid the bool? -- 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] Reviving scalar type hints
On 17/02/15 15:47, Anthony Ferrara wrote: > A static analyzer (one of the reasons people want strict) would error > there. The reason is that *at compile time* it can't reason about the > code well enough to determine if there's an error or not. You're > passing a string where you expect an int. Is that going to work? We > don't know. So the analyzer would need to throw a warning that the > cast is potentially unsafe because it can't guarantee that the runtime > won't throw an error. Which means that to remove the warning you'd > need to add an explicit cast. This is what I do not get ... I have no idea what string will be provided, so either we get a valid number or we don't. Conversion of the string to a number needs to follow several rules such as thousand divider or decimal point, or perhaps even spelt out numbers. If the input string can't be converted to a number then we need the error message - explicit casting fixed nothing - you can't eliminate the error if the passed string can't be converted so you need an alternate escape route. A generic 'type fault' does not help since you want to return the fault to the inputting source? Static analysis only works if you assume there is no human involvement in the generation of the inputs? Now if you are handling the problem of mistakes in the input prior to the function call you already know that the data is good so why do you need 'strict' at all. You will process the string, decide if you want to tell the client that it must be a whole number, or if it exceeds some limit. That may even be done in javascript in the browser, so what is fed back has already been sanitised. It will come in as a string and you know it is a valid number ... -- 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] Reviving scalar type hints
On 17/02/15 18:33, François Laupretre wrote: > What does this mean in your case ? Just that, as long as the feature is not > available, your function won't have an explicit return type. Period. And, > please, don't change false to 0 ;). I simply can't see the case for limited function type hints at all! I either already have clean defined data from the database, or I need to validate the data from users before using it. While validating I need to confirm constraints of data type so adding some extra wrapper that only does half the job just seems a pointless exercise. Annotating the correct data type would be of more use and I already have that in the docblock and my IDE produces those hints while I am writing the code - which it has done for many years. To my mind it IS in the IDE that much of this stuff which people keep saying is not 'runtime' should be managed, and anything that is not needed at 'runtime' should be removable but what is being added across several areas all seem to beadding the same things - partially - using different methods - without any obvious gain. Additionally I'm now passing data as an array as that was the 'best practice' a few years back so it is rare to be passing a single value anyway. -- 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] Reviving scalar type hints
On 17/02/15 21:28, François Laupretre wrote: >> De : Lester Caine [mailto:les...@lsces.co.uk] >> >> On 17/02/15 18:33, François Laupretre wrote: >>> What does this mean in your case ? Just that, as long as the feature is not >> available, your function won't have an explicit return type. Period. And, >> please, don't change false to 0 ;). >> >> I simply can't see the case for limited function type hints at all! I > > If you can't see it after so much was written on the subject, what can we do > ? Do you imply that, if *you* cannot understand the need, it does not exist ? Since it has already been said that what is proposed is 'just a start' then the missing bits may get added later - and if it is anything like PDO will it arrive before PHP10 :) >> either already have clean defined data from the database, or I need to >> validate the data from users before using it. > > If that's your only data source, that's OK. I confirm you probably don't need > type hinting. You probably even don't need functions, classes and the rest. A > 50-line script should fit. http://hg.lsces.org.uk/bw/bitweaver/ is a little more than 50 lines ... lsces.org.uk/bitweaverdocsPHP/index.html hasn't been updated since we lost the original phpDocumentor but now I do need to try and get a new version run including all the e_strict stuff that hs been reworked in the last 5 years. >> While validating I need to >> confirm constraints of data type so adding some extra wrapper that only >> does half the job just seems a pointless exercise. > > The point of type hinting is not validating user input. Again limited application of a useful function. Strict scalar type hints are only there to give an error when something is wrong. How is that not doing validation? If you HAVE validated the data then where do you need the hint other than reminding you just what you need to validate to? And if you have validated then one can pass a value rather than a string anyway? >> Annotating the >> correct data type would be of more use and I already have that in the >> docblock and my IDE produces those hints while I am writing the code - >> which it has done for many years. > > That's different. There is overlapping there but the purpose is not the same. > IDEs only can do a limited set of static analysis. As soon as you have > indirect calls, IDE-based static analysis is down, let alone comment-stripped > libraries and others. If you want more constraints on input and output, look > at DbC (design by contract), as it can handle tests too slow to run in > production. I would not even bother trying to understand the PHP code base without a decent IDE, and Eclipse provides that. PHP files live next to C/C++ and other file formats, so the one set of tools allow everything to work productively. I don't find any problem seeing indirect call annotation and although PHPeclipse is now struggling with new things ( like dropping the ?> in the MIDDLE of phpt files :( ) it has done the jobs that most of this extra infrastructure is trying to duplicate for a lot of the life of PHP5. > To my mind it IS in the IDE that much >> of this stuff which people keep saying is not 'runtime' should be >> managed, and anything that is not needed at 'runtime' should be >> removable but what is being added across several areas all seem to >> beadding the same things - partially - using different methods - without >> any obvious gain. Additionally I'm now passing data as an array as that >> was the 'best practice' a few years back so it is rare to be passing a >> single value anyway. > > IDEs are worthwile but not mandatory and runtime features have nothing to do > with IDEs. > Now, you were (aggressively) complaining about returning int or false. You > were sure you had found the case that would prove all of this was ready for > the bin. I took the time to explain. Then, you're complaining it's no use > because you don't understand its purpose and because you chose to bundle your > arguments in arrays... Flagging that a value HAS to be an integer is fine, and hopefully the move to make that an unconstrained object rather than a simple register value has passed, but even here the next step is rather than hiding the fact that in many cases there IS a limit, the move to 64bit values in parallel with 32bit ones needs much better management and it's the total disregard for that which is my problem. 'PHP has not worried about that in the past' neatly sidesteps the fact that we USED 32bit builds of PHP5 to avoid the problems, but nowadays we have legacy systems that are still locked to 32bit values while new sys
Re: [PHP-DEV] zend_get_parameters_ex rework
On 17/02/15 23:40, Jan Ehrhardt wrote: >> Thanks patch looks clean and It compiles, i will start testing it > Apparently your tests were successful (?): > http://git.php.net/?p=php-src.git;a=commitdiff;h=8f968c5416e721983c0efda25ec1f393c8df662a Adrian may have, but I've just wasted 2 hours trying to get the tests to run and all I can get is 'Termsig=11' failures after it creates the test database. But it is running happily on the test site http://php7.lsces.org.uk/wiki/ The thing I would rather be working on is why the PHP5 versions are running more queries on the database then the PHP7 build. The code and database are identical ... only the PHP side is different. But I need a few hours sleep ... -- 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] Scalar Type Hints v0.4
On 18/02/15 09:14, Andrey Andreev wrote: > That is especially bad when such identifiers are in fact generated as > integers first so that they are incremental, but the > program/database/business logic requires them to be fixed-length > strings and/or in hexadecimal format. In such cases, even silently > discarding leading zeros can prove to be problematic, while in the > case of hexadecimal representations you'd need more than 10 data > samples to notice the problem if you don't use a strict hint. > Obviously, that would be solved with automated testing, but > unfortunately even code with high test coverage % often lacks depth in > its test cases. Octal is something that can often be miss converted since it IS the same as an integer with only a '0' in front in PHP. But that is not something that can be fixed with the current proposals? Again we have to ensure that the pre-processing takes care of the problem and how would static analysis even know there was a problem? A type hint following the SQL standards would be more helpful than the javascript approach of giving an error in strict mode. -- 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] Compile problems - Was Switch jumptable optimization
On 18/02/15 08:02, Sebastian Bergmann wrote: >> It seems not even running distclean clears down everything that needs >> > removing for some of the changes currently going through. ./vcsclean > I stopped using distclean / vcsclean a while ago. "git clean -xdf" > does the trick for me. hg purge /all needed a little help to hide the bits that I need for thg and eclipse, but I seem to have that under control now. So it's just a right click function in thg. All that remains is adding back in extensions like imagick which I'd like in the ext folder but which git/hg want from a different repo. Ideally ext would just be a list of sub-repo's one can switch on and off rather than having to list each in the ./configure string. I'm using a local process via hg to merge the different git elements so that the IDE sees all the cross references in the one code tree. On that side, I don't enable the mysql stuff normally and while mysqlnd is compiling happily as a shared extension it looks like I can't load it as it is not actually a valid extension? Is that a bug or is the fact it's allowed to select 'shared' in ./configure the bug? -- 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] Scalar Type Hints v0.4
On 18/02/15 12:33, François Laupretre wrote: >> Octal is something that can often be miss converted since it IS the same >> > as an integer with only a '0' in front in PHP. But that is not something >> > that can be fixed with the current proposals? > What do you propose ? Considering leading zero as octal indicator is not an > option, IMO. If you have another way, why not. 0o 0 and \ are the usual flags for an octal value and we have functions for octal strings but they are not user friendly in their output as they tend to ignore adding a leading tag at all. But my favourite is still '\143\141\164' == "\143\141\164" which is false, but I doubt many would know why? Yes it only becomes a problem when one is accessing material like historic data dumps, and rejecting the numeric string may be 'strictly' correct, but it's one those 'what the' if one gets an error where for years it's run perfectly? >> > Again we have to ensure >> > that the pre-processing takes care of the problem and how would static >> > analysis even know there was a problem? A type hint following the SQL >> > standards. > Please give conversion rules and supported syntax for the 'SQL' type you have > in mind. 'octal' just expects a base 8 string. I know there are some examples in the SQL standards, but since they are paid for documents it's pointless trying to reference them :( ( Andrey - there may not be plans to support a full range of hints - weak or strict, but this is all valid material that PHP handles daily and passes around ) -- 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] Scalar Type Hints v0.4
On 18/02/15 14:59, Pádraic Brady wrote: > I wouldn't necessarily mind int->float - it's lossless assuming one way only. Assuming int is not 64 bit ;) -- 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] Scalar Type Hints v0.4
On 18/02/15 17:55, Zeev Suraski wrote: > We can limit ourselves to values below that limit. If you deal with values > above it, be explicit about casting. This is exactly my problem ... Databases are using 64bit primary keys more and more, and having to worry about going over some limit is the very thing that any 'hinting' should be taking care of! This is the very area where using 32bit builds at least provides a level of protection currently. -- 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] Re: [RFC-Discuss] Scalar Type Declarations v0.5
On 18/02/15 23:09, Christoph Becker wrote: > It seems to me that this behavior is hard to deal with generally for > programmers as well as static analyzers. Andreas' bigint RFC[1] would > solve that issue, but it has been withdrawn, and AFAIK nobody is working > on it. OTOH, bigint would make the widening from int to float > potentially even more lossy (i.e. inaccurate) than it is now (64bit ints > vs. IEEE 754 doubles). The 'unconstrained integer' RFC adds it' own problems, but the int -> float overflow is only a problem with 32bit builds anyway. 64bit builds will not overflow until they run out of space anyway. -- 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] Re: [RFC-Discuss] Scalar Type Declarations v0.5
On 19/02/15 01:33, Christoph Becker wrote: > Lester Caine wrote: > >> On 18/02/15 23:09, Christoph Becker wrote: >>> It seems to me that this behavior is hard to deal with generally for >>> programmers as well as static analyzers. Andreas' bigint RFC[1] would >>> solve that issue, but it has been withdrawn, and AFAIK nobody is working >>> on it. OTOH, bigint would make the widening from int to float >>> potentially even more lossy (i.e. inaccurate) than it is now (64bit ints >>> vs. IEEE 754 doubles). >> >> The 'unconstrained integer' RFC adds it' own problems, but the int -> >> float overflow is only a problem with 32bit builds anyway. 64bit builds >> will not overflow until they run out of space anyway. > > It seems to me you're thinking too much (maybe only?) about "database > types". IMHO PHP can be used more versatile, and there might be issues > which are exemplified in the RFC[1]: > > var_dump(2 ** 64); // float(1.844674407371E+19) > > Clearly an int->float overflow that'll also happen on 64bit builds. > > [1] > <https://wiki.php.net/rfc/scalar_type_hints_v5#integer_overflow_to_float_behavior> You see this has nothing to do with 'Scalar Type Declarations' ... this is a problem in it's own right that needs sorting as part of the general 64bit 'upgrading' and providing a proper fix for 64bit numbers is something which the 'unconstrained integer' RFC addressed but in my book it was always the wrong fix, and providing a cross platform fix for BIGINT which provides a simple integer value is the correct fix. The voting on that RFC seemed to agree. We need 64bit values in several places where simply clipping to 32bit ones is no longer the correct fix. -- 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-Discuss] Scalar Type Declarations v0.5
On 19/02/15 04:44, Dennis Birkholz wrote: > I just saw the reddit where you mention that v0.4 is practically > abandoned now, so I will just renounce my previous mail! DO NOT USE OTHER CHANNELS! With the large number of secondary channels the only place that suggestions like that should be made is here and as far as I have seen both ideas are still 'active'? But I do find it crass that there is now a different document with no reference to the v4 history! What does need unravelling is just which bits go with which discussion across all of the areas. I'm still looking at how any of this applies to the values in the arrays I'm passing around and just getting more and more confused. What I think I want is a set of functions to replace all this casting mess. Rather than is_bool ... as_bool similarly as_int64 rather than getting an automatic float. I want to ask to look at a variable in the array as the type I need for the job in hand now you may say that is 'casting' but you are not providing me with the casts *I* and many other database users need. I can see the 'advantage' of optimizing code via this strict stuff that some people want, but I don't see that has any place in a 'run only' version of PHP. If you want to compile the code then use a port of PHP that is compiled. Leave those of use who prefer the more dynamic system which may well have to deal differently with a scalar variable depending on what is returned at runtime. On the minus side of this drive to 'optimize' the code is the potential for completely different code on 32bit systems over 64bit ones. If the number is below 32bit then a completely different set of code gets used using only 32bit instructions. This may well be good for speed, but can introduce cross platform differences that may be difficult to debug. We currently live with those problems already with the int->float agro on 64bit numbers. -- 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] Reviving scalar type hints
On 19/02/15 09:13, Zeev Suraski wrote: > Obviously, I think 'weak' campers have a lot to gain too - by making > sensible conversions work fine as expected, without having to resort to > explicit casts. > And everyone stands to gain from having just one mode, instead of two. > The coercive typing approach would require each camp to give up a bit of > their 'ideology', but it also gives both schools of thought *most* of what > they want, including the key tenets for each camp (rejecting non-sensible > conversions - always, allowing sensible ones - always). I believe that's > what makes it a good compromise, a better one than the currently proposed > RFC. Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? -- 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] Using Other Channels (was Scalar Type Declarations v0.5)
On 19/02/15 15:21, Zeev Suraski wrote: > Focusing on my email to Sara (and several others), there is NOTHING, nothing > wrong with a bit of private communications trying to gauge support, > opposition, gaps and sort out differences before going for a public > discussion. My original comment was on the basis that we have had too much 'we agreed on list X' and I think a lot of the underlying discussion while voluminous here has lost some of the critical fine detail ... because it has not been copied here. Currently 0.4 and 0.5 versions are still being discussed, but neither relax the weak/strict debate which is apparently so essential in other forums? -- 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] Reviving scalar type hints
On 19/02/15 12:52, Zeev Suraski wrote: >> Now that all made sense! >> > >> > My only grey area is 'allowing sensible ones' where the size is an >> > integral part >> > of what is 'sensible' ... the one where conventional strict typing uses a >> > type >> > of the right size? > I think the guiding principal for these conversions should be no data loss. > This may mean we have different limits on different architectures, depending > on whether they're 32-bit or 64-bit. This still leaves the 'black hole' caused by the fact that databases are actively using 'BIGINT' even on 32 bit platforms. It may be that the only practical approach is gmp, but using that and writing code that selects that on a 32bit platform, then switching to clean 64bit maths on a 64bit platform does not sound like simplifying things? As with other debates, some say ignore 32 bit, and others say lets loose the constraints altogether, but having a fundamental type behave differently depending on platform is a problem? -- 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] Reviving scalar type hints
On 19/02/15 12:47, François Laupretre wrote: > I didn't add restrictions specific to number representation in the draft > ruleset yet, becausen while I think that's an important point, I didn't have > time to study it in depth. > > I know you're an expert on this as you continuously (rightly) raised the > point. > > So, can you elaborate on this and send me or, better, publish on the list the > detailed set of changes you suggest, including 32 bit vs 64 bit concerns if > they fit. Today, conversion restrictions are rather limited as floats which > don't fit in int give 0, and int to float is considered as always possible. I > mean that must be technically incorrect, while unnoticed in the vast majority > of cases. > > So can you write a consistent set of changes you would introduce ? François ... My main interest in this over the years has been while trying to port data between different engines, and that includes porting legacy data from older systems such as dbase some of which originates from 8 bit processor days. One area that overlays the general discussion is the simple size of a scalar value, and this just mirrors the number of bytes used to store it. I1, I2, I4 and I8, but a more general validation facility on top of 'integer' would be a simple range. decimal or numeric and float may get lumped together, but integer is a much better base for decimal/numeric since it is lossless and simply moves the position of the decimal point. Storage only requires an integer of the appropriate size for the number of digits. float is another miss used definition since it normally only allows for 32 bits of data, while double expands that to 64 bits. So once again the platform may affect how these values are processed. Pierre - You may think that the size of integer is irrelevant in the discussion on providing a strict type use of it, but in practice it is somewhat important if the codebase you are creating is only 32bit but all the data being handled is 64bit. -- 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] Using Other Channels (was Scalar Type Declarations v0.5)
While typing this I did think to just scrap what I was writing, but I think it is relevant if only if someone can explain why I am wrong? On 19/02/15 17:06, Anthony Ferrara wrote: >>> With strictly typed $a and $b, the expression drops to 1 possible >>> >> permutation. And you can detect if it's a valid one. And many static >>> >> analysis engines do this. >> > I didn't see any proposal that proposes strictly types variables. As for >> > parameters, both strict and coercive typing provide knowledge about the >> > types of parameter inside the function they are defined in, so no >> > advantage to strict typing here. > It's not about how data gets in, it's about how data moves once it's > in. It's about knowing how types change and flow into other functions > that's important. Because that lets you determine more data about the > stable (non-error) state of the application. With much of this it is what validation needs doing where. Data coming into the process can either be well constrained, or totally random. Pulling stuff back from a database, it has already been sanitised and should be well constrained but even that may be questionable. Processing the data may well introduce other constraints and I make no apology hammering data size again. If we get an overflow for what ever reason it has to be handled, and while that may be by adding additional checks on a generic datatype, using a suitable already constrained type just seems logical. Even more so if your reason for introducing strict elements is to produce better optimized code? If all I need is a 16bit count and the process will never exceed that do I really want an unconstrained variable to represent it? I will put my hand up and say that up until now I've not worried about just how some of this works inside the box. It has only been since 64bit builds have become the norm and unexplained errors started that I have dug into that layer and to be honest some of the constraints that the zend objects have created perhaps does not make sense although it does explain why some people want to take it a stage further. If I have a variable which is populated by a string of characters as a starting point, then viewing that as a numeric value is a function of that object rather than creating a new different object. Back to my as_xxx rather than is_xxx ... as_xxx fails if the result can't be produced, or yes it gives a new object of that type. It's how all these extra objects exist that is confusing, but if all the persistent data simply creates objects of the correct type in the first place then why do you need to cast anything? -- 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] Using Other Channels (was Scalar Type Declarations v0.5)
On 19/02/15 18:16, Pierre Joye wrote: > This is not the point of this discussion. What you referto has to be > done for anything PHP uses, every library, every extension or services > (http or other). Now read the rest of what I wrote ... Where ever validated data comes from ... it does not need a cast. If it's not validated ... it needs to be before it can be used anyway. Is every variable stored as a string even when it's source is a validated scalar value? -- 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] Nightmares on type hints, annotations, and aop...
On 20/02/15 05:49, Zeev Suraski wrote: > Pardon me for saying so, but I don't think you're on to a huge scoop here. > Scalar type hints - of all the kinds we've been talking about here, be them > strict, weak or coercive - can be easily emulated with a couple of lines of > code, we all know that. It's been known for years that strict hints are > is_*() else error equivalent, that weak hints are (mostly) just casts, etc. > Saying the class type hints can be emulated with is_a() calls wouldn't shock > anybody either. I think I may have realised just why *I* am having a problem with a lot of this discussion ... I've used ADOdb from day one which already does this ... *I* had not realised that core PHP did not bother with the management of data types that ADOdb is layering on top ... Hence my question yesterday which I will reword ... If PHP creates a new variable what does it store by default? -- 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] Coercive Scalar Type Hints RFC
On 21/02/15 19:56, Pádraic Brady wrote: > 1. Happy to see leading/trailing spaces excluded. Fixed length fields may well be a data source so having to strip them before using them just seems a backward step. The basic C library simply strips the white space so are we looking at using an alternative? > 2. Rules don't make mention of leading zeroes, e.g. 0003 Again data may well be zero padded. This is more likely to be historic material, but it's yet another extra processing step. If we have to process data before then asking if it's a valid number what is the advantage of this? However of cause the C library switches to octal mode and needs pre processing of leading zero's anyway. > 3. "1E07" might be construed as overly generous assuming we are > excluding stringy integers like hex, oct and binary Yet again ... If we have to add a lot of extra checks then why can't we simply ask if the data is a usable integer. At the end of the day it does depend on where the data was sourced? Binary data is only usable if we know that it is binary, or we will be converting some other format anyway? > 4. I'm assuming the stringy ints are rejected? Source material may be 'stringy ints', so all that does is say "we can't use the original variable it has to be converted" rather than we can and use it's 'non-stringy' view. > 5. Is ".32" coerced to float or only "0.32"? Merely for clarification. Omitting the leading zero is normal when doing hand keyed data entry. .32 is a valid data entry ... Omitting perhaps 20% of characters speeds data entry. > 6. Boolean coercion from other types... Not entirely sure myself. > Completely off the cuff: <=0: false, >0:true, floats and strings need > not apply. That would be a major BC break! > 7. In string to float, only capital E or also small e? lower case e is common ... > 8. I'll never stop call them "stringy" ints. For some funny reason we tend to prefer to view numbers on the screen as strings ... having the original string with a value which can be used for calculation is simply how I thought PHP worked. A variable is more than just a 'value', we need it's name which is a string, and a viewable string could be useful, along with other flags. I had assumed up until now that PHP was using that model but it seems not :( -- 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] PDO_DBLIB type handling
On 21/02/15 22:12, Yasuo Ohgaki wrote: >> This driver returns all column data as a string, regardless of how it's >> > represented in the DB. I created a patch for my own use that syncs up the >> > type handling with the behavior of the MSSQL extension. This seems like it >> > would be of general use. Does anyone have any feedback before I put >> > together an RFC? My main question would be whether people would rather have >> > this be the default/only behavior, or whether it should be opted into >> > via PDO::ATTR_STRINGIFY_FETCHES. >> > > Databases return "string" data to return correct data in DB. > Most obvious is "NUMERIC" data type. NUMERIC has any precision. > We may have 128 bit INT in near future also. > > So it should return string by default, PHP may convert types into > PHP native types optionally. Not the other way around. IMHO. It is probably worth pointing to date and time types as a good example of where there is not practical to take a binary view of the data since there are a number of differences between databases, and up until now it has only been safe to use 32bit numbers directly in PHP which is additional reasons for keeping to a string base. ( Since all of my material is managed via databases it is also why I am normally using 'stringy ints'! ) -- 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] Coercive Scalar Type Hints RFC
On 22/02/15 00:07, François Laupretre wrote: >>> 3. "1E07" might be construed as overly generous assuming we are >>> > > excluding stringy integers like hex, oct and binary >> > Yet again ... If we have to add a lot of extra checks then why can't we >> > simply ask if the data is a usable integer. At the end of the day it >> > does depend on where the data was sourced? Binary data is only usable if >> > we know that it is binary, or we will be converting some other format >> > anyway? > I asked you for rules to recognize octal. I am all in favor of recognizing > other numeric strings, hexa with leading 0x (detecting trailing h is more > ambiguous and slower), for instance. It was removed some weeks ago for > consistency reasons but it can be reintroduced in a consistent way in the > future if needed. I've given the 'c' ones, but others have already blocked the use of them. Octal escape is allowed but a simple '0' or '0o' has the same problem as 0h or 0x ? Those of us still using 'c/c++' get used to the old standards. >>> > > 4. I'm assuming the stringy ints are rejected? >> > Source material may be 'stringy ints', so all that does is say "we can't >> > use the original variable it has to be converted" rather than we can and >> > use it's 'non-stringy' view. > Can you explain? I don't understand. I'm working with a 'variable' which may be an integer but that is only enforced by reference to how I am looking at it. I understand that some people want to ONLY allow it to be an integer and that may be the constraint added to it, but you may also need the string view, or the origin may be a string already, so one maintains both a binary view and a 'string' view of the same variable. So I don't subscribe to 'stringy ints' because all variables have a stringy element naturally. If I had any need for 'strict' constraints on a variable it has to cover both the size and type of the data, simply saying int is of little use if the data is too big anyway. -- 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] Coercive Scalar Type Hints RFC
On 22/02/15 00:52, Pierre Joye wrote: > My gut feeling, having quite a large users base to back my rough > estimation, is that most won't even know or notice it. The majority of users have no need for it at all ... so is there any need for it to be even compiled in for a general user ? -- 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
[PHP-DEV] Unnecessary extensions ...
With the discussion on adding http extension by default and not now having other key extensions in a normal build I'm looking at what I NEED and what I can get away without. On the current PHP7 test build I do not have mysqlnd installed as I don't use mysql, but I can't make the mysql section available in a second php-fpm instance becuase I can't add mysqlnd as a shared module. Just what is the current state on what is 'required' and what is still optional. I will return to banging on about breaking up php-src so that one CAN get away with building individual modules and I see no reason why those who want 'strict' can't have that as a pecl module to replace 'lax' operations. -- 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] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
On 22/02/15 18:37, Zeev Suraski wrote: > Variant* calc(Variant& val1, Variant& val2) { >if(val1.isInt() ) { > // type checking > if (!val1.coerceToInt()) { > throw new RuntimeError() > } > If (!val2.coerceToInt()) { > throw new RuntimeError(); > } > > // function body begins here > int result = Variant(val1.intValue() + val2.intValue()); > return result; > } A more practical example would be to replace coerceToInt() with inRange() which includes an int check/'coerce' as part of the range check, and produce a number of errors based on the result. -- 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] Reclassify E_STRICT notices
On 22/02/15 22:30, Nikita Popov wrote: > I would like to propose reclassifying our few existing E_STRICT notices and > removing this error category: > > https://wiki.php.net/rfc/reclassify_e_strict > > As we don't really have good guidelines on when which type of error should > be thrown, I'm mainly going by what category other similar errors use. I'm > open to suggestions, but hope this will not deteriorate into total bikeshed. At last something which fits my roadmap ... Only problem is '"Redefining" a constructor' which I certainly accept while upgrading code, but I also appreciate why 'Remove PHP4 Constructors' might not be accepted leaving a difficulty. I think one ends up with still needing a 'mode' switch if the legacy constructors are retained? -- 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
[PHP-DEV] Type hints ...
Silly question time again ... Currently I have an array of variables and the docblock annotation tells me just what each element is intended to be. I process the variables on that basis and while it may be helpful to have some higher level of 'restraint', I have a working flexible system. As a variable is processed it is constrained by the appropriate rules. If PHP adds 'Type Hints' they will only apply to where I am passing an array variable, and the type hint adds additional processing to that which I already maintain myself. How will that improve performance? Add to this equation that the type and constraints of a variable may well vary from one record set to another. It may well be that a fixed set of types can be defined, but these are not the types currently being defined and would include date types in parallel with a group of numeric types. Passing 'strict' types in some cases just does not compute in my book, and even 'coercive' types only addresses a subset of the types needed so that it adds another layer of 'checking' over what we already have in much of the existing user code base. People keep going on about different rule sets but this just adds another set of 'rules' rather than a single solution. -- 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] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
On 23/02/15 00:25, Anthony Ferrara wrote: > And as the static analyzer traces back, if it finds possibilities that > don't match (for example, if you assigned it directly from $_POST), > it's able to say that either the original assignment or the function > call is an error. Why would using an integer I've passed in a URL be a 'fault'? All of the data navigation functions pass their state via the URL and one simply protects against hackers by filtering the state to a default value if it does not return the correct integer data. -- 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] Type hints ...
On 23/02/15 02:49, François Laupretre wrote: > Hi Lester, > > I am not sure I understand well, but the extended type syntax partially > described in https://wiki.php.net/rfc/dbc may correspond to what you > describe. Such extended syntax will be part of 'Design by Contract', meaning > it's potentially too slow to run in production and checks can be turned on > and off globally. When it is available, PHP argument type hints will become > simplified fast checks that run every time, even in production. > > Extended types will support nested syntax as complex as > 'object(Iterable)|array('id' => int(]0:), * => string|array(string))'. No > limit to the syntax you may support here. It will also be available as a > dynamic feature which will allow to check a variable against a > dynamically-defined type. *This* will bring dramatic performance improvement > in data validation. I don't imagine type hints will bring much in terms of > overall performance. > > I guess that's what you mean but please confirm. I think this will be my next > project for PHP, after STH if it passes. My point is simply that 'Type checks performed by STH are faster than the equivalent PHP code' is only true if ... WHEN COMBINED WITH THE EXISTING variable validation ... there IS a saving. In my book the type check is simply part of the range validation so splitting those two does not make sense. Once I've set up for one check, the other validations simply follow on. If I ADD further 'magic' checks by using this 'new feature' it does not do the whole job so I still need the existing checks anyway. Reworking 15+ years of code to create 'dbc' versions of the existing annotations is another drain on available time. I can see someone writing a 'converter' program to populate some parts of this, but I'm not sure just how helpful that would be. Just as going through libraries to see where someone has stripped the docblock and replaced it with the 'new fangled' stuff be that dbc or type hinting. Which is where I would like existing tools to remain an option, so libraries would need to be maintained as 'legacy' and 'new' even if we have to maintain those ourselves :( >> Currently I have an array of variables and the docblock annotation tells >> me just what each element is intended to be. I process the variables on >> that basis and while it may be helpful to have some higher level of >> 'restraint', I have a working flexible system. As a variable is >> processed it is constrained by the appropriate rules. If PHP adds 'Type >> Hints' they will only apply to where I am passing an array variable, and >> the type hint adds additional processing to that which I already >> maintain myself. How will that improve performance? > > It won't, except if you remove some redundant checks from your PHP code. Type > checks performed by STH are faster than the equivalent PHP code, that's the > only possible performance improvement I imagine. > >> Add to this equation that the type and constraints of a variable may >> well vary from one record set to another. It may well be that a fixed >> set of types can be defined, but these are not the types currently being >> defined and would include date types in parallel with a group of numeric >> types. >> >> Passing 'strict' types in some cases just does not compute in my book, >> and even 'coercive' types only addresses a subset of the types needed so >> that it adds another layer of 'checking' over what we already have in >> much of the existing user code base. People keep going on about >> different rule sets but this just adds another set of 'rules' rather >> than a single solution. -- 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] Type hints ...
On 23/02/15 13:49, François Laupretre wrote: > Hi Lester, > >> De : Lester Caine [mailto:les...@lsces.co.uk] >> >> Reworking 15+ years of code to create 'dbc' versions of the existing >> annotations is another drain on available time. I can see someone >> writing a 'converter' program to populate some parts of this, but I'm >> not sure just how helpful that would be. > > *Please* read the document I reference before giving opinion. OK hands up ... with so many competing rfc's at the moment I was getting mixed up with the 'alternative' formats. Actually I seem to have something cached wrong locally :( > The mechanism described here is based on code block information. It uses > existing information and extends the syntax to check for more complex types. > That's why I said it should fit your needs. > Not reading the document and replying negatively just you because I talked > about DbC is poor, imo. DbC is just a concept, not an implementation. While > alternate proposals may religiously copy syntax from D or Eiffel, I chose to > adapt it the PHP way. For different reasons, including the ones you give > (compatibility with pre-existing info), I chose to implement that by an > extension of doc block syntax. > So, if you want to give an opinion, please read https://wiki.php.net/rfc/dbc > first. See notes below. >> Just as going through libraries >> to see where someone has stripped the docblock > > This can be checked too, on a limited extent, as well as compatibility with > possible PHP type hints. Ideally, it shouldn't be in comments, but is was > done this way. And I am not convinced by the ' automatic conversion' way. A practical example is a package I'm trying to find some time to support - phpgedview. The original has nicely documented code, while the webtrees port reworked that to an alternate format which both made following changes impractical, but more important made the code unusable with phpdocumentor. A number of other libraries are suffering from the same 'modernization' so it would be nice to refresh the original phpdoc annotation with a modern raison-detra. > The only issue is that several list members are absolutely opposed to base > anything on doc comments, despite the fact it has proved useful for years. > Although I asked several times, none took the time to explain me why. It must > be ovious, but not to me. So, an RFC proposing to extend doc block syntax has > no chance to pass. It was already beginning in pre-discussions about DbC with > constructive posts like : "No doc block. Period.". Personally I'm 'docblock only'! And I would prefer all of this type hinting was docblock only as well. Analysing and profiling the code quality just like profiling SQL script ... a job that is done ON the code not IN the code, and if all of the overhead of annotation can be stripped simply by ignoring the comments then that has to be good? > However, I think this can be fully implemented in an extension, with no > change to the core. So, no need to approve an RFC ! The bit I don't like with this is the same as a number of other proposals. How errors are handled. Although that is just implementation. I still prefer old school program flow, and throwing exceptions are only appropriate when you are unable to process the 'error'. If variables being passed to a function don't meet the conditions then the program picks that up and produces an appropriate user message related to that particular call rather than a programmers line number. It's the difference between coding for the coder or coding for the user? triangleArea says there is a DbC error, but the user needs to be advised if possible just what value is a problem. It may be that a number that was input at speed is a character short so the variable processing and this is picked up even before triangleArea is called but it is the constraints in triangleArea that provide the programmer with the information on how to verify the inputs. That the right type is passed is identified here as well so adding that data to the function call is a waste of processing if the validation has already been done? >From a practical point of view, the annotation details may well be used to populate javascript side validation and while I can see how your 'requires' clause can be added to add the size of a variable, an already sized 'type' removes the need to add multiple 'requires' entries where a variable is not otherwise constrained. As you say, all this can be handled differently by different extensions and third party tools and the phpdoc/docblock data is flexible, but the rfc details how it will be used for a particular use senario -- Lester Caine - G8HFL
Re: [PHP-DEV] Coercive Scalar Type Hints RFC
On 23/02/15 18:09, Zeev Suraski wrote: > I don't think it will. But instead of guessing, we should try the patch > with some real world apps and find out. I think that if we find out we can > migrate Drupal (or whatever) in a couple of days or even a couple of weeks > to be E_DEPRECATED free - this approach is very viable. If it requires > months and months of updates, it'll be a different story. There are still a number of things that need agreement before moving forward? 1/ The 'strict hint' camp can't see why even if 'disabled' so that we don't have to bother with it they can have what they want, but it's another layer of unnecessary code even if it can be optimized out. 2/ Drop the 'strict' but keep STH and we still have another layer of complexity that may not fit with other methods of handling variable validation. 3/ Changing the rules for converting types is in my list a separate question to adding STH at all. Even if STH is not being used the rules change? At least some alternative means of producing the current style of working should be retained. 4/ There IS still the alternative option of proper annotation which will provide an alternate method of including type hinting without needing to change the run time code at all. I don't see why this is being rejected as vehemently as not including strict or incorporating annotation IN the code. Keeping development time information in a separate wrapper both allows everyone to follow their own preferences and develop validation tools that work for PHP rather than forcing the use of some other language that is flavour of the month. Neither strict, Coercive processing nor François's alternative provide a complete solution to the validation requirements. Something which could be provided if the right hooks are available to identify hints be that the current rules or some third party strict rule set. There was a query about making hints user definable and that fits in better than any of the current 'single' solutions? Currently nothing is the perfect solution so should any be made compulsory? -- 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] Coercive Scalar Type Hints RFC
On 23/02/15 20:57, Zeev Suraski wrote: > They don't upgrade even when there's > no or very little compatibility breakage. That's why 5.3 is still so > popular, and 5.2 isn't rare to find. Let alone 5.4. You know my position here but not only are the problems of areas that were deprecated in 5.3 and removed in 5.4, trying to provide a hosted version of PHP that works for the older code while keeping the 5.4+ code happy is a problem. I've just been hit with a change of ownership of one of my legacy services and the new owner has 'upgraded' resulting in several sites now having problems. Yes they run but not clean and out of 8 sites I've acquired 5 completely different frameworks. Add in a change from Apache to Nginx ... you get the picture ... I've moved them all to one of my own machines with a 'compatible' build of PHP and we are working again. Should I have reworked each to get them running, yes, but which customer do you keep happy first? They WILL all be moved to a single modern framework ... and I've been saying that since 2012 ... but at least finally I HAVE a stable system on 5.4 which does seem to work with 5.6 and also with the current PHP7 build. However in the process I've lost eaccelerator which used to work well on the PHP5.2 hosting, so I need an alternative simply to stand still ... and while PHP7 is giving a speed improvement it still lags behind what I have on the PHP5.4 machines with eaccelerator. So first step get up to the same platform with all sites, but currently there is no incentive to switch to a slower system ... Your speed table from earlier shows a marked improvement up to PHP5.4 with eaccelerator loaded. PHP7 reduces memory usage and execution time against a basic PHP5.x but not against my PHP5.4/eaccelerator base ... -- 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] Reclassify E_STRICT notices
On 24/02/15 07:20, Stanislav Malyshev wrote: >> I would like to propose reclassifying our few existing E_STRICT notices and >> > removing this error category: >> > >> > https://wiki.php.net/rfc/reclassify_e_strict > Could you add some more explanation about why it is a good thing? I.e., > E_STRICT has pretty clear place and hurts no one, why remove it? What we > are trying to accomplish by that? I'm just not seeing how it would be > better without E_STRICT. I don't think that it is necessary to remove the error itself, but some of the coding style elements it currently 'allows' need to be reviewed to see if it is time they were deprecated, allowing some of the new 'strict' elements to be tagged properly in PHP7 ? -- 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] [Discussion] Last chance for case-sensitive engine
On 24/02/15 08:02, Pavel Kouřil wrote: >> I want to ask this question one more time before PHP7 feature freeze: can >> > we the engine case sensitive from PHP>=7.0? >> > >> > There is a draft for that: https://wiki.php.net/rfc/case-sensitivity >> > (mostly empty), so I decided to ask this question in the internals mail >> > list. >> > >> > Pros: more simple O(1) hash table checks for properties, functions, >> > methods, classes without strtolower normalization on the engine/parser >> > level. Consistency with unicode class names (yes, they are case sensitive, >> > check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4 standards >> > (case sensitive mapping of class names to the file names) >> > >> > From my experience, all modern PHP framework don't use case-insensitive >> > code, so chance to break anything for them is really low. >> > >> > Cons: on the extension level things aren't so good and can be some BC >> > breaks (like with phpng) >> > >> > Possible ways: >> > >> > 1) Keep PHP engine case-insensitive for PHP7 >> > 2) Make PHP engine case-sensitive since PHP7 with possible minor BC breaks >> > in the extensions (this breaks can be easily fixed) >> > 3) Add a compile-time switch, eg. --with-case-sensitivity to the >> > configuration to have an ability to build PHP with sensitivity and make >> > this option enabled by default since next major version (PHP>=8.0). Add >> > deprecation notices in 7.x >> > >> > Thoughts? > Hello, > > I'd personally LOVE PHP being case-sensitive, but I think it's not possible. > > Sure, frameworks and newer code will won't be broken, but what about > the tons of "legacy" code? Personally, I saw too much code (and even > examples in tutorials!) using stuff like MySQL_Query(). And case > sensitivity would break this code without a doubt. (I know mysql ext > is deprecated, but that's relevant right now, this is just one of many > examples - the most common one I can think of, actually). > > On the other hand, this could be fixed by running some migration > scripts over code base, so maybe it's not THAT bad? Who knows. It is fun that some areas are already case sensitive, such as the returns from a database which under the SQL standard defaults to upper case while the convention in code tends to be lower case. One has to convert result arrays case often when trying to work cross platform. However I think that the situation with regards Unicode seems to have been lost in the current battlefield? That a string value needs to be handled with mbstring is another little problem which requires care when pushing strings around. Introducing case-sensitive E_STRICT now would allow an eventual incorporation of proper multilingual support later. Keeping some areas 'English only' does not bother me, but the rest of the infrastructure has already moved on so it is about time PHP joined modern practice? One of the areas that many people may already have worked through is moving from case-insensitive file names in Windows to case-sensitive ones on other platforms which are now a lot more prevalent, so some of the 'BC' problems are outside our control anyway. -- 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] Script only include/require
On 25/02/15 00:38, Dan Ackroyd wrote: > As soon as you have any possibility of including a file uploaded by an > attacker, you are probably going to lose. I think that this is perhaps the key here. My framework for new sites requires a user to log in before they can upload anything. So if your manager is worried about 'all this php malware' and your system allow unmanaged uploads ... all bets are off. The next thing I do with images is to create a thumbnail set, so only if you can get at the original file will there be a problem. I admit that I prefer to leave the file name unmanaged, but the option is to rename it original.xxx is also available. Anything uploaded that is not an image or can't be displayed as a thumbnail gets displayed as an icon, and viewing code as text gets the due diligence it deserves, so even if an approved user tries to add php script it will not be placed in a location where even if they could access it it could be run either directly or as an include file. I totally understand the basis of the RFC, I just don't see that creating a few more smoke and mirror obstacles to practices that are perfectly safe when used correctly but will add more work to 'web admins' who have to get around them even when their code is already safe? The code injection example only works on the basis "Imagine a piece of badly-written PHP code responsible for reading the image from disk and sending it to the browser:" This change does nothing to fix the badly-written code, but it is THAT which needs to be fixed rather than perfectly safe systems that 'disobey' this nannying? -- 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] Script only include/require
On 25/02/15 09:14, Yasuo Ohgaki wrote: > Hi all, > > On Wed, Feb 25, 2015 at 5:58 PM, Lester Caine wrote: > >>> As soon as you have any possibility of including a file uploaded by an >>> attacker, you are probably going to lose. >> >> I think that this is perhaps the key here. > > > I thought it's rather obvious how this RFC works, but apparently not. > I added following description to the RFC. > > == > Do not see how this RFC prevent script inclusion attacks > > - include*()/require*() refuse to compile/execute file extensions other > than “.php .phar” by default. > - move_uploaded_file() refuse to move PHP script. “.php .phar” is refused > by default. > > With this RFC, include*()/require*() only executes files have “.php” or > “.phar” extension and move_uploaded_file() refuse to move uploaded files > that can be executed as PHP script. Therefore, even most obvious mistake > like 'include $_GET[“var”];' will not work anymore. i.e. It cannot read > files like “include '/etc/passwd';” nor execute script like “include > '/path/to/upload/evil_image.jpg';”. > == > > How could this RFC loose? > > I'm not trying to protects users from shooting themselves. > However, this RFC protects PHP programs from script inclusion attack > as well as file inclusion attack via include/require by default. Totally understand what you are trying to do, and if the users you are trying to protect actually downloaded PHP direct from the PHP site it may stand a chance of actually doing that, but it's adding restrictions that WILL break other distributions so either they have to re-work what they do, or switch it off anyway. The people you are trying to protect are going to be downloading a distribution that may well be using 'obvious mistakes' such as .inc or .php5 in addition to .php There have been attempts in the past to make 'script only' files and and these same sort of restrictions, but the fallout did prove more of a problem. Example ... one of the legacy sites I just had to move stopped doing any of the navigation stuff and would not send a contact email. Was working fine previously ... but when I actually started looking at the code strangely the pages were all .html ... yep ... a complex site with lots of content which had originally been hand coded and at some point a few little bits of php had been added in. My nginx setup had disabled processing .html pages so broken site. I don't want to rename all of the files to .php ... I don't need to ... so I've created a php-fpm for .html only and we are working again. Only a few hours wasted but the sort of thing we have to be able to cope with! -- 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] [Discussion] Last chance for case-sensitive engine
On 25/02/15 09:40, Derick Rethans wrote: > To be really honest, I don't think all of the pro's hold up. For a hash > check, there is no change really - the only change that is to remove the > zend_tolower. Previous discussions have IIRC shown that the performance > benefit is minimal. Compatibility with PSR's is also a moot point, as > there are just recommendations. There is still the matter of 'internationalization', which is technically a different RFC, but zend_tolower is only handling ASCII character set? So modifying that function where appropriate may be advantageous later. > However, there are a few extra cons: You are going to break > people's code on a large scale. I simply don't think it is worth it > (again, just like when this discussion popped up every year or so for > the last decade). Having been stung by the 'cons' already in reverse when moving perfectly stable code from windows to linux I'd actually say that it would have been a 'pro' if the mixed case stuff that previous programmers had used had been eliminated. I take a lot more care now ensuring that case IS consistent and if PHP nannied this in the same way it nannies some other style points, then I would put under the pro rather than con! Some of the BC areas being discussed do seem 'why put us through that', but unicode is still being pushed to the sidelines and this is one of those BC breaks which would help pave the way for a clean unicode core in the future. -- 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] The Game Theory of Scalar Type Hint Voting
On 25/02/15 11:23, Dennis Birkholz wrote: > Or you could create a three-way vote, both proposals together need 2/3 > majority over no-votes and the proposals that gets more than the other > is chosen. Even that simplifies things perhaps a little too much? The questions as I see them are ... Scalar Type Hinting - yes/no Type of hinting - weak/strict/other If only weak hinting accepted, option to add strict anyway - yes/no Changes to casting rules are a separate discussion? Change casting - yes/no/partial (selected tidy-up) -- 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] Exceptions in the engine
On 25/02/15 13:19, Rowan Collins wrote: >>> Tony, first of all - this still breaks BC, because exception is being >>> thrown in a place where it used not to be... >> >> I disagree. The following function calls would not throw exceptions >>fopen(...); >>fwrite(...); >>fclose(...); >> >> while the following code would: >>try { >>fopen(...); >>fwrite(...); >>fclose(...); >>} catch () { >> >>} > > But what about this code, which could well already exist: > >try { >$fh = fopen(...); >$this->processLotsOfDataAndMaybeThrowAnException($fh); >fclose($fh); >} catch () { > >} > > If fopen() starts throwing exceptions here, that's as much a BC break as > it throwing them everywhere. If it doesn't, the rules for when it should > throw become even more complicated, and useful in even fewer cases. That is certainly the sort of scenario that I am concerned about. try/catch blocks have been added through a lot of libraries and if the returns now change then currently working code starts to fail. Fixing the extra exceptions looks more interesting, so referring to the first try block above, having to catch different exceptions from each function is the problem here. But I still prefer dealing with the error as part of the function call so I can at least respond in the same context. -- 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] Re: [RFC-Discuss] Scalar Type Declarations v0.5
On 25/02/15 12:58, Dmitry Stogov wrote: >> Does that mean when reading or writing code, in addition to checking the >> > signature of a function, >> > I have to check the 'strict_types' setting at the top as well, to >> > understand how that signature behaves? >> > > I think you should check it in the top line of the file where the function > was called from. Of cause the real world situation here is that the legacy included files and their functions will simply not have type hints. The problems only start to arise if someone updates the library code following one practice while other users are not even bothered by it. I get that if strict typing is added to the library, but the user is not bothering with any type hinting than it will not get in the way, but there still has to be checks in the to find out if the strict check is needed while I may well simply be using the library like I always have ... and throwing strings at it. It's at this point I am trying to work out what will happen? If I am a novice users I just expect the normal weak conversion, and presumably the 'strict mode' function I am calling has the code to cater for that in this instance while also having the checks for strict mode ready for strict mode calls to the same function? I don't see how any of this can be optimised out unless the code is only compiled for one mode or the other. One has to add of cause any third party change to the conversion rules which may come into play as well, but I still see all of this as a red herring since the reason any type hint fails is of more importance than catching that the wrong type of value has arrived. MOST of the time this is 'protecting' against morons who are only interested in hacking your site, so while one passes a few integers via the URL handshaking to control navigation perhaps, one has to ensure that when someone tries to inject alternate text things fail tidily? Even if data is validated via javascript in the browser one can't assume that what should be a nice clean value is actually what gets through? All right if that fails in a later function call then one can crash out, and you don't want to serve hackers anyway, but one needs to know if it is a hacker or a user with a problem. But this more a play against the need for type hinting at all ... -- 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] Coercive Scalar Type Hints RFC
On 25/02/15 15:31, Pierre Joye wrote: > With the other RFC, which changes the casting modes, I wish everyone > good luck. I may be wrong, can happen ;), but we simply do not know > and will not know before 7.0.0 is out. Good luck to change them again > to "adapt and tweak", and good luck to the apps developers to adapt > their apps with plenty of patch versions checks. This is the reason #2 > why I am against your RFC, the #1 being the total lack of actual non > magic casting (read: strict), optionally enabled. Like you I don't see the point of the casting changes but similarly I don't see why we have to have strict mode bolted in to everybodys systems as well. Both RFC's seem to be trying to push the bitter pill through with the main payload ... Scalar Type Hinting. There doses seem to be a general assumption that everybody wants STH therefore it has to be included and I am sure that that simple question would get a substantial majority. As with other 'hints' there is a difference in opinion on just what 'everybody' wants. My objection is perhaps to all targeting an different rule sets, none of which actually do the whole job, and now that I am starting to get into just how the code works, I think I can see openings for hook points where just how a particular style of working can be accommodated. Just as the problem with case-sensitive core, if the right 'filter' can be made selectable we can all have what we want. Yes it will result in confusion over what runs where, but equally we can tailor hinting to match a particular set of rules rather than having to live with some other persons preference such as the 'new' casting rules ... -- 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] Coercive Scalar Type Hints RFC
On 26/02/15 08:05, François Laupretre wrote: > You're probably right but I don't understand what you mean with 'casting'. > AFAIK, we are not touching casting rules, implicit or explicit. BUT ... While Coercive Type Rules don't actually cast, they fail in different ways to what the cast would have been, so someone who HAS cast the value before calling then fails simply because the rules are different? I have never used things like 100kg, and I don't see an easy way to convert that to perhaps 10 gms, but it is a basic part of current PHP so ANY dilution of that should be covered properly. Introducing new rules should mirror across all relevant areas, and I find this a big negative to Coercive STH. But Strict STH is equally bad since again it is not equally applied across all code. One 'cherry picks' when to switch on Strict, one changes the rules that don't fit for Coercive. Neither deserve acceptance because both are only creating more divergence. -- 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] Strict typing and callback vs declare()
On 26/02/15 11:34, Benjamin Eberlei wrote: >> You 'll have to think about each file anyway. To add or not to add >> > declare(strict_types=1). >> > > Yes, but It has only exactly one ruleset to keep in mind. With your > approach the ruleset space is infinite. Much more complex. Currently the rule set is already 'infinite' since many libraries will already be checking for their own conditions and verifying they have a valid variable to start with is the first step. The nice thing about PHP *IS* it's flexibility in the way one is not constrained by a single core framework and the more I look at this, the more making PHP a little more flexible makes sense. Being able to bolt in a validation system appropriate to the library being used makes perfect sense, but I already see that code in the libraries I use anyway. The problem with proper validation is that it either needs the annotation RFC to allow definition of all the rules or access to some other data model such as the metadata of a database. Simply saying 'int' and then blocking all valid forms of that value is only part of the process but providing a mechanism that CAN be optimised for the target and which can be enhanced via that target can only be an improvement on what is proposed so far. And the title here is wrong - this is not restricted to 'strict' it applies to all scalar type hinting/checking. -- 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] A different user perspective on scalar type declarations
On 26/02/15 21:28, Zeev Suraski wrote: >> Yes, the database use case and exterior data has been my main concern over >> > the type hint proposals. Now, this could also be changed (fixed, etc) on >> > a >> > different layer (aka database extensions to deal with native types) but >> > that is >> > likely far more to bite off than one would want at this point. It is >> > relatively >> > painless to go in and cast all of those types but the amount of code out >> > there >> > which people are going to just 'expect' this to work will be fairly large >> > and >> > one of those cases that will possibly be cause for migration concerns. > Thanks a lot for the input! We'll reconsider accepting "1"/"0" as valid > Booleans as the original proposal did. Using a 'char' or other binary field type as multiple boolean flags also resolve to 1 and 0 when pulled apart. The debate from the other side is if there is a need for a 'boolean' field type. http://www.firebirdmanual.com/firebird/en/firebird-manual/2/simulating-boolean-in-firebird/51 and http://www.firebirdfaq.org/faq12/ show some options used to get around the various input problems. So like PHP - no agreement on what BOOL is. FB3.0 is still in development, but adds a bool field for which IS_TRUE and IS_FALSE are not a comfortable fit because for any database a field can have a value or be null (not set) ... this therefore requires using a zval other than IS_TRUE/IS_FALSE to store a boolean value properly! -- 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] A different user perspective on scalar type declarations
On 27/02/15 01:29, François Laupretre wrote: > Yes. Same conversion rules : empty string and "0" are false, all the rest is > true. > > For consistency reasons, we can extend the "0" case to accept leading zeroes > and leading and trailing blanks, as for a numeric string. Just been checking and yes if a multi-bit binary field is a string of '0's it's false - nothing to process - but any bit set gives true and one scans for the set bit. This is one where the leading zero may affect the numeric conversion, but you can read it as a array of 1's and 0's ... -- 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] A different user perspective on scalar type declarations
On 27/02/15 13:12, François Laupretre wrote: > If we allow for trailing blanks, we'll allow the same set of chars > that is already allowed for leading blanks. > > I say'blanks' and not 'whitespaces', because here is the list > currently allowed as leading blank (with ascii values) : Space (32) , > tab (9) , linefeed (10), carriage-return (13), vertical tab (11), and > form feed (12). Depending on the way a database is configured, one may be using char fields which are 'blank packed' fixed length, or varchar which would normally only include white space when it is actually added. It's not uncommon though to cast numeric fields to 'char' to create fixed length records and I would not like to say how many legacy systems still use that approach for building tables of data? -- 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] Coercive STH - some real world tests and updated RFC
On 27/02/15 13:45, Benjamin Eberlei wrote: >>> Drupal admin interface (across the all pages): One new E_DEPRECATED >>> > > warning, which again seems to catch a real bug - stripslsahes() >>> > > operating >>> > > on a boolean. >>> > > >> > >> > All those are due to a bug in substr(), that we see now only thanks to >> > proper type identification. There is no reason for substr() to ever return >> > a boolean. It really needs to be fix to always return a string. >> > > Yes, weird behavior that substr("", 2, 2); for example returns false. But > changing thatis just another evil BC break. Now I don' think that 'weird' ... Although the correct return should perhaps be 'null', but it's long been practice that s there is no result we get 'false' so how any places will have a sanity check based on the 'false' return? -- 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] Coercive STH - some real world tests and updated RFC
On 27/02/15 14:15, Benjamin Eberlei wrote: > Imho the problem is that the return values of php internal functions being > string|false will lead to massive consecutive errors when passing this on > to other internal functions. This is perhaps the crux of my objection to both types of 'error checking' ... OK the return should be an empty string rather than false, but certainly one does not want an exception when nothing is returned. So much code IS based on doing one thing if there is a value and another when there is not, so if that is the problem people are claiming needs fixing perhaps that is what needs addressing? string|false is a core element of most of PHP? -- 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] Coercive STH - some real world tests and updated RFC
On 27/02/15 16:46, Damien Tournoud wrote: > You probably haven't read the examples that I pasted. If you think that it > makes sense to return an error code if the function is called with invalid > arguments, it should be done consistently. The current behavior is just an > absurdly inconsistent, it is really hard to find an argument in favor of > it, other than the argument in favor of backward compatibility. That some changes to the logic of substr have been made is a fact. Negative values were added to read back from the end of the string a function that has been played with over time, # It is NOT OK to start reading past the end of the string, no, no. Bad programmer. If there are no characters left ... the string is empty. # But it is OK to ask for a bigger slice than the length of the string. Yes ... length is the MOST it will return, if less are available then that is all you can get. # It is also OK to read past the begining of the string, why not. If the reading point does not cut characters then yes this is consistent. If the length requested was '2', then I would expect 'a' and false which I think was what the 'bug fix' for PHP5.2.2 was supposed to do, but it was reverted later in 5.2.7 # On the other hand, it is NOT OK to stop reading before the end of the string. Bad programmer. Take 2 characters off the string ... empty string. This may not be what YOU want substr to do and it would perhaps be useful to ADD additional checks so that 'false' is returned when it can't created a string because of the 'invalid arguments', but type hints makes no difference to part of the jigsaw. What happens is exactly what one would expect ... nothing left in the string -> an empty string. Having then to check every time for a '0' string length got shortened to simply being able to check 'is there a string' yes/no, and if no you can do something else. There is nothing inconsistent ... -- 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] Coercive STH - some real world tests and updated RFC
On 27/02/15 20:28, Damien Tournoud wrote: > Hi Lester, > > On Fri, Feb 27, 2015 at 6:51 PM, Lester Caine <mailto:les...@lsces.co.uk>> wrote: > > This may not be what YOU want substr to do and it would perhaps be > useful to ADD additional checks so that 'false' is returned when it > can't created a string because of the 'invalid arguments', but type > hints makes no difference to part of the jigsaw. What happens is exactly > what one would expect ... nothing left in the string -> an empty string. > Having then to check every time for a '0' string length got shortened to > simply being able to check 'is there a string' yes/no, and if no you can > do something else. There is nothing inconsistent ... > > Please, read the examples again, the current behavior is nothing but > inconsistent: > > substr("a", 1) => FALSE > substr("a", -300) => "" ? That was the case prior to PHP5.2.1 The fixes in 5.2.2 were not commonly accepted but give false for both, but 5.2.7 and later give false and "a" which is what was the preferred result at the time. Unless we are seeing something different, I'm only seeing "a" or false for a current output of all your examples. > But anyway, that's not even the point. The point is that return values > that "worked" in a world of transparent type-jungling will not work in a > world of stricter typing checks. Which means that we need: > > (1) To accept that for now casting FALSE to the empty string is the > right thing to do; > > until / unless: > > (2) We fixed all the common functions in the standard library so that > they stop returning inconsistent types, in particular in the cases where > it should not even be a debate what is the right thing to do (for > substr, if the arguments point to an empty slice, return the empty string). That side I totally agree with. The 'fixes' posted so far such as adding (string) or replacing false by 0 should be enough to prevent adoption, and personally I find the strict option just as problematic. -- 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] Coercive STH - some real world tests and updated RFC
On 27/02/15 21:14, Damien Tournoud wrote: > Hi Lester, > > On Fri, Feb 27, 2015 at 9:53 PM, Lester Caine <mailto:les...@lsces.co.uk>> wrote: > > > Please, read the examples again, the current behavior is nothing but > > inconsistent: > > > > substr("a", 1) => FALSE > > substr("a", -300) => "" > > ? That was the case prior to PHP5.2.1 > The fixes in 5.2.2 were not commonly accepted but give false for both, > but 5.2.7 and later give false and "a" which is what was the preferred > result at the time. Unless we are seeing something different, I'm only > seeing "a" or false for a current output of all your examples. > > I meant "a", but you are right, it's a bit less inconsistent than I > thought. The current behavior could be defined as "if the resulting > slice is so that (start index <= end index) and (either start index or > end index is in bound) return the slice, else return FALSE", which is > not very useful but not so bad anyway. > > The only real annoyance is that the check is strict on the right bound, > so that: > > substr("abcd", 5) => FALSE > > while: > > substr("abcd", -10, -4) => "" This is the where the -ve logic stuff was changed. If you try -5 rather than -4 things swap around versions wise. The 'problem' is where the actual buffer length goes to 0 and then -ve. There still seem to be a few edge cases that are not correctly caught, but then currently "" and false default to false anyway so there is ONLY a problem if one DOES remove the weak casting. > That explains one of the E_DEPRECATED triggered by Drupal 7, because > when you want to remove a prefix from a string, you often do: > > if (substr($str, 0, strlen($prefix)) { >$str = substr($str, strlen($prefix)) > } > > But this currently returns FALSE when $str == $prefix. > (Obviously, the most useful behavior would be to return a string in all > cases, like for example, Python.) If you only want strings then OK, but in that case how would you rework the drupal problem anyway? Although I'd not start from that if statement anyway if there is a chance that the $str and $prefix ARE the same string? The current if statement is what is wrong not the second substr. if ( strlen($str) > strlen($prefix) ) { $str = substr($str, strlen($prefix)) } else { // nothing left } But how do you know that the string contains the prefix? Yes the legacy code base needs tidying up and is full of bugs, but we often just need to tidy up the logic ... -- 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] Coercive STH - some real world tests and updated RFC
On 28/02/15 08:24, François Laupretre wrote: > Sorry, not a bug. Documentation is clear. You get 'string|false' from > substr() and send it to a function expecting 'string'. Most languages will > fail on this. It worked in PHP because of implicit casting from bool to > string. We just decided to deprecate this implicit cast. > > Now, we can discuss about substr(), whether it should always return string or > not. But that's another subject. Isn't this the whole crux of the problem? The strict/coercive world fix for 'is there a string left' is to create an error which has to be handled, when workflow wise simply branching on the empty string is the correct action. I can see that some people need the empty string rather than the 'false' but THAT is the sort of thing that 'Coercive' should be handling rather than dictating that it is now an error. This is fundamental to the nature of PHP and dismissing a basic premiss 'another subject' is exactly what both 'camps' are currently doing. *I* want to maintain the ability to write code that runs in sequence, that is what a script language should do. It is NOT designed to be compiled, but processed and having to compile sections to create new functions such as exception returns which may never be used is wrong, just as trying to optimise something that may need the now optimized out element next time a bit of code is used is equally wrong. If you want the ultimate fastest performance just use C or one of the other fully compiled languages an live with the 'delay when you first run it'. Ultimately PHP works because it returns the type of object you need at the time ... fixed single types are not what PHP is ... and that is the type of PHP *I* want but I seem to be in an obsolete minority? I only need the current build of PHP7 because it puts back speed lost due to other changes but it is most definitely heading somewhere I don't want to be. -- 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] Coercive STH - some real world tests and updated RFC
On 28/02/15 08:40, François Laupretre wrote: > My opinion, but that's only mine, is that I would favor deprecating null to > scalar, even for internal functions. It would add deprecation messages but > we'd end up with a cleaner code. null is a very specific 'state' for anybody working with databases. It means that no value was found. Mapping that to a default value for future processing is a job for the application rather than the data packet as returned. It ONLY needs to overridden from a default "" or 0 in cases where the simple default is not required, but on the whole the default 'case' is ALL that is needed. That null is also false in situations where a bool is required is also natural. It's now having to go through all the code and manually add these quite natural casts which is the problem here. It's not a bug or mistake, it just flows in the whole process. -- 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][DISCUSSION] Remove allow_url_include INI
On 01/03/15 00:37, Yasuo Ohgaki wrote: >> Yes, the global vs local setting issue is distinct from the question of >> > "is phar://blah a URL?" > > I think your question is about remote/local resource. > Is phar:// local resource? It's yes. > Is phar:// URL/URI? I think it depends how people understand URL/URI. > file:// is considered URI/URL even if it's local resource. A URI consists of two parts ... URL (where/what the resource is) URN (the name of the resource) phar: and file: are URL scheme names and yes there is nothing here to designate if the resource is local or remote. So yes allow_url_include is a totally wrong description anyway? Simply because at the time is was added I don't think local url's were even considered? -- 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] UString
On 28/02/15 06:48, Joe Watkins wrote: > This is just a quick note to announce my intention to ready this RFC > for voting next week. Since there is nothing in this which needs any changes to the core then surly it simply needs to exist in pecl until such time as a proper replacement for unicode in core strings has been addressed? Since it will still require intl to provide those areas it does not support, and I question if we really need to provide yet another encoding converter. A unicode string handler that just handles UTF8 strings may be yet another stepping stone, but it still falls short of beings able to handle all of the internationalization problems and is simply an alternate to mbstring so one either runs both, or sit down and convert all the third party libraries to eliminate mbstring. Like http extension, it's not essential that it's loaded by default, and leaving it in pecl allows development outside that of the core? -- 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][DISCUSSION] Constructor behaviour of internal classes
x27; work flow question should be "Can I correct the error in the parameters passed?" If the answer to this is yes, then the object should at least be in a stable state to allow that. If there is no object, perhaps because a file does not exist, then the work flow may already define the next step ... create the file ... then if that does not work one may bow out with a null object, or leave an object with a valid handle but with a state showing why it's an empty object. The only package I use on the list is PDO, and where that returns 'null' is totally the correct result. I can see where this is also perfectly correct for some of the other situations as well. The Reflection stuff is something I have yet to find an use for ... a decent IDE is still the right place to do most of that ... but your examples are areas where the other RFC comes into play anyway. -- 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