Re: [PHP-DEV] [RFC] Enumerations
On 04/12/2020 23:24, Larry Garfield wrote: The first step, for unit enumerations, is here: https://wiki.php.net/rfc/enumerations There's still a few bits we're sorting out and the implementation is mostly done, but not 100% complete. I use 'Enumerations' quite extensively but have not found the lack of a hard coded base for that a limitation at least partially because as provided in databases the fundamental restrictions that imposes make using them something of a 'bodge job'. There are two areas I would highlight as causing problems. ... 1/ Dynamic Enumerations ... where the application may need to add or delete values over time. I have a number of tables in the database which provide a dynamic list of elements which are used to provide the lists inside the PHP functionality. These are invariably managed by a numeric index in addition to the text of each item, and historic values remain in the database flagged as inactive. 2/ An area that PHP remains poor at supporting, internationalization. Since the vast number of end users do not have English as a first language, then translations of the enumeration values becomes essential and the table approach obviously works nicely here since one simply provides multiple sets of text in parallel and select the language needed as an option. I am not saying that there is anything wrong with the proposal, only that as with many aspects being proposed these days, there is a distinct lack of consideration on just how some aspects of their use can be expanded to cover internationalization and the example in the RFC has no obvious way of supporting a different language? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP 8 release announcement page on php.net
On 12/10/2020 08:56, Roman Pronskiy wrote: The PHP 8 release is going to be huge, and in some sense, you could say it's a whole new language. There is a feeling that more can be done to promote it more extensively. HOPEFULLY that does not mean it's as much of a cock-up as Python 2 to Python 3 changes. Personally I think this simply reinforces my thought that I will simply stick with PHP7 for as long as I can. I'm still running 7.2 live, and working through the code changes to get 7.3 running without warnings and since I'm reliant on Firebird I now have to manually build modules anyway so securing a private build I can maintain myself seems the right way forward. -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
On 02/09/2020 15:31, Thomas Bley wrote:
I'd also like to propose to use null:
[null, null, $username] = getUserData();
foreach ($source as $key => null) {}
Exactly what null is designed for ...
--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 16/07/2020 22:42, Larry Garfield wrote: After some discussion, the namespacing proposal has been again updated. Two major changes: 1) Only engine code goes in \PHP. There's a separate \Ext namespace for extensions, whether bundled or PECL. From RFC ... " This RFC does NOT propose moving any existing code into the \PHP namespace at this time. That may be done by future RFCs if desired, under their own votes. This is a “policy document” only. " So does that also apply to \Ext? Currently the selection of extensions is flexible and most distributions allow the easy repackaging of just what is available. Creating a 'core' set off extensions under \PHP is essentially saying 'you will make these available' while \Ext is a second class citizen? Personally I think every package even if relegated to PECL deserves to be under \PHP or alternately ONLY the essential core engine components go under \PHP and everything else is \Ext 2) It establishes that an index will be maintained on the Wiki listing what namespaces are already claimed. https://wiki.php.net/rfc/php_namespace_policy This is probably (I hope) the final edit of consequence before voting. Speak now or forever hold your peace.:-) Many of the 'exotic' functions such as 'reflection' are not essential for writing good code, so a core \PHP which defines an essential working set of functions does make sense. What HAS been lost is the development of better extensions such as a \Ext\String or \Ext|Array extension that is more 'object orientated' while leaving the legacy functions wrapped in \PHP ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList
On 16/06/2020 13:14, Michał Brzuchalski wrote: I'd like to start a discussion period for my RFC which proposes to change the use of "blacklist" in Opcache configuration with better self-descriptive terminology. Since there will be a higher level change to all these terms - in all likelihood - trying to push yet another term that does not match the current discussions elsewhere seems somewhat premature. The NEXT RFC will be to bring this in line with the 'new' industrial standard, so is there any point jumping the gun before the international debate has finished? "blocklist", "banlist", and others all have appropriate application but like "excludelist", they all imply a narrower usage area while "blacklist" is accepted generally across all applications. What ever alternative to "blacklist" is adopted elsewhere is going to cause confusion and adding to that confusion with a different 'translation' just makes the situation worse? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
On 15/06/2020 18:00, Stanislav Malyshev wrote: While your quest for more just and fair world is noble and laudable, I think your energies are misplaced in this case. Terms like "blacklist" are established industry terms (and are used also outside the industry - It is now highly likely that M$ will force changes to these in github which is probably part of what has prompted the thread. Once 'new established industry terms' have been dictated, then it's simply a matter of does the PHP process where it is mirrored on github follows the new standard? https://www.theregister.com/2020/06/15/github_replaces_master_with_main/ if people are not following the press coverage. -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Attribute Amendments
On 08/06/2020 19:37, Larry Garfield wrote: That... is not related? This is*not* a documentation tool. At all. It's more akin to moving Doctrine Annotations into core (junior version thereof). It doesn't render docblocks redundant, it renders "using docblocks for custom metaprogramming" redundant, which was always a fugly hack to begin with. A type system improvement for "this parameter must be a positive integer less than 50" would be super nice, I agree, but is in no way related to the topic at hand at all. But at the end of the day, THAT has been the problem all along with people insisting on 'strong typing'. Surly the 'topic in hand' SHOULD be to address the base level variables and create a base that replaces the material that many of us of have used docblocks to provide for years, and which most decent IDE's display currently without needing to add more work understanding new 'ways'. A variable that may or may not be NULL, read only, integer, numeric, string and so on with size and length restrictions automatically managed ... the code for which is permanently loaded and not being rebuilt every time a different 'version' of a variable is loaded. The sort of facility that every database interface tries to emulate when interchanging persistent data with a database value, and an array of which consistently defines a record as a group of variables. Grouping those variables to provide objects which simply manages the relations between them. I suppose the real question is if PHP is a script processor or a compiler? If people want a complied program, then use C/C++ direct! Leave PHP as a script processor and restore one of the main reasons PHP worked so well long ago ... it provided a well managed library of scripts for doing the basic jobs that have not changed since day one. I seem to recall a recent request for BUILDING such a library? But that is exactly what PEAR has provided for years. It's just not well maintained these days simply because it requires a hell of a lot of work to 'bring it up to date with PHP7.x' as does a lot of the legacy code base :( Yet amazingly 99% of that legacy code DOES still run ... just throwing errors that may well simply be ignored. PHP8 is yet another push to make PHP 'more modern' but is it ACTUALLY making PHP better or do we have precisely the same problem as Python but trying to change things piecemeal rather than just going all in and destroying BC and starting again with 'a more current language'? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Attribute Amendments
On 08/06/2020 16:30, Benjamin Eberlei wrote: On Mon, Jun 8, 2020 at 11:11 AM Lester Caine <mailto:les...@lsces.uk>> wrote: On 08/06/2020 09:44, Marco Pivetta wrote: > I was mostly conflicted around the "allow grouped attributes" bit, but > James Titcumb (who currently cannot write to this list due to bounced > emails) convinced me that it is a good replacement for `/**` and `*/`: If twenty years of documentation provided by docblocks is to be replaced there has to be a compelling reason to do so and while this latest drive for yet another documentation method seems to be now a fate acompli there WAS no reason to replace that perfectly acceptable documentation! Attributes are not documentation (they could theoretically be used for it, but its not the intented use-case). Attributes are supposed to be used with Runtime Reflection to have an effect on the program. Their existence does not supersede docblocks, only the use of docblocks for meta-programming (essentially doing what Attributes allows with docblocks). So the statement that "it is a good replacement for `/**` and `*/`" is not correct ... it may be that others do not understand the difference? Personally none of this is addressing the fundamental problem of providing a generic variable system that can manage range as well as 'type' ... something the docblock have been providing for a long time and moving part of that to some new element is only making things worse :( -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Attribute Amendments
On 08/06/2020 09:44, Marco Pivetta wrote: I was mostly conflicted around the "allow grouped attributes" bit, but James Titcumb (who currently cannot write to this list due to bounced emails) convinced me that it is a good replacement for `/**` and `*/`: If twenty years of documentation provided by docblocks is to be replaced there has to be a compelling reason to do so and while this latest drive for yet another documentation method seems to be now a fate acompli there WAS no reason to replace that perfectly acceptable documentation! -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Compact Object Property Assignment
On 31/03/2020 12:36, Jakob Givoni wrote: I don't understand why people are replying to this email that has [VOTE] in the subject as if it's still the discussion thread. Please let me know if there's something I can do about it. The problem Jakob is that the new message is STILL attached to the original discussion. If you simply changed the 'DISCUSSION' to 'VOTE' then your email client still had the original message links in place. The whole email process is something of a mess, and the 'correct' way would have been to start with an empty message, add a clean subject and text and then send it to the list ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Migration tooling and the cumulative cost of purely syntactical deprecations
On 11/10/2019 11:25, Nikita Popov wrote: If we provide this kind of tooling, I think that the cost/benefit calculation on deprecation changes: If we have any syntactic deprecations at all, then it basically doesn't matter how many different (syntactical) things get deprecated in one release, the migration cost is always going to be the same. (This is of course a slightly simplified view, but close enough.) A practical example ... I've just sorted out access to a new clients web hosting and fixed things so I can actually log into the wordpress admin panel. Since there has been no access since the previous support person who set up the site went awall there are a lot of messages to deal with. The first one being that PHP is out of date so wordpress can't upgrade. THAT is good to see since I already know that the site will be broken if it HAD simply updated as has happened on other sites! The question now is just what process to follow to update without taking the site off-line. This is not something the sites owner would ever be able to handle hence the request to help out ... In the case of wordpress, the next problem is working out just what plugins are currently active, which ones will work if wordpress is updated, and which may need to be replaced. But the starting point is what will happen if I start by switching PHP5.5 to PHP5.6 so that wordpress can be updated at all. Should I simply move direct to 7.2 which I have other wordpress sites running on and crib sheets to help fixing the problems I have already tracked. None of this can be sorted by using tools that fix the raw code. The only route is via third party upgrades which relate to which version of PHP is running. *IF* php was a lot more stable when RUNNING older code then one COULD simply update the version and then play catch-up with other updates, but with the current situation, one often has to fix raw code problems to get the older stable site into a state that the upgrade process will actually work. Bottom line ... can I justify a decent price for the time sorting all of this will take when there is no indication just how long it WILL take, and then what work will be required in addition to simply removing the nannying messages from wordpress ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
On 08/10/2019 04:31, Theodore Brown wrote: In 8 of these, the backtick uses are exclusively in test files or other scripts not part of the library source code. Then there are 11 packages with one or two uses each, and only 2 packages with more than two occurrences. Raw numbers:https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34 The question that has to be asked here is how many legacy projects have actually been moved to 'new' services like github, or even use code management anyway. The vast majority of third party hosting is simply based on isolated file management and even running clean-up tools are not going to be easy. Especially where the original author who set up the website is no longer around. While some hosts are maintaining the old versions of PHP, more often these days the big players are buying up small outfits and moving customers to new setups often without adequate care. Which is why ANY unnecessary changes that need to be made as a result are just painful often without ANY gain what so ever on either side? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing fundamental language behaviors
On 12/09/2019 23:16, Mike Schinkel wrote: How many of those are actually developers? Because the way I understand this numbers, "powering the web", that doesn't mean 34% are also developers. It wouldn't surprise me if a big portion of these applications could've also be a system written in another language, deployed, plugins installed, added some themes and done, no PHP knowledge required. Most WordPress users are*not* programmers. Which is why introducing breaking changes to PHP will potentially affect them so negatively; because they have no programmers on staff nor any skill to fix the problem. Which means they will have to hire expensive programmers — like me!!! — to fix a problem that from their perspective they do not understand nor will even recognize a benefit when the code is "fixed." Again, I am just presenting this perspective on this list. Those who vote on this list will decide if breaking WordPress end-user's site bothers them or not. Something which does not help here is the way WordPress enforces upgrades that may not be compatible with all elements of the themes that the user currently has active. I AM a programmer rather than a web designer and am having trouble keeping WordPress sites stable. To that end I have decided simply to freeze at PHP7.2 for various reasons but WordPress is now complaining that the version of PHP is out of date. One just can't win ... some of the WordPress sites themes will not even work with PHP7 (or WP5) at all. So we *DO* need an LTS version of PHP that will run perfectly functional websites for the next ten years while others create the next replacement for the likes of WordPress by moving framework functionality inside PHP ... Much of the discussion on new features cut across the ways frameworks already handle that functionality ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
On 09/08/2019 13:07, Zeev Suraski wrote: It's very, very different. With this approach, even down the line in 2029, PHP remains PHP. None of us has a crystal ball to predict the future, but my guess is that WordPress will stick with PHP, and not move to P++. Based on feedback - Laravel (the most popular PHP framework) - will stick with PHP, and most probably many if not most of the new Laravel-based projects will do the same. As a simplistic view isn't it just another framework? Haven't the the likes of WordPress developed their own API on top of PHP and P++ is just another one? It just has the advantage that it can link deeper into the core engine than ones which simply sit on top? In exactly the same way C++ sits on top of C ? -- Lester Caine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The real world ...
On 13/06/2019 15:51, Rowan Collins wrote: In this case, you already did "wait until later" - you waited until the client saw it, and had the time and inclination to mention it to you. There are far better solutions out there, as others have mentioned, that make sure*you* see the message in good time. Then you can call up the client and say "don't use this screen I think it's corrupting the data", rather than them calling you up after they've entered 1000 corrupted records. Still can't establish why the 'deprecated' message resulted in the image upload failing to complete. The message was down to a missing 'static' on a function that was triggered by the image metadata combined with the 'auto-rotate' of that particular image. Actually the image did not want to be rotated but that is another matter. Plug in the missing 'static' and the image loads, rotates and thumbnails. But without the message it was not obvious the load had not completed. As it happens the next batch of images did not see the problem which is obviously why it had been missed. I had to go back to the image that I'd already manually fixed and reload it to see the problem for myself :( Can you ever guarantee perfect coverage of testing? Several other sites are using the same code so one might expect it to have turned up sooner and this machine has been through 7.0 and is now running 7.2 so in this case am I just being clobbered by not picking it up when moving from PHP5? A lot of the original single use functions have grown static versions over the years since the deprecation and I suspect there may still be others that may need work :( By the way the site I posted originally has been completely down since I emailed them about it ... which is annoying as I want to chase the order I placed Monday ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The real world ...
On 13/06/2019 13:30, Andrey Andreev wrote: What I meant is, all a user needs to report to you is that there was a problem, and since you have logs you can lookup whatever it was (possibly asking just for a timestamp and/or IP address to pinpoint the visitor). JUST had a report of a problem ... Deprecated: Non-static method LibertyMime::storeMetaData() should not be called statically I need to investigate why it thinks it's non-static but the irritating bit here is that "It's just a warning" yet the operation has not completed properly. Had I HIDDEN the warning the client would just have ploughed on but now I can divert to fix the faulty bits of data and sort the problem! It will be some silly thing missed, but in 20+ years of code that are still a lot of those and simply hiding something and waiting until later to clear the problems created is never going to be right :( -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The real world ...
On 13/06/2019 13:04, Andrey Andreev wrote: You have logs to see the errors; relying on your users to report the actual error messages to you is the worst way to do it. How many website logs can you manage on a daily basis? Given the volume of material in heavily used website. I am STILL trying to get long established sites back to a state where that would be a practical approach. Especially when adding material is first element on the to-do list. I've several hours of such work to get cleared first and prompts in that traffic is easier to manage than then working through several machines worth of logs ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The real world ...
On 13/06/2019 08:55, Andreas Heigl wrote: display_errors=Off in production. Which give a white screen ... fine for security but useless for people using the site! While that makes absolute sense perhaps thinking whether there is a way to mark password-parameters in core-functions and hide them in Stack-traces might improve security as that would also hide user-provided credentials in log-files. That would not target userland methods/functions. Though having a Core-Value-object for credentials might even allow*that* Sanitising things would be a nice to have especially where log files are on 'cloud' storage, but the ability to give an end user some indication that there is a problem WHILE display_errors=Off would be helpful? I know the white screen problem has been discussed many time over the years ... Personally I STILL use display_errors=on and just make sure that sensitive information is not displayed in the stack. Most of the time it IS just the warnings one gets and clients can report them and see they are cleared ... so some sort of middle ground between off and on would be helpful? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The real world ...
Seen in the wild ... company name sanitised
Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in
/home/888/public_html/system/library/db/mysqli.php on line 7
Fatal error: Uncaught exception 'Exception' with message 'Error: />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10
Stack trace: #0
/home/888/public_html/system/nitro/core/nitro_db.php(29):
DB\MySQLi->__construct('localhost', '888_4y65f5...',
'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1
/home/888/public_html/system/nitro/core/nitro_db.php(13):
NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...',
'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2
/home/888/public_html/system/storage/modification/system/library/db.php(11):
NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...',
'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3
/home/888/public_html/system/framework.php(36):
DB->__construct('mysqli', 'localhost', '888_4y65f5...',
'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4
/home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124):
require_once('/home/888 in
/home/888/public_html/system/library/db/mysqli.php on line 10
你的代码出错了：
I presume something has been updated that they have not been aware of
since it's library file that triggered the warning ... but it's not the
first time in recent years I've seen this sort of information on
commercial sites and while my own clients just get white screens, those
are created by the likes of Wordpress when 'automatic updates' happen.
Many years ago the response was "well don't update", but 'current
practice' takes that out of OUR hands! So isn't it time that the
triggering exceptions like this did produce a more user secure response
to protect against leaks like this and provide a better alternative than
a white screen?
In the case of this live site, I actually placed an order as it was only
some links that triggered the fault, which may explain why they were not
even aware there was a problem :( From the 'development' side, NitroDb->
should obviously be handling the problem anyway?
--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] open_basedir?
On 11/05/2019 08:53, Niklas Keller wrote: That's exactly the reason why I'm for removing it. There will always be ways to circumvent open_basedir and setups like this are insecure. It gives a false sense of security. It's not better than nothing, because most hosting providers would opt for a real solution instead of leaving users entirely unprotected. What's your solution then? I'll be more than happy to have anything better that will work with thousands of users:) Solutions that work at the OS level have been suggested in this thread. It's not my job figuring out a solution that works better for your business at scale. Suggested, but that falls short of providing a solution for those users who may well not even be aware it is being used. When one hits a deprecation warning there should be a reasonable set of instruction to go with it offering an alternative. It SHOULD also be recognised that many users will not actually have any control over the OS level and being able to wrap different applications running in ones own shared hosting to protect one's own operation IS one of the useful features open_basedir provides? Having to create different hosting accounts to achieve that seems somewhat insane? https://uk.godaddy.com/help/can-i-use-open-basedir-on-my-server-running-parallels-plesk-panel-1619 is an example of one hosting providers use of it and something which would probably require every host to rework their support crib sheets :( -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] email list problem
I've just had my email service disabled for 'spamming' while trying to switch email addresses ... 8 unsubscribes, 8 confirm unsub, 8 subscribe and 8 confirm unsubscribe constitutes spam apparently. The what triggered the automatic closure was the multiple messages where the list sends more than one copy of an post ... HOPEFULLY they have now lifted the ban and this will go. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 29/04/2019 09:01, Zeev Suraski wrote: It's absolutely fine to dislike short tags. It's absolutely fine to believe it shouldn't have been introduced. But the gap between that, and thinking it's fine to remove it - is very, very big. And how long after it's removed will 'https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revive Number Format Separator RFC
On 27/04/2019 13:37, Rowan Collins wrote: The only way I've seen dates stored as integers is as a number of seconds / milliseconds / whatever since some epoch, most commonly seconds since 1970-01-01 00:00:00 UTC Use of a days count rather than a seconds count makes dates a lot easier to work with. 2 32bit numbers give a substantial day count along with either fractional time of day or alternatively a second count for the day. Genealogical data is substantially easier to manage as a day count which can be expanded in accuracy with a time count either viewed as integers or as floating point numbers ... leap seconds just get hidden in the processing. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revive Number Format Separator RFC
On 26/04/2019 12:10, Rowan Collins wrote: This is a poor example, because phone numbers shouldn't be stored as integers; there's nothing you can do with them mathematically, and outside of North America it's extremely common for them to have significant leading zeroes. Along with flagging the country code with a '+' ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 25/04/2019 08:34, Reindl Harald wrote: little fucker when i write you a private mail keep it private And as we are on a public forum I will continue to reply to the forum THAT is how my email client is set up and you can just piss off! It pisses me off that I get multiple replies normally anyway ... The fast majority of people who USE PHP would not even know if their code had hosting switches versions in many cases one ends up with white screens. Even where we are able to use the fancy fixes being used as examples of 'how easy it is to fix' ... this does not help users who would not even know what a PHP file is :( -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 25/04/2019 00:30, Christoph M. Becker wrote: At the same time fixes for the PHP7.2 warnings would be helpful! My templates keep throwing 'count' warnings which currently have been fixed by simply removing the 'count' and leaving the value blank. That is until someone who knows how to fix it provides a fix. It's BUILDING cached templates which can't simply be sanitised by scanning the code base! I don't think this belongs to the internals mailing list, so see <http://news.php.net/php.general/326733>. If *I* was using count then that sort of fix would work. The problem is in the way SMARTY handles adding 'count' of a smarty variable in a template ... and certainly I have well although that may just require going through and wiping every cache and letting it rebuild. Enabling short tags is always on my check list since it became a requirement and I see no reason to change that. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 24/04/2019 22:55, Reindl Harald wrote: under which fucking stone did you live all the years that there is something like Code that has been working perfectly for 20+ years and does not need me to waste ANY time worrying about because THAT code will carry on running PHP5.2, but templating does not need a 60% increase in characters to make it work any differently! And go and learn fukcing write proper code, if you still suffer from 'count' warnings all your code is a mess - period has no place here either! The 'code' I am writing is to use 'count' function IN a smarty template and PHP7.2 complains about how SMARTY expands that in the template ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 24/04/2019 22:12, Björn Larsson wrote: I did a quick check on two open source libraries that I'm using, namely Smarty templating library and Revive ad server. A quick glance at hand shows that they both uses the At the same time fixes for the PHP7.2 warnings would be helpful! My templates keep throwing 'count' warnings which currently have been fixed by simply removing the 'count' and leaving the value blank. That is until someone who knows how to fix it provides a fix. It's BUILDING cached templates which can't simply be sanitised by scanning the code base! -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 24/04/2019 16:07, Stephen Reay wrote: Or use an IDE that has built-in support for inspections/fixing like this, or, as I said, run sed over your project files. Replacing ‘ But why should I have to bother at all? As others have indicated in templates is tidier and HAVING to add thousands of 'php' to the templates serves no purpose other than bowing to other peoples coding styles! There are other easier ways of shooting myself in the foot especially since -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 24/04/2019 17:04, Peter Bowyer wrote: Surely the time for vocal opposition was _before_ voting closed? And actually having a vote would help ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 24/04/2019 15:36, Stephen Reay wrote: Of all the things to ‘refuse to upgrade’ over this seems pretty silly. There are multiple tools that will automatically fix this across an entire codebase in seconds. Heck, a sed 1 liner would do it if you want to DIY it. Another nail rather a reason it it's own right, and I've looked at these 'automatic tools' and until there is one that does not enforce their own views of code style they are just another nail ... it's bad enough when tidy TABBED code gets messed up by someone replacing them all with multiple spaces because that is 'the proper way to do it' ... this is long established coding style issue not simply automatic edits to code that IS working perfectly already. It does not 'fixing' simply because some people don't like it ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 24/04/2019 14:41, vsura...@gmail.com wrote: A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache. This is yet another negative move in my forward planning and just another cross against even bothering with PHP8 ... and PHP7.4 is only going to complain about things so while I've not even started testing on PHP7.3, that is likely to be the last version of PHP I will be using ... once all the warnings are dealt with on PHP7.2 ... I don't think even the carrot of 'JIT' this time trumps being beaten around the head with more and more BC changes we will to have to manage and adding 'php' to every all the other attempts at removing descriptive text elsewhere. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
On 16/04/2019 18:20, Kalle Sommer Nielsen wrote: Everytime the topic of interbase comes up, you always referer to applying fixes, yet I'm yet to see any contributions from you to actually maintain the code at php-src, am I to understand that this means you patch your own builds of PHP? Because it is not something that strengths the argument that has any merit of strengthen the argument of keeping it, quite the contrary if anything. I've never been granted access to commit my own work! But a number of overhauls of the PHP side I've contributed to and tested the work of others ... I started with fixing the problems back in 5.2.x and you will find my contributions on this mail list back then! I was asking about splitting the fbird_* commands back then but was told there was no need as there were no differences that warranted it :( Nothing much has changed in the intervening 11 years ... it's still running the same sites perfectly ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
On 16/04/2019 14:29, Chase Peeler wrote: Not once has the fact that an extension exists in PECL instead of core prevented me from utilizing that extension. The only thing that has ever prevented me from using an extension is when it is not maintained. I've been following this entire thread, and I have yet to see what the big deal about having the extension moved to PECL is. If anything, being in PECL gives you MORE flexibility as you aren't tied to the PHP release cycle. The 'advantage' up to now of being in core has been that the BULK of the code changes have been required to track changes in the PHP side of the interface. The core SQL interface has not basically changed so up until now it has worked fine for both Firebird and Interbase. So as long as someone who understands the PHP side of the equation puts the same generic changes into the driver as in other core extensions then things carry on working ... but developments in the PHP side have become a lot more difficult to track than when I did manage to apply fixes to the driver code many years ago. Moving forward there has been some substantial changes on both the Firebird and Interbase side which today could benefit from a separation but that is not 'essential' to continue to use the the legacy interfaces as the vast majority of development work on the Firebird side is in additional SQL functionality and the core way of passing that has not changed in 25 years so there has been no reason to 'continually update' the driver, only the wrappers around the basic driver. Which do not impact the driver extension itself? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Casting
On 09/04/2019 08:32, Guilliam Xavier wrote: I do kind of like the idea in the RFC, but I think it needs a better argument for it. For your other points, I find that Claude Pache has given pretty good arguments in the meantime (thanks!) =) (By the way, I also thought about say, "nullable_intval()", "nullable_strval()" etc. but we're missing "arrayval()" and "objectval()"...) The debate as always is between those for who 'NULL' is a key STATE that is part of the interaction between a database and program and those who do not have that need. In my world a variable has a number of states and NULL is simply one of them. Thinking of NULL as 'uninitialized' is a reasonable match, and when pushing a variable to a database it's NULL state can be used to trigger loading a default value or to leave the field unset for later handling. HAVING to put a value or a string into the variable because 'it must have a type' is simply wrong. But the need now to HAVE to cast at times is equally wrong? I'm still hitting errors in stuff being moved to 7.2 where the 'fix' is adding a cast, to keep PHP happy, but then the value may well be a NULL return from the data set so one almost ends up needing two versions of a variable ... one to keep the now stricter typing happy and one to store the actual data returned from the database. This also links up with the leading and trailing spaces discussion. That the working value is a left justified or right justified number but the logic now requires an 'int' to keep it quiet is pushing towards needing these separate versions of essentially the same variable :( Making the associative array view of the data difficult to manage ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
On 05/04/2019 14:05, Robert Hickman wrote: I think you're misunderstanding the problem: it's not that the*programmer* doesn't know the types, it's that the*analysis tool* doesn't know them, because the programmer hasn't told it, and currently has no way to tell it. If the static analyser was programmable, it would be possible to provide it such information, within the scope of a single code base. In the case of data returned from a database, the metadata for the database is another source of information relating to that data, and it would be useful if PHP had a means to access that data, but in reality this is still currently an area for developing 'a single code base' within the IDE level rather than PHP itself? The question in my mind is if there is still a place for results sets returned by a database query to simply be associative array elements or whether this is now too old fashioned and each should be an object which handle the validation functions relating to it and encapsulated in an object managing the various aspects of the query results such as errors returned and the like. In place of returning 'false' when something failed? Somewhere to hang failed returns rather than simply throwing the error in the hope that something else will deal with it? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
On 06/03/2019 08:58, Nikita Popov wrote: 1. What is more important to me here than strictness is consistency. Either both " 123" and "123 " are numeric, or neither are. Making "123" numeric is a change we can easily do, because it makes the numeric string definition more permissive and is thus mostly backwards compatible. Doing the reverse change is certainly not compatible and will be a much harder sell. I think it may be worth pointing out here the distinction at least with Firebird and I thought with other databases? A CHAR field is always returned padded with spaces to it's length, while a VARCHAR field is always trimmed to the last non space character. There are often reasons for using CHAR although many of those are probably historic, but trimming them without proper consideration is less than ideal. Returning historic material where numeric data is right justified in a CHAR field is equally valid. Handling these has always required care and it would be preferable that both returned the same result without having to trim and perhaps creating problems when the padded version needs to be returned ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
On 29/03/2019 12:05, Joe Watkins wrote: No, it's broken in both modes. In NTS mode, both the thread that handles events (which illegally calls user code) and the main thread are executing concurrently, they may both be calling functions that cause interaction with module globals, which are obviously shared between threads in NTS mode. You cannot just start threads and execute user code from anywhere, it's not safe in NTS mode and is a horrible violation of share nothing in ZTS mode. It's much more likely to break ZTS mode than NTS, but illegal in both. The main problem here is that Firebird events are not something one is likely to use when running a web service? Which is why simply disabling the events functions would be my own fix in the absence of anybody coming forward to say they ARE using them. Asynchronous access to third party services is an area that does require a much more cooperative code base? Simply asking for a query to run, going off to do other activity, and returning when the result is available is the sort of activity we are talking about here? From the Firebird docs ... The event notification is asynchronous and takes place at the end of the transaction in which the event was generated. A separate thread is created by TIBEvents to wait on the event notification. When the event occurs it calls the “OnEventAlert” event handler to report which event has been received. Note that the event handler is run in the context of the main thread and hence there is no need to worry about thread synchronisation. So ibase_wait_event is sitting listening on the same connection that set the event handler and shares that connection which is where the current method of working comes from. But I have no idea if this can be changed. It is the firebird client which is actually holding the connection on which ibase_wait_event is listening. Using it depends very much on how PHP handles asynchronous events while I simply want to know that the read or write I've just done was successful or not ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
On 29/03/2019 08:50, Benjamin Eberlei wrote: So it looks like I'm going to be stuck on PHP7.3 from now on ... I think you misunderstand what is happening here. Many extensions are "just" in PECL and are still maintained there and kept updated for newer versions. Distribution maintainers like Remi package all the PECL extensions for every PHP version. Firebird support will surely be updated to work with 7.4 and released by distributions. It will *just* not be in php-src anymore. Currently building 'interbase' extension has been turned off because it's failing to pass the changes in master for thread safe operation. I understand that it needs someone to work on it and I would love to be able to do that but it's development requirements have moved outside the area that I can cope with. And many people reliant on it are in the same boat, just as they would not be able to contribute to writing code for Firebird itself. While not perfect, what we have currently does it's job just as PHP5.2 still works on legacy hosting. PDO hopefully will remain available, but re-writing 20 years worth of code base for that different way of working has the same problem as finding resources to update the interbase extension. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
On 29/03/2019 06:05, Stanislav Malyshev wrote: News to me is https://firebirdsql.org/en/news/revival-of-php-driver-development/, but then many Firebird user groups do not have English as a first language and just get on with things locally. Well, this sounds good, but are these people going to develop it outside PHP project? Or are they going to maintain the existing extension? So far, it's not clear to me. As I said 'News to me' ... they certainly have not made any contact on the Firebird php list or responded to any requests to help :( I'm not totally surprised though as other firebird user groups don't engage directly with the 'English' groups. So it looks like I'm going to be stuck on PHP7.3 from now on ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
On 25/03/2019 22:54, Stanislav Malyshev wrote: That means both extensions are effectively unmaintained for over a decade. If this does not happen, then continuing to ship it as part of PHP core distribution is not doing the users any favors. When critical problems have arisen they have been addressed. The few current 'bugs' are not critical and the preferred methods of working is documented. My own attempts at patches in the past have been replaced by ones from developers who understand the PHP side better than I do :( News to me is https://firebirdsql.org/en/news/revival-of-php-driver-development/, but then many Firebird user groups do not have English as a first language and just get on with things locally. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24/03/2019 13:47, Dan Ackroyd wrote: It's worth noting that even after the extension is moved from core to it's own repository, most people using it on Debian or Centos/Redhat/Fedora won't notice any difference. On one hand this is correct but the reason I got stung with a move to PHP7.2 before I was ready was because SUSE pulled the 7.0 repo despite 7.0 being the LTS version on that base distribution. I needed to rebuild a machine, but the key component was not available ... and in hindsight I should probably have pulled a copy of 7.0 from php.net rather than taking the 7.2 replacement. On one hand we get good support from the various distributions, but being able to dovetail that in with the main project can be essential at times! Being ALLOWED to select when we have completed upgrading our end to be compatible is rather important these days, given the much faster upgrade cycles, but not always easy where distros 'keep up to date' automatically :( And even more difficult when they stick with an older version when you need the updated one :( -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24/03/2019 10:58, Kalle Sommer Nielsen wrote: Your objection to the deprecation and removal of ext/interbase has been noted, and will be recorded at vote time. I have no doubt the rfc will go through, my problem then is that PHP7.4 essentially becomes a nogo zone because there is no way to remove the deprecation warnings and hiding them also hides the deprecation messages that can and do need addressing :( Despite the politically correct action of hiding all errors/warnings on production machines, I've always displayed them and I'm not about to change that habit as an error message is much better than a white screen any day. Although I still get white screens as well :( -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24/03/2019 01:42, Kalle Sommer Nielsen wrote: Besides this, it has further magic behavior if the multiple connections are created with the same credentials as one in the same process, I'm not sure if this is fixed with Nikita's patch. But that IS the point here ... In fact many people using Firebird with PHP use it in 'embedded mode', where the client is actually the server process and explicitly blocks a second physical connection! The default $link is the initial default transaction and ibase_trans creates additional links encapsulating additional transactions on the database if work flow requires. The difficulty and one that PDO can never support is that a transaction CAN encapsulate two or more different physical connections and it is this which dictates that operations need an explicate '$link_or_trans_identifier'. Personally I use $conn and $transnnn explicitly to keep track of things ... but if you only open a single physical connection and don't add transactions then the 'default_link' is the only packet of workflow. ibase_connect specifically says "In case a second call is made to ibase_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned. The link to the server will be closed as soon as the execution of the script ends, unless it's closed earlier by explicitly calling ibase_close(). " It was this action that as broken around 7.0.3 ... and it's probably totally incompatible with 'thread safe'? But the firebird client can handle multiple calling processes - and persist connections - so the 'bug' is probably in how PHP and Firebird interact in a new world? We are still using a 20+ year old model. For a simple single transaction packet of work one opens a connection does the work and if the activity crashes it is rolled back otherwise it autocommits when finished. Yes this is magic behaviour but it's the same magic behaviour that it has always done even on C and Delphi platforms and for the vast majority of PHP processes it's all that is needed? It's just not politically correct today? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
(Neely forgot to fix reply address!)
On 24/03/2019 00:22, Kalle Sommer Nielsen wrote:
mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here
This situation never exists in Firebird or Interbase. The ONLY way to
connect is to a database, you can not connect to the server without
using a database in the connection string. Each database is it's own
file or set of files if spread across multiple disks. There is no way of
asking a server what databases are available, you have to know
beforehand. Although some newcomers call it a bug it's an original
design feature.
I'll add BOOLEAN to https://phpsurgery.org/tests/ibtest.php tomorrow,
but there are bugs in your link that don't show in the link I have been
using :( But some of them are not bugs ...
--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 23/03/2019 21:09, Kalle Sommer Nielsen wrote: I updated the RFC with a section earlier to list some of the issues the extension currently has. Thread safety is one area where the way the extension was structured originally may now be wrong, but the main problem with multiple connections is confined completely to multiple connections to a single database. In particular the 'default link' is actually the default transaction handle and additional links are simply multiple transactions on the one connection which I think is where some of the confusion has come from :( A more established Firebird user would simply start a new transaction, while a newbie may try to start a new connection. And in the past the extension has hidden that and quietly picked up the existing one ... "A small subset of field types are supported, anything else crashes" This is news to me ... is there any bug report to back it up? All the current data types provided by Firebird are working in the extension, but you may well be right that we may be better off cloning the existing code and building a Firebird only port going forward. The concern is the same one we had with windows in the past, where adding extra extensions does not always work reliably ... one has to provide a wrapped package with all the edge cases addressed. But all my use in production is using ADOdb to wrap the database SQL problems ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 22/03/2019 13:26, Kalle Sommer Nielsen wrote: I'd like to start the discussion for the future of the ext/interbase extension: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase Currently I am seeing 6 open bugs against ext/interbase going back to 2009 ... 48447 - 2009 The oldest bug relates I think to threading and I think the problem here is trying to use the same connection opened in one thread in the child thread. Close the connection then fork and I am presuming it will work, but I don't have pcntl loaded in production and had to add it to the test setup ... but don't know what I would use it for, but it may be appropriate to use with Firebird's events interface. 62300 - 2012 Tomorrows job ... have the files downloaded now, but I don't recognise the problem as we use null all the time to trigger the database generator code. 71650 - 2016 We do have it documented http://www.janus-software.com/fbmanual/man.php?book=php and it may be necessary to separate it out from the interbase extension to cope with Firebird 4 which adds new data types! 72175 - 2016 The patch nikita has proposed works nicely now I've got it running on 7.2.16 ... the WAY duplicate connections to the same database are handled may be part of the problem with Bug 48447 ... 74076 - 2017 The reported bug is not repeatable, but using the wrong resource id will trigger a seg fault. Not sure if it's possible to detect the mistake and error instead. 74104 - 2017 Again not able to duplicate, but it looks like it's a matter of replacing strptime which should be something I can address in isolation. Getting dates in is the biggest problem everywhere. So is there anything else which is required to bring the extension up to date? There is nothing above that prevents the extension doing it's job for the vast majority of users and even the suggestion that it is unusable due to Bug 72175 does not stand up to scrutiny and can now be fixed in 7.3 and 7.2 anyway ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
On 23/03/2019 13:30, Kalle Sommer Nielsen wrote: This kind of behavior does not belong here in any possible way, and it does not win you any points in favor. Take the rest of the evening off the computer if you cannot handle the reality and issues that is present here in the ext/interbase debate. It's lunch time here and I've just had a phone call from a client complaining that their site is down ... just a white screen ... Actually it was only a small area inside the site and I'd not picked it up in the several hundred pages that make up the site :( Nothing in fpm7 log to hint at the problem - again - so I AM in something of a bad mood. Turned out to be part of the upgrade to get these sites working on PHP7.2/FB3 was missed so suggestions that something I've been using for 20 years does not work does not go down well! -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
On 23/03/2019 12:46, Kalle Sommer Nielsen wrote: Now to get back to working out why Nikita's patch does not work in 7.2.16 ... Obviously because the patch was made for PHP 7.3. Hint: If a macro/function is not available in 7.2, then look at how it is implemented in 7.3 and migrate it or see how other functions who do similar functionality works and port it. When merging the patch with the older code I was fairly sure that it did exist already in 7.2 ... but until I can get php-src synced I'm having to manually scan for this stuff ... at the current rate hg-git will take 24 days so now I need another plan of attack :( -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
On 23/03/2019 12:47, Joe Watkins wrote: The thing is broken The BLOODY THING IS WORKING PERFECTLY ... what is broken is something that simply currently necessitates using the resource that has already been created rather than trying to connect again. The correct response to someone complaining about it is as with many other things in PHP simply to explain they are doing it wrong anyway. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
On 23/03/2019 12:05, Kalle Sommer Nielsen wrote: 80% of this posting is more a personal blog of how you (not "we") have been interacting with the PHP community (as in the PHP.net community specifically). What you should have done was to reply to either me or Dan in the RFC thread with a one liner: "I mean 'We' as in X", that would have been it. We as in the people who rally around when we need to to protect the things we think are important. There are more people today reliant on elements like Firebird than there were 20+ years ago and to be honest if you kick the interbase driver into PECL we will carry on using it anyway, but YES it needs some love - from someone who can navigate around just how resources have been changed in PHP7. The sort of cooperation we had while keeping several extensions available on windows in the past. I'm perfectly happy that I am not the only person using PHP with Firebird and reliant on it continuing to be available! Now to get back to working out why Nikita's patch does not work in 7.2.16 ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 22/03/2019 16:25, Nikita Popov wrote: I've created a patch forhttps://bugs.php.net/bug.php?id=72175 (last comment), which seems to be the biggest open problem in the interbase extension. I'd appreciate it if you or someone else who uses firebird could test this. OK now got a test framework on the development machine where I can check things out. As expected, starting two connections to two different databases just works and simply copying $link to $link1 works as one would expect. But trying to create a second connection to the same database is currently giving me a crash and 'undefined symbol: GC_ADDREF' So I need to tidy up the patch to work with 7.2.16 :( The other part of the jigsaw is working out the significance of the 'default_link' in the code. And I'm taking this back to the firebird developers to check something out. As far as I am aware the firebird CLIENT will reuse an active connection to the database, but if one creates several connections in PHP and a couple end up linking to the same database where does a default one come into the picture. I think the code is basing decisions on the first connection made? Rather than the poll of active connections ... As stated in the bug report, there is no need to reconnect to the same database, but there will be a default transaction for the connection which requires explicit transactions to be handled and this may be why there is thought to be a need to open new connections when one simply manages extra transactions on the same link. Working of a singleton link just works and so in that case the bug is irrelevant rather than a show stopper. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Firebird - Who are WE ...
Over twenty years ago Borland took over Ashton Tate to bring dBase into the Borland tool set. What they did not appreciate at the time was that Ashton Tate had taken over Interbase to provide a proper multi-user database engine to augment dbase. The bean counters at Borland decided there was no margin in the Interbase part of Ashton Tate and announced it would be end of lifed! They did not appreciate at the time just how many people had moved from dbase over to Interbase and how many businesses were then reliant on it. In a knee jerk reaction to calm things down they offered to open source the code ... and long story short Firebird came into existence. The bean counters THEN began to realise what a cash cow Interbase could become or rather could have become so the end of life was rescinded, but the the cat was already out of the bag. Roll forward 10 or so years and PHP drops the Interbase driver from the windows builds. Well actually there were no official windows builds so we had to rally around and provide them, but the drive to sort out building PHP on the newer windows compile stacks saw the interbase driver pushed to the side "because Firebird did not support compatible builds!". So we just carried on providing them outside the PHP project along with other key elements like imagick! The key reason for not allowing Firebird into windows builds was that it's client library was no compatible with the build set and that Firebird needed to be compiled with the same version of windows compiler. This did not make sense then just as it does not now. A database engine is a stand alone section of code and may well be running on a completely different machine so why should the version of windows used make any difference ... if the server is on Linux? The important bit is that the LOCAL client program can be linked to the local user - in this case PHP. With the windows setup the interbase extension paired with the firebird client and all that needed to be done to access a newer Firebird server was to load the newer client onto the machine. The link between the interbase extension and the firebird client has not changed in many years. So today to switch from PHP connecting to a production FB2.1 or FB2.5 to an FB3 machine we simply install the correct client and do nothing with the interbase extension. Today there are problems IN the interbase extension caused by the way PHP now handles a 'resource' such as a database connection. Firebird (and Interbase) has the ability to create transactions between two or more active connections and commit or roll back all as required. PDO does not allow multiple connections at all so there is no way to action it via PDO so the interbase extension is the only way to access it. I think that part of the problem of the way the resource handling has been updated in the extension is down to not understanding this element and yes someone who understands firebird needs to maintain this but it's the way that PHP has changed the API which also needs to be understood. *I* have tried to keep up to speed with the PHP side of things, but having submitted fixes in the past, trying to decipher what Nikita is trying to do in this latest patch is difficult looking at the code in isolation since there are lots of 'system' calls that I don't follow. Personally I don't need more than a single link to a single database so everything still works for me anyway, but with persistent connections I presume the resource links should be managed at a higher level anyway? On my own development platform I think using hg-git to access the php-src repository is now impossible. Since yesterday afternoon I've downloaded 896 commits of the 24601 I'm behind, so while THG works perfectly for all the key components such as ADOdb, smarty and ckeditor, if I'm going to work with php code I'm going to have to bypass that! Which is yet another learning curve when the one I am on works well to provide the input that I do provide. ADOdb has been kept up to date with the changes in questions and results passed over the link but to date nothing major has changed in 20+ years in the process of sending a query to the database and getting a result set back ... although handing the new authentication methods added in FB3 may benefit from a major rebuild of the extension, which WOULD require that the fbird_ aliases are moved to their own build of the extension, being completely incompatible with current builds of Interbase. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 22/03/2019 16:25, Nikita Popov wrote:
I've created a patch forhttps://bugs.php.net/bug.php?id=72175 (last
comment), which seems to be the biggest open problem in the interbase
extension. I'd appreciate it if you or someone else who uses firebird could
test this.
Nikita
Am I jumping the gun a bit? I've got 7.2.16 configured so I can compile
it myself. It's throwing a warning on compile
./ibase.h:761:28: note: expected ‘ISC_UCHAR ** {aka unsigned char **}’
but argument is of type ‘char **’
ISC_LONG ISC_EXPORT_VARARG isc_event_block(ISC_UCHAR**, but the
compiled copy is clearing my ibtest suite.
I've ported your patch to the 7.2.16 copies of the files but this is
throwing a different warning
"implicit declaration of function ‘GC_ADDREF’;" and GC_DELREF
GC_ADDREF certainly exists in the file already but not GC_DELREF so am I
missing something that will stop me making this work on 7.2.16?
It is at least running - http://smallbrook.co.uk:800/phpinfo.php but I
need to add something to test this problem as my framework only uses a
singleton connection ... http://smallbrook.co.uk:800 needs a login, but
the database searches are running fine.
I'm still waiting on mercurial syncing with git but hopefully in the
morning I'll be able to cross check changes in the files over time.
--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 22/03/2019 13:26, Kalle Sommer Nielsen wrote: G'day internals I'd like to start the discussion for the future of the ext/interbase extension: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase The rationale for pushing this extension out of the core is mentioned in the RFC. Unless there is any serious issues raised here, then I will put this into voting on Monday 8th of April, noon EET (which is a good two and a half weeks away). The intended voting period is set for 2 weeks, meaning if voting proceeds, the pools will be closed around Monday 22th of April, noon EET. It is not that we don't want to stand up and maintain it, it has been impossible in recent years to get a handle on just what needs to be done TO maintain it. The PDO extension is in a much worse state than the main interbase one but both of them do their jobs as well as they can given that in the case of PDO it can't handle the cross database transactions, something that the main extension does quite happily. Personally I've been wasting time recently trying to keep alive sites that are using MySQL and the main problem with MySQL is the one thing that Firebird does nicely. Backup just runs as a secondary cron job independent of PHP while MySQL is reliant on PHP and current backups on some wordpress powered sites are failing because they run out of time or memory. I've never had a problem with loosing data with Firebird while I've had recover MySQL situations a few times in the last year! So all we are asking for is HELP with the code changes that result from changes to the PHP API to keep this available. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Struct Data Types
On 15/03/2019 09:54, Nikita Popov wrote:
could then become something like
// declaration
class AnotherStruct {
readonly string $firstName;
readonly string $lastName;
readonly ?int $age = null;
}
// initialization (syntax up to bikeshedding)
new AnotherStruct {
$firstName => 'Little',
$lastName => 'Johnny',
$age => 5,
}
I'd generally prefer a solution that is based on the existing class system.
Especially as it means that other use-cases can also benefit: Sometimes you
might only want some of your properties to be readonly, etc.
There is also more room to add formal validation so we could have
class AnotherStruct {
readonly string(64) $firstName;
readonly string(64) $lastName;
readonly ?int(0-150) $age = null;
}
Although I would perhaps expect in this case to have 'date of birth' as
'immutable' while age is something that will be variable.
But isn't all this just mainly another class object. As has been
suggested for an improved array object but never developed further?
Create an extension to support it first, although the validation element
is still needed for any variable across the board ...
--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] print with newline
On 03/03/2019 05:34, Steven Penny wrote: You trеw the bait with no luck. If you didn't get the hint. Your request have extremely low probability of acceptance. Try something else. how about you dont tell me what to try, and i dont tell you how to spell "took". Threw is the more likely correction ... The fact that you think adding a line feed by default will solve something tells me you have not looked at the problem properly. Same as the developers on many projects where we seem to get extra unnecessary blank lines probably because the language throws on in by default. When the browser displays HTML one needs a for a new line rather than extra white space, so since PHP essentially targets web page generation a 'default' new line needs to be properly considered as to just how to actually create it on the output. I get pigged off by paypal throwing in EXTRA blank lines in the address data which have to be stripped before you can use it following a paste ... adding hard page ends needs to be properly thought about! -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpenmod/phpdismod
On 04/02/2019 06:24, Remi Collet wrote: P.S. I have never understand the need of such tools... did it made sense in previous century, where download have a cost ? BTW, on package linux distro, when I install a webapp which depends on some extensions, I obviously expect than everything needed is enabled... It's nice to be able to ignore MySQL and Postgres when one is not using them in production, so the ability simply to load those extensions one actually uses is a nice to have ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpenmod/phpdismod
On 03/02/2019 02:44, Walter Parker wrote: If you can make it work on MacOS, Windows, and the BSDs, then great. Otherwise, it should be left to the Linux distributions. And bare in mind that there are a number of different standards CURRENTLY used across the different LINUX distributions! The question of managing selection of what extensions ARE loaded is a minefield in it's own right ... and just where they are loaded by default. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] JIT
On 03/02/2019 06:51, Zeev Suraski wrote: While this is anecdotal, I think you might find a different perspective from user group organizers. I've encountered many user group members over the years who run PHP on Windows. It's more common that they develop on Windows and deploy to Linux, but I do know those who also deploy to Windows in production. This is actually very consistent with my experience, including some hard data I have from relevant (even if it 100% representative) download and usage stats. Windows is an extremely popular platform for developing PHP on - in fact, from the data I have (which isn’t conclusive) - it’s even more popular than Linux in certain demographics. But much like you say, this dev scenario is more common (I would say a lot more common) than it is to see Windows in production - which does not come to say it’s non existent in prod, just that it’s a lot less common. To add to that ... just how many windows based developers have actually moved to PHP7? I'd missed that the official windows package HAD dropped PEAR, but it's provided as part of the older third party windows distributions, and THOSE are the ones being used by the people I'm supporting because for a time there were no official distributions on windows.. THAT is the reason their code base has not move to PHP7 as it does not have access to all the third party packages being used. While JIT should be totally transparent, is it not the case that invariably edge cases can cause different effects on different platforms, and it is perhaps that which is creating a concern if code can't be fully tested on a windows platform for that reason? In practice, it's academic, since if there are subtle differences between Linux and Windows it probably does not matter if JIT is enabled or not? One or other is simply displaying a bug that needs fixing? Certainly production wise there is little evidence that W10 has done anything to improve the speed of the web stack which still lags far behind Linux on the same hardware, bu it's some time since I ACTUALLY tested that but perhaps it is time to update my own benchmarks. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
On 02/02/2019 14:28, Peter Kokot wrote: About PECL, then I assume we keep it as is for this period also. Unclear, required to install PEAR to be able to run the pecl command, and optionally moving this part elsewhere out of the PHP. Specially, to package maintainers (Linux distros), another repository/project out of the scope of the PHP internals etc. I have to admit that since nowadays I only install PHP via OpenSUSE, what is in core is not actually relevant to me directly since even the packages that HAVE been dropped from core are still fully supported! BUT many of the people I am supporting are only using Windows so it is nice that there is a tidy path for 'package management'. That has included adding PECL packages in recent years and which was still working nicely. Those people have not upgraded from PHP5 for many reasons and having to address additional changes to a stable windows base is just more blockers to bringing the over 70% of sites that are still on PHP5 forward to PHP7. Especially if other moves make Windows a second class citizen? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
On 02/02/2019 02:10, Peter Kokot wrote: Composer is like static linking compared to PEAR which is liked shared linking. Composer can install things globally. I'm not sure I understand why is this even a discussion Composer vs. PEAR core installer script at the moment. The pull request is about disabling the PEAR option. Which I suggest to go further because, for example, waiting for a PHP 10 release for this step is really not a smart move for multitude of reasons... Previously Composer has been pushed as the alternative to using PEAR to maintain third party add-ons. If you disable PEAR then there needs to be an alternative way to provide similar functionality. The NICE thing about PEAR is that it can be managed either by pulling the global packages as in the case of say Horde or one can bundle the same packages locally while maintaining local tailoring of those packages. That you don't understand why they are being linked is perhaps part of the whole problem? Legacy projects CAN at least pull copies of the key third party PEAR packages without the problem of someone else messing them up. Yes the likes of each() screwing things up is a problem and is all part of the agro introduced by deprecating code that is currently working safely and securely, but it is a lot easier to patch that in a PEAR based system than in composer based ones until official patches filter through. Simply trying to rebuild systems heavily reliant on one to work with the other is yet another drain on limited resources. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
On 01/02/2019 08:34, Kris Craig wrote: The more I think about this, the less I like it. According to the page linked to from the RFC, there are 51 current FIG members who would gain a vote. So this RFC would strip most contributers of their voting rights (including me), while simultaneously adding 51 new voters, all from the same external organization (one that has been aggressively gunning for "official" recognition since its inception). In other words, this RFC, in its current form, would have effectively handed control over the entire PHP project to FIG. Though I'm sure it was never the intent, TBH, this does feel like a bit of a slap in the face to past contributors who still have good ideas to offer now and then and should still have a voice. The question of the whether FIG is to become a core standard and everything is then based of it is perhaps the real RFC here? That move would bring FIG developers in simply because their contributions would be direct to the PHP code base? That it does now seem to be the de-facto standard may detract from a formal discussion as to if it should be THE roadmap moving forward? Much like composer is now so enshrined in new projects but is at adds with much legacy code? Bringing in blocks of 'voters' who have a different development style before deciding if that style is acceptable just seems wrong? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][VOTE] mb_str_split
On 05/01/2019 21:11, Legale Legage wrote: Fixed URL:https://wiki.php.net/rfc/mb_str_split It would be useful if the rfc actually included the outline of just what the function is proposing to provide? A start at least at documentation for inclusion in the manual later, but allowing an understanding of just how the chunks are defined. mb characters or bytes for example? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
On 01/01/2019 23:29, Stanislav Malyshev wrote: Finally, I don't think that the global locale is the real problem for PHP. Rather it's PHP locale handling and the fact that setlocale() works per process (and not per thread). When PHP starts up, no locale That's part of locale being global. Though even in environment where threads are not involved, many apps do not account for locale quirks. Like many things that originated in the 'Personal' age of PHP, the 'Server' nature is somewhat inconsistent in many areas. Working with 'time' while some people still insist on using LOCAL time on their servers, the more consistent method is to use UTC and then identify the CLIENTS preferred locale. Displaying other numbers have exactly the same problem and it should be a client locale setting that decides how to display them, with a global base of something ASCII based. Making validation client specific removes the need to mess up the server by trying to run multiple locales with the possible conflicts between that, just as trying to manage multiple times is complicated if the server is running yet another locale? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
Wrong reply button :( On 23/09/2018 07:18, Rasmus Schultz wrote: That is the entire point of the elephant analogy: that knowing what can get in doesn't necessarily mean knowing what is already inside - BUT, knowing what can get in may still useful in itself. I understood that, and I disagree - just knowing what can get in is not useful or interesting in itself. It's not even a new language feature - you can already achieve the same with a simple setter. It's just new syntax. The only reason it's interesting to control what can get inside with type hints, is to enable the language to do something new - something it couldn't already do, which is to guarantee that the type enforces it's own state specification. I understood the analogy, and I don't agree. In other words it's yet another bodge to add strict typing without properly addressing the real problem. Adding 'types' to properties only covers the properties that are supplied via that interface? I think that is what is being proposed here? Internally the object may have other variables that depend on the supplied properties, or be populated from another interface such as a database in my case. THOSE variables need to be managed in the same way as properties, and magic code like setters or PROPER handling of variables is needed to ensure that the variables are suitable TO initialize a variable. All these little patches to making PHP strict STILL need all of the old code to validate that the data is actually usable! PLEASE can we get back to making variables manage their own VALIDITY rather than just some arbitrary concept of type! -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
On 21/09/2018 08:58, Rasmus Schultz wrote: No matter how you twist it, uninitialized is the new null. I'm fine with unintialized as an implementation detail that ensures you can't read from properties while the constructor is busy establishing the invariant. I'm not at all fine with unintialized as a new language feature. Ignoring the debate on uninitialized/null ... not all objects ARE invariant and there are very good reasons for not setting values for everything, but it seems that these types of object are deemed to be 'bad coding' where in fact the simply have elements that yet to be 'initialized' if at all for this instance of the object. The constructor simply creates those elements that need to exit and does nothing with the holders for elements that have yet to be populated ... they stay null. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
On 19/09/2018 22:58, Marco Pivetta wrote: Also, there are scenarios (discussed in typed properties v1) that make the uninitialized state actually favorable (every serializer ever, like every one, really). I still find a problem with this idea that everything must be initialized. If I am working with business logic built into the database then 'NULL' is very much a valid state and when I create an object encapsulating a record it's values should be NULL until it is actually download, or more normally until a new record has SOME of it's fields populated. It is simply not sensible to be nailing down every variable that is being passed and it is certainly not 'bad coding' to be working with uninitialized data - it's handling just what needs to be initialized that is the job of the code. And that is unlikely to be done in the constructor! -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Array max size
On 01/08/18 19:41, Marcos Passos wrote: My understanding is that the conceptual limit is*PHP_INT_MAX*, as there is no way to represent the size above this value. And on which definition, 32bit versions of PHP crash out before 64bit builds ... It assumes that one HAS to convert variables to binary numbers but one can quite easily retain 64bit numbers on a 32bit version of PHP, so why should it not be possible to to handle even larger numbers ... and text keys for an array can handle 'larger' numbers or other identifiers. Now some recent changes to arrays may be containing an unlimited array size, but it should not prevent it from being able to be handled. -- 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] Optional typehint check for parameters
On 16/07/18 12:14, Zeljko Mitic wrote: But please, do keep in mind that I would like to have this feature as optional. The problem with most of these 'improvements' to PHP is that the case is always made that 'you do not have to use it' and this is yet another load on the code base that 'you do not have to use'. However SOMEONE will come up with a use in a library that means one has little option but to have to use it and switching off would break that. As Yasuo has said, there are other ways of doing the same thing, and moving the 'problem' over to the IDE allows a LOT more flexibility in doing this sort of code management. The fact that once added, typehint is then a done deal, other areas will also be under pressure to enforce typing and we are stuck with one sides restricted view of how it should work. EVERY variable has a range of limitations and simply enforcing a 'number' when it also needs to be tested for size STILL needs the docblock comments to provide THAT information. Since most processing starts with text strings, enforcing binary data rules already needs some means of converting the input to binary and so is it really so bad to pass the raw variable and test that it is in the correct range within the function ... and PROPERLY handle an invalid input within the proper program flow rather than kicking it out to some other part of the code. Adding a valid default replacing the duff entry may be the correct response. Having to handle all of that BEFORE calling the function is simply the wrong way of programming! Switches to control what features are enablled may no longer be politically correct, but not providing options for some of these 'extras' is just going to increase the pressure on not upgrading and nothing I am seeing for PHP7.3 gives me any reason to need to worry about using it at all ... typehints are certainly an extra negative to changing ... 7.0.x is stable on my LTS platform, so I'll stay on that ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Typed Properties
On 08/07/18 00:35, Sara Golemon wrote: Personally, I think even independently of typed variables, typed properties feel like an 8.0 feature, not a 7.x feature. I probably agree with you on that. (Again, still undecided). The debate seems to assume that Typed Properties ARE a done deal even without a vote? Personally I just feel all this is still going in the wrong direction and trying to work out where to go next is still detracting from getting new work done. In practice if I need 'typed' anything, I need types that actually return an advantage, and unrestricted 'int' and the like is NOT providing that! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 2^3
On 26/06/18 00:14, Alice Wonder wrote: git is for code management but when a release it tagged, creation of the source tarball should be done by the developer, and released by the developer, preferably with sha256 or sha512 sums posted in an easy to find location (which github doesn't do) Or run Hg to handle the packaging ... although I started a sync of php-src of my Hg clone last week, and it's still only 12841 of 20519 commits in and still running. Access to the web view is down currently until I work out how to make that work with PHP7 :( Anybody remember when it was easy to sort out just which tools one used? Nowadays with the range of languages all using different methods and everybody pushing their own agendas, it WOULD be nice to have a simple solution to the web based framework that we can rely on for the next ten years ... and not have to be proficient in several languages to make a set of tools work. And I'm waiting for the demand for Oracle's java subscription to allow me to continue to use Eclipse as the main IDE ... -- 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] Cleaning up unmaintained extensions - interbase
On 20/06/18 10:25, Nikita Popov wrote: Just to clarify which bug I was referring to in that mail, it's this one: https://bugs.php.net/bug.php?id=72175 There are three issues that must be addressed: * The issue in the original bug report: Connecting to the same DB multiple times does not work. * The use of zend_list_delete() in *_close() functions, which is memory-unsafe. * Incorrect interaction of closing and multiple shared connections. While the underlying connection is shared, closing one resource should not close all the other ones, but also not result in any leaks (this ties into the previous point -- you can't just use zend_list_delete for that!) You may need to implement a double resource indirection to properly handle this, one holding the actual connection and another holding the connection resource. If you or someone who is familiar with interbase could fix these issues, that would be highly appreciated. Is there anything in the changes to the code in PHP7 that are ACTUALLY to do with changes to interbase/firebird? On website systems I only ever have a 'singleton' database connection so don't hit this problem, but having just spent half an hour looking through the various notes on different lists it seems to be the way zend handles resources in PHP7 rather than anything to do with the database? THIS is where the nuances of PHP7 need to be understood to be able to read your third point ... where does one need to understand how the database works? I am assuming that my next step here is to work out how zend_list_delete() is intended to be used, perhaps compare that with it's use in other database drivers, and work out just what was broken in 7.0.3 and why ... and "implement a double resource indirection" ... which is much easier to implement if you understand why it is now necessary? -- 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] Cleaning up unmaintained extensions - interbase
On 20/06/18 06:04, Stanislav Malyshev wrote: php7 builds are not that different from php5 builds, and I suspect the issues discovered are also present in earlier versions. Marius has had more luck understanding the nuances of changes and massaging my previous attempts in with his fixes, but I don't think either of us are totally comfortable with the C end of things! Things have changed somewhat in the 40 years since I got my MSc in 'Digital Systems' and today even PHP is black magic at times :( I'm not seeing any bugs listed in bugs.php.net that are security risks. Security issues are not publicly visible. If you have php account, I could assign them to you and you could see them. Or I could arrange a copy for you, if you intend to work on them. Current builds of Interbase and Firebird are moving further apart and security is one area affected. It may well be that we need to split out the Firebird aliases and current builds of Firebird 3 have different security layers to FB2.x and Interbase now. I would at least like to see a copy of what we are talking about and see if I have any chance of being able to work on them ... You consider Firebird a niche area, and similarly the Firebird developers consider PHP the same as the main application software is Delphi and C/C++ so trying to get help from either end has always been a battle. But for me it is still a much more reliable base than MySQL yet new users have little option but to live with second grade tools. I'm not sure just what accounts I have on PHP these days. I used to have logins but I forget nowadays what for. I would just like to get back to producing content rather than firefighting changes every day ... -- 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] Cleaning up unmaintained extensions - interbase
On 19/06/18 21:48, Stanislav Malyshev wrote: What Bug! It's passing all the test that I run on it perfectly stably otherwise I would not even bother with PHP7. But the problem supporting ANY driver is the exotic nature of PHP is just as difficult as the tools it needs to interface with to make a fully functional stack ... I have four bugs for interbase and four for firebird submitted just recently, as security issues. Do you want to take care of them? I can assign them to you if you want to take care of them. The last time I managed to patch php was over 15 years ago, I have not been able to get a handle on the new structure used by PHP7 in part because I've not had time to do any C coding since. I'm still working on moving PHP5.2 code to work on PHP7 while keeping the stack working on W10 and maintained versions of SUSE Linux. And some of the stuff I thought I'd finished upgrading is not working again :( I'm not seeing any bugs listed in bugs.php.net that are security risks. I don't touch PDO_firebird as it does not handle key Firebird features so looking at 'InterBase related' only returns 8 bugs, and one of them is missing documentation on the fbird_ aliases that I use in the ADOdb Firebird driver. THAT is something I do spend time keeping tidy, and fixes some of the niggles raw access encounters, but I will have a look at the 2017 bugs that I'd not been aware of ... the other bugs are somewhat exotic but not security matters. -- 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] Cleaning up unmaintained extensions
On 19/06/18 21:20, Nikita Popov wrote: and interbase (has a major bug since the PHP 7 migration and there is nobody with knowledge of this exotic DB driver to fix it). What Bug! It's passing all the test that I run on it perfectly stably otherwise I would not even bother with PHP7. But the problem supporting ANY driver is the exotic nature of PHP is just as difficult as the tools it needs to interface with to make a fully functional stack ... -- 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] undocumented session_name() change
Since Tony is blocked from this list he has posted a BC break on the PHP-General list ... the main jist of which is that session_name() has had it's DOCUMENTED functionality changed some time between 7.1.11 and 7.2.5 I can't see any discussion on session_name in the last two years or any notification of the change, so when did it happen and why. More to the point, why has the documentation not been amended to match the new functionality? -- 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] Deprecate the backtick operator
On 12/02/18 20:43, Wes wrote: No technical reason. Keep in mind that people dislike... a lot... writing \strlen() (with the leading \) so I thought they would also dislike writing u"unicode" or any other solution that uses more than 2 enclosing characters. My personal fix for that particular problem is simply use unicode IN core and ditch mbstring. That is not going to happen before I pass on, but hopefully some later version of PHP will not have to worry at all about unicode ... -- 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] Tidying out of context errors
On 12/02/18 06:19, Thomas Hruska wrote: On 2/11/2018 9:45 PM, Michael Morris wrote: If we are going to go about removing stupid operators in PHP, the current use of @ as an error suppression operator is much higher on the list since encourages people to write bad code by sweeping problems under the rug Or people don't like how PHP currently handles errors/warnings/notices and would prefer to handle the messages themselves in the same context of the running code (i.e. not in a global handler). I'd rather see the @ operator become a "most recent" message collector instead of purely an error suppressor. That way, the current behavior wouldn't change for existing applications but users could start taking advantage of whatever associated functionality is added. There are also significant security issues that arise when NOT using the @ operator. This is another decisive area of PHP. YES I am still using @ to prevent PHP wandering off on it's own, so I can properly handle things like 'end of file', so I don't want the global error. Much of the push for typing everything is pushing global errors when local path changes WITHIN the class is much more appropriate. The 'most recent' error is how most database error processing is handled, and in most cases the error suppressed by @ is simply taking PHP out of line. Switches to disable global messages are now in something of a mess and adding more and more sources is of little help to the vast majority of users. backtick probably comes into the style class and with people Python for on machine script handling nowadays then removing access to the machine for PHP scripts just seems another push that way? Just what target area IS PHP supporting? -- 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] Strong Typing Syntax
On 05/01/18 01:21, Rasmus Lerdorf wrote: > The reason we don’t have typed properties/variables is that it would require > adding type checks on almost every access to the underlying zval. That is a > huge perf hit compared to only doing it on method/function egress points as > we do now. I think that in hindsight all I have been looking to out of this is that 'zval' has additional capability to standardise validation. 'Simply' adding a crude type check with it's overheads does not remove the validation requirements which still need to be handled much of the time. It the type check ALSO included validation, then the performance hit would be mitigated by the reduction in user side code. But 'error' may not be the right response EVEN with just the simple type check and that is why current typing hacks don't fit MY method of working. I have validation on key paths, but each is isolated from other paths while a core standard method of validation would simplify things in a way 'strong typing' does 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
[PHP-DEV] Personal Home Page
At what point did 'Personal Home Page' become 'Professional Home Page'? I sat down this morning to look at the sites that are still on the 'TODO' list with a view to just what I can do with them and if the clients could do anything to help. The short answer is NO since the reason I'm nursing many of them is because the error messages when trying to run them on a later version of PHP does require some level of professional programming skill. Gone are the days one could simply 'google' a quick fix! In many cases the sites simply give white screen and a 'personal' user has little chance to recover so one moves the site back to an older version of PHP until one can get around to looking at it ... So how to proceed? Well I think it is time I cut many of these clients loose, and to be honest they will be better off with one of the 'free' hosting options that flood the market these days. They just reload the content and change things like contact forms to what the hosting is offering. That will get rid of all the .ASP sites that I've never had time to convert to PHP, and all the static sites that probably never needed PHP in the first place. The problem is I'm not the sort of person who can say 'sod off' but I think I am going to have to a lot less helpful in future :( But even saying no takes time ... A lot of the recent threads have been on a basis of 'Then you should learn to program properly'. But PHP had a very short learning curve years ago and one did not need to be a 'programmer' to write and maintain simple dynamic sites? Admittedly today the infrastructure we have to live with is a hell of a lot more complex than it was, but PHP used to isolate that. Today there seems to be so many different frameworks all of which compete with one another, and nothing that supports the 'personal' user at all? Even MySQL code is being messed up with MariaDB variations and very basic hosting gets problematic. Even the claim that 'one does not have to use this new code' neatly sidesteps the simple fact that the key libraries we rely on bring that very new code into the framework and then one has to understand why things that worked last update no longer work. That is not necessarily because 'the code was faulty previously' and more likely because of the 'improvements' to the library. Checking everything for every update of browser, OS, PHP version, library change, urgent security fix, all take time many of us don't have. Back in 1982 I earned a Masters Degree in 'Digital System', a fore runner to 'Computer Science'. I've tried to keep up with the new bits, but much of what is being loaded into PHP today has no use to a 'Personal Home Page' user and should be in a separate library of tools for the professional under the hood users ... YES a personal user needs to know that they have a variable that stores a number, but they also need to know the limits on the number perhaps depending on other variables, simply requiring that an unbounded string is restrained to an 'int' thing is of little practical use to many users ... they still need the validation library whether they understand 'strict typing' or 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] [RFC] [DISCUSSION] Scalar Pseudo-type
On 31/12/17 22:45, Michael Morris wrote: > Please do not quote large swaths of Tony Marston's crap. He's an > unrepentant liar, braggart and trouble maker that most of the list has > on ignore since the admins can't be bothered to do their job and kick him. I'll ignore the slander ... but perhaps now it the time that I simply cut my poor clients loose and leave it up to them to keep their websites working. Certainly the amount of time wasted coping with CRAP windows updates such as happened last week, the minefield these days of keeping Linux servers actually working and the problems of prioritising just where to spend the remaining time to just keep currently live sites working leaves no time to do any NEW work! OH and the bastards in the US who steal .com domains for porn crap and ICANN does nothing to protect us from !!! At least non US controlled domains are honest when we PAY to renew! Another job to waste time on this week :( So NO I DON'T NEED STRICT TYING ... THE DATABASE INTERFACE TAKES CARE OF LIMITS AND VALUES THAT int DOES TOTALLY NOTHING FOR !!!! -- 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] Scalar Pseudo-type
On 31/12/17 10:24, Tony Marston wrote: > wrote in message news:28ba9e6a-a3f2-2547-d294-f3a1710d5...@rhsoft.net... >> >> >> >> Am 30.12.2017 um 11:37 schrieb Lester Caine: >>> On 30/12/17 09:16, Tony Marston wrote: >>>>>> You are missing the point. If an RFC is so badly written that someone >>>>>> does not understand it, or understand what benefits it is supposed to >>>>>> provide, then there is no point in up-voting it >>>>> >>>>> if i don't undrstand it i don't vote at all - that's the point >>>>> >>>>> not up >>>>> not down >>>> >>>> If you can't understand it then you cannot tell what benefit it >>>> gives to >>>> the greater PHP community, and if you cannot see that it provides any >>>> benefit then you should vote it DOWN. >>> >>> The 'greater PHP community' I continue to support is still only looking >>> for a simply life, but each iteration of PHP7 is just making things more >>> and more complex, which is why I STILL have not switched off PHP5 and >>> 5.4 and earlier is still running a large percentage of sites. Just what >>> percentage of the wider community thinks that strict typing is giving an >>> essential benefit? If there was a groundswell for typing then perhaps we >>> would not have this continual debate on just how to jam a little more of >>> a move that way and get on with a version of PHP that is only typed. >>> Then for one can simply avoid it ... >> >> who thinks it don't give you a benefit? >> >> for new code it's the best you can do do get it as bugfree as possible >> and fro old code you still are not forec to any typehints and for >> migration you have weak types too >> >> sorry, but discuss end of 2017 if types was a goof d idea and talk >> about the 'greater community' but still run PHP5? in the meantime I >> have changed *everything* written in the last 15 yeas to >> strict_types=1 and type hints everywhere - you find so much potential >> bugs that it's worth > > Some of us are clever enough to write code that doesn't have those types > of bug in the first place. I developed my framework in PHP4 before type > hints even existed, and I developed a large enterprise application with > that framework which is now being sold to large corporations all over > the world. That codebase has moved from PHP 4 through all versions of > PHP 5 and is now running on PHP 7.1. During these upgrades I have only > changed my code to deal with what has been deprecated, and I have never > bothered with any of those new optional extras (such as typehints) > unless I have been convinced that the effort of changing my code has > measureable benefits. > > The idea that typehints provide benefits to the whole PHP community is > completely bogus. It only provides apparent benefits to those > programmers who have moved from a strictly type language to PHP and who > feel lost without the crutch that a strongly typed language seems to > provide. I work faster with a dynamically and weakly typed language, so > speed of development is far more important to me. Any so-called bugs > are detected and fixed during the testing phase, so I don't want the > language being slowed down performing checks that I don't want. Thanks for that Tony ... almost exactly where I am as well ... I started just as PHP5 came to final betas - from C++ - and never had a problem with the flexibility that provided. -- 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] Scalar Pseudo-type
On 30/12/17 09:16, Tony Marston wrote: >>> You are missing the point. If an RFC is so badly written that someone >>> does not understand it, or understand what benefits it is supposed to >>> provide, then there is no point in up-voting it >> >> if i don't undrstand it i don't vote at all - that's the point >> >> not up >> not down > > If you can't understand it then you cannot tell what benefit it gives to > the greater PHP community, and if you cannot see that it provides any > benefit then you should vote it DOWN. Not being able to vote, many of us have no option to complain about the way things are going. Currently there seems to be several styles of PHP form the nice and simple untyped version I moved to from very strictly typed hard compiled code I'd been using up until then, through to current code which is reliant on third party things like PSR and Composer and expects only strictly typed PHP. The 'greater PHP community' I continue to support is still only looking for a simply life, but each iteration of PHP7 is just making things more and more complex, which is why I STILL have not switched off PHP5 and 5.4 and earlier is still running a large percentage of sites. Just what percentage of the wider community thinks that strict typing is giving an essential benefit? If there was a groundswell for typing then perhaps we would not have this continual debate on just how to jam a little more of a move that way and get on with a version of PHP that is only typed. Then for one can simply avoid it ... -- 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] Implement missing SQLite feature "openBlob" in PDO
On 12/10/17 00:11, BohwaZ/PHP wrote: >> I think people were reasonably clear during the discussion. >> >> Having certain methods only available on an object depending on how it >> was initialized is just not a good idea. > > As far as I know, no one volunteered to rewrite PDO to change that? > > I don't really understand that logic. Yeah the existing behaviour is not > optimal. But there is no other solution right now. > > Should we also stop adding any feature to PHP because most PHP functions > are named incoherently and we need to wait until all of them are renamed > correctly? Hopefully not :) > > It might be years (or never) before that PDO behaviour is changed. In > the meantime PHP will just be missing features that could have been > provided, this sounds strange to me. The 'other solution' right now is to ensure that the generic drivers for each database API do the right thing, and if you must use generic features then use those drivers. PDO SHOULD only provide the lowest common denominator of data abstraction that works CLEANLY independent of the driver selected. That has already been messed up by some of the 'extras' added to individual drivers and it is about time the ground rules were clearly defined and enforced. That nobody has stepped up to finish the parts of PDO that were put on the back burner when it was prematurely pushed into the core build is perhaps a further indication that it was not the right base from the start? -- 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] Implement SQLite "openBlob" feature in PDO
On 02/10/17 01:48, BohwaZ/PHP wrote: > So for me the use case is quite different here, and openBlob allows > stuff that PDO::PARAM_LOB with bindColumn and bindParam cannot allow > currently. In conclusion openBlob is still useful as it allows accessing > a BLOB outside of a statement and allows to read and write at the same > time without having to load the blob in memory. This is where the limitations of some of the other database engines come into play. In many cases in shared hosting, the database is provided on another machine, so one has to transfer the data results between machines and do not have direct access to the data. PDO can't emulate this function so the question is still SHOULD something that can't be made generically functional be allowed in PDO. Personally I would prefer that for this sort of action the generic driver was used used rather than PDO and I have to do that for other functions in other databases currently anyway. So one does not have to overload PDO with more checks as to if your code will work on the different drivers. -- 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] Implement SQLite "openBlob" feature in PDO
On 27/09/17 10:17, Matteo Beccati wrote: > On 27/09/2017 11:00, Lester Caine wrote: >> The bigger question is - Should database specific extensions to PDO be >> allowed at all? The WHOLE base of PDO was that it would allow easy data >> management between DIFFERENT databases. This should be implemented in a >> way that mirrors blobs generically otherwise the generic database driver >> should be used since a switch to another PDO driver will fail. This >> should apply to any targeted extension to PDO, so anything that breaks >> the generic base data needs tidying up. > That's a wrong assumption. PDO was born to allow quickly writing > database drivers, not as an abstraction layer that allows you to > seamlessly move from one another. I thought the same but I was corrected > by someone that was involved in the process. The whole base that PDO was allowed to be bundled was that it provided a clean DATA abstraction that could be relied on. The fact that it sidesteps the problems of SQL abstraction was pushed to one side as something that could be handled later. If each driver is now producing DIFFERENT sets of data then the whole generic base is broken. Why not simply move back to the generic drivers which are a LOT more advanced these days and rely on higher level abstraction layers where database transparency is an advantage. openBlob is a specific feature of SQLite so the decision to use it already rules out any other database. IN PDO access to it via the generic blob functions is the proper way forward so that a call for a blob gives a blob what ever the underlying datbase. -- 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] Implement SQLite "openBlob" feature in PDO
On 27/09/17 09:47, Dan Ackroyd wrote:
>> https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo
>
> Couple of questions:
>
>> $stream = $pdo->sqliteOpenBlob('test', 'data', 1);
> I tried reading the code but failed; what happens when this is called
> on a PDO connection that isn't to an SQLite database? Also, there
> should probably be tests around that behaviour.
The bigger question is - Should database specific extensions to PDO be
allowed at all? The WHOLE base of PDO was that it would allow easy data
management between DIFFERENT databases. This should be implemented in a
way that mirrors blobs generically otherwise the generic database driver
should be used since a switch to another PDO driver will fail. This
should apply to any targeted extension to PDO, so anything that breaks
the generic base data needs tidying 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] Deprecate and remove case-insensitive constants?
On 24/09/17 11:05, Alain Williams wrote: >> we began to read and write. I have been working in the computer >> industry since the early 1970s on a variety of mainframe, mini- and >> micro-computers, and a variety of languages. and this was all case >> insensitive. It was only the invention of unix which threw a spanner >> in the works. > I remember those early days; things have changed. Back then case was not an > issue: > > * ASR33 Teletypes were upper case only > > * Punch cards machines were upper case only > > Yes: you could sometimes get lower case, but it was hard. > > Case conversion was easy: > > * ASCII - 7 bit characters, easy > > * EBCDIC - 8 bit characters, easy > > (OK: national variants of ASCII/EBCDIC, but still 7/8 bit). > > Some machines, eg CDC, had 6 bit character set - upper case only. > > These days we use Unicode, a 21 bit character set. Case conversion is hard > and, > as others have explained, can be ambiguous, non-reversible, ... That sums it up nicely Alain ... Now the question is actually ... do we stay in the dark ages of single byte character sets or do we move to fully embrace a current well established and extensively used standard. Unicode has perhaps shirked on the matter of 'case-insensitive' so there is no clean solution to that today. That should not prevent the switch to unicode and other threads such as the csv routines are now highlighting additional 'edge cases' where unicode needs addressing, or kicking into the long grass of extensions of mbstring? Maintaining 'case-insensitive' for single byte character sets is an option, but then one needs to stay with that for the whole code functionality? Allowing multibyte constant names with the current limited sub-set of case conversion is just not sensible, but in the absence of a clean unicode case folding/conversion which is the sensible next step? -- 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] Deprecate and remove case-insensitive constants?
On 20/09/17 10:30, Tony Marston wrote: > When it comes to software case insensitivity has been the standard since > day 1. When searching for a file in MS Windows you do not have to > specify case as it is not possible to have different files with the same > name but different mixtures of case. When M$ screwed up the filing system by allowing spaces in file names and also dropping case sensitivity - to make life easier for none programmers - we had to get use to this 'new way of working'. It STILL causes problems today so no it was NOT standard from day 1. Although I can't remember now if DOS 8.3 file names enforced uppercase only but all other OS's at that time preserved case in file names. https://en.wikipedia.org/wiki/8.3_filename explains how VFAT added longer file names to FAT ... using an upper case file name below. File capabilities on https://en.wikipedia.org/wiki/Comparison_of_file_systems will demonstrate just how few file systems are case-insensitive. You will see that NTFS is ACTUALLY case-sensitive and it is only the WIN32 subsystem which prevents file names clashes. It's also that system which changes the case of a name when it's displayed or passed over to other systems :( That all said ... the rather limited question here is if the current very restricted case-insensitivity should be removed, or should it be expanded to properly handle constant names in other character sets? That then needs a LOT of work in other areas where the limited ascii case-insensitivity is allowed? Do we NEED case-insensitivity if that is one thing preventing a switch to use of unicode names in the 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] Progress or just 'a mess'?
On 20/09/17 08:26, Stanislav Malyshev wrote: >> picking up on the base problem? Just what character set is PHP7 designed >> to work with. > > What do you mean by "work with"? Actually that HAS already been identified in this thread, and it is only the basic ASCII character set, but this is not actually specified anywhere? >> For PHP8 is it not time to lay out a similar set of rules as provided by >> SQL and identify just what 'case-insensitive' means and where it does apply? > > I'm not sure which problem you are trying to solve here. Could you > explain what you'd be using these rules for? Having established that the only characters that are case-insensitive in PHP7 ... the unicode basic latin set ... the discussion SHOULD be on either expanding that to cover all case folding or simply removing this rather limited case? Tony Marston is making an impassioned demand to retain this very limited case, and therefore expand it to cover all character sets, and as a fellow 'English only' coder, I can accept that argument. However many of my clients do not use English as a first language so any data handling has to be unicode based, and case in that data can be important, so is case-insensitive really as universal as Tony thinks? Certainly we need data case-insensitivity to handle unicode properly and not just a few english characters ( should I really add a capital 'E' to english just to please the spell checker? ) People are using their own languages when writing PHP variables and function names, and apart from a few edge cases this does seem to be working for them. As with SQL, the key programming words are in English, and I don't think anybody would suggest adding aliases for them, so restricting keywords to 'unicode basic latin set' can be defined, but does THEN making that case-insensitive add to the problems of making PHP more user friendly in handling unicode names elsewhere? I am seeing SQL field names coming in with unicode content, and these are then array keys in PHP ... the latin characters get lower cased at times and this DOES cause a problem if the metadata defines upper case and I suspect that is something that will never be changed now, but the actual rules applied would be nice to know? -- 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] Progress or just 'a mess'?
On 17/09/17 11:53, Rowan Collins wrote: > On 17 September 2017 09:54:54 BST, Lester Caine <les...@lsces.co.uk> wrote: >> Just what character set is PHP7 >> designed >> to work with. > > Focusing on the answerable part of this, PHP actually allows a very wide > variety of characters in identifiers (names of variables, classes, functions, > etc). > > I checked the PHP lang-spec repo expecting to find a set of Unicode classes, > but it currently mentions "U+0080-U+00FF": > https://github.com/php/php-langspec/blob/master/spec/09-lexical-structure.md#names > That seems wrong to me, unless I'm looking at the wrong definition - the > first part of that range is control characters, and you can have variables > called things like $ (with an emoji as the entire name). > > That would definitely be the place to document the allowed characters, > though, and a rigorous definition of "case insensitive" could also be added. > I was wrong, by the way, to say that using "to case fold" rather than "to > lower case" would solve the Turkish I problem - the key for that is to define > a single locale whose case folding you are using, independent of runtime > locale settings. I think this is actually the problem. Unicode is simply NOT a general solution! Normalizing is another aspect, and that can result in differences between strings if one also 'case folds'. On top of which one has to add the collation one is using to provide sort order which is another can of worms? Sorting array keys in order depends on the character set used ... which is perhaps why there seems to be a drive to replace associative arrays with simple numeric ones? "U+0020-U+007F" gives the Basic Latin set of characters (ASCII) "U+0080-U+00FF" add the "Latin-1 Supplement" The problem is that the second 128 characters is avoiding overlaying the "U+-U+001F" control character block, while single byte character sets WOULD be more productive if they followed the extra character convention instead. One of the irritating compromises made by Unicode? It would perhaps also be nice if the file naming convention used 'nbsp' for spaces rather than 'sp' and eliminate the need for quotes around file and directory names, but adding quotes is used by SQL to indicate 'case-sensitive' strings, yet another convention to be given a nod to? If you get an associative key from a quoted field name it is NOT case-insensitive and while a second field with the same combination of characters would be 'silly' it is something that can happen for many reasons ... and explode() falls over in some instances as a 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
[PHP-DEV] Progress or just 'a mess'?
It's a question I've asked before, but there still does not seem to be a proper answer ... just where is PHP in relation to unicode? The thread on 'case-insensitive constants' cherry picks a particular aspect without picking up on the base problem? Just what character set is PHP7 designed to work with. The SQL standard provides a working solution to the problem and one that is still applied 25 years on ... it lists the subset of characters available for writing SQL code. Essentially the Latin character set with well defined special characters. The irritating part of cause is that this standard is one you have to pay for copies off, but the principle can easily be copied along perhaps with some of the extensions relating to handling unicode data within the constrained framework. Everything in SQL is essentially 'upper case' although I still have fun moving datasets to PHP arrays where the keys end up as lower case' versions of the default UPPER CASE returned by the standard. THIS is an area where case-insensitive operations would be very useful, but that is not going to happen any time soon. For PHP8 is it not time to lay out a similar set of rules as provided by SQL and identify just what 'case-insensitive' means and where it does apply? -- 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] Deprecate and remove case-insensitive constants?
On 15/09/17 10:02, Tony Marston wrote: > Why is it not possible to identify a single upper and lower case variant > for every character in every character set? Can't find the right unicode standard page, but https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html sums it 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] Deprecate and remove case-insensitive constants?
On 15/09/17 12:13, Tony Marston wrote: > My argument is that far too many people have become used to case > insensitive software, and to remove this "feature" for no other reason > than the programmers involved would find it "more convenient" to remove > the feature altogether rather than make the effort in implementing a > proper solution would go down like a ton of bricks with all those users. case-insensitive only works reliably for an ascii character set. This is what the vast majority of PROGRAMMERS expect to see. Even Microsoft 16bit subset of unicode characters can not RELIABLY be upper or lower cased, but add the full unicode set and the conflicts of the number of characters required for one or other conversion explains why a conversion to unicode in the core proved impractical. The main point here is that it may be ESSENTIAL to introduce a switch to case sensitive if we are also to convert to full unicode support. The alternative is to restrict the character set back to ascii for all programming operations if case-insensitivity is to be retained. And how many of you have hit the problem of Windows supplying a CamelCase version of a file name when it was entered lower case. Since all our web servers are 'non-windows', hitting the idiosyncrasies of these inappropriate case conversions just adds to the fun. That may not the happening these days, but cause major problems at one time! -- 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] Deprecate and remove case-insensitive constants?
On 14/09/17 14:10, Michael Morris wrote: > On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <les...@lsces.co.uk> wrote: > >> UTF8 introduces a level of complexity and can be used used in many >> places in PHP, but it does seem that there is no drive these days to >> make the core a clean UTF8 environment. This should perhaps be addressed >> again for PHP8? >> > *Cough*, *Cough*, PHP 6, *Cough*, *Cough*. > > Comedy aside, Full UTF functionality was planned for PHP 6 and ended up > sinking the branch because it was way more complicated that anyone realized > at first. Someone involved with the development at that time can speak to > it more accurately - all I know is hearsay and conjecture. My point exactly ... -- 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] Deprecate and remove case-insensitive constants?
On 14/09/17 10:20, Tony Marston wrote: > Then unix came along and FUBAR'd everything. Any advantages of case > sensitive systems are ALWAYS outweighed by their disadvantages. Unix predates Windows ... the use of such breaks as having spaces in file names came from that development in addition to the line ending. The RTTY machines needed a carriage return step followed by a line feed which is why that was two steps initially. Not needed these days, but still embeded from the early days. UTF8 introduces a level of complexity and can be used used in many places in PHP, but it does seem that there is no drive these days to make the core a clean UTF8 environment. This should perhaps be addressed again for PHP8? But the additional problems that case-insensitive then introduces may mean that all case-insensitivity has to be removed at that point? -- 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] Deprecate and remove case-insensitive constants?
On 13/09/17 09:59, Tony Marston wrote: > People who think that case sensitive software is cool are deluding > themselves. When I started working on mainframe computers (UNIVAC and > IBM) in the early 1970s everything was case-insensitive. Life was so much easier when using an RTTY as the keyboard and printer. No one had invented the shift key and the 5 bit character set was easy to work 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] A validator module for PHP7
On 07/09/17 05:26, Yasuo Ohgaki wrote: > As I wrote in README.md, there are only 3 types of inputs. > > 1. Valid data should accepted. > 2. Valid data should accepted, but user's mistake. e.g. Logical error like > your example above. > 3. Invalid. Anything other than 1 and 2 (i.e. Client cannot send these > value) > > "validate" module is supposed to take care 3 which is nothing to do with > models, etc. > It should validate against input data spec, not logical meaning of the > input. If programmer did this, single responsibility principle is broken. BUT you require an accurate 'input data spec' in order to establish what is not part of '3' and this is the same metadata that is needed to ALSO define the 'logical checks'. Once you have established that the input data has a valid set of data you need to VALIDATE that the data is within the limits defined by the 'input data spec' and those checks ALSO apply to any subsequent processing of the data set. The 'input data spec' is important not only to your 'single validation process', but also to further processing that data prior to producing some sort of output. ( No mention of databases but in a lot of cases that is where the key metadata resides? ) My point is that the 'input data spec' is not simply a stand alone array of data only used by the validator. It is something either created by other parts of the 'logic' or it is needed to give individual responses to 'user's mistake' as per '2' ... I understand that you want to return a 'fail' at the earliest possible point, and a single step 'validate' meets that need, but the bulk of the reasons validation should fail is because someone is trying to hack a site by creating 'user's mistakes' that pass '3' that are not handled correctly by '2'. I think where the latest offering fails is that it now requires that any 'custom' validation needs to be written in 'C' while that same code may be needed as a PHP version as in Dan's example. The validation processing needs to be ABLE to be iterated through variable by variable once one has established that there IS a valid set of variables to work 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] Providing built-in functionality written in PHP (was RE: [PHP-DEV] [VOTE] UUID)
On 06/09/17 13:46, Zeev Suraski wrote: > We’d probably have to be pretty selective in terms of what goes in there – > probably just as selective as we are with the C-based extensions, but I’d > imagine that things like ext/exif, UUID, and perhaps even things like > unserialize() could find themselves written in pure PHP using such a > mechanism. My own UUID is a old time UDF add on to the database as the new built in function there does not allow for selection of a Type 1 UUID. UDF is the ideal tool to add functions at the database layer, but it's a pain because it does require C code ... currently. Validation is another area where one often needs to be able to bolt on your own extra functions. Being able to write one's own extensions to things like variable creation or validation is where we are today and writing that functionality optionally in PHP makes sense. The problem is with there being no obvious base to build on. That a variable is often more complex than simply 'int' is a fact, and creating an object for each variable with all of this extra functionality is little different to adding a UUID variable. So a standard method of being allowed to create additional UUID like variables and validate that the supplied data to populate hem is correct. -- 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
