Re: [PHP-DEV] PDO subclass names

A thought crossed my mind, considering that MariaDB and MySQL are drifting more and more apart with features and nuances of how they work, would it be a good idea to create an alias to MySQL PDO driver under MariaDB name so we can create a MariaDB specific implementation down the road and so

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

On Wed, 10 Apr 2024 at 22:31, Tim Düsterhus wrote: > Hi > > On 4/10/24 10:28, Arvids Godjuks wrote: > > The amount of complexity in these two hooks is on the level of the whole > > PHP OOP model with the number of footguns and WTF cases to rival magic > > quotes, re

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

On Wed, 10 Apr 2024 at 06:43, Juliette Reinders Folmer < php-internals_nos...@adviesenzo.nl> wrote: > On 9-4-2024 16:03, Juliette Reinders Folmer wrote: > > On 8-4-2024 23:39, Ilija Tovilo wrote: > > Hi everyone > > Heads-up: Larry and I would like to start the vote of the property > hooks RFC

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

On Tue, 9 Apr 2024 at 09:57, Rowan Tommins [IMSoP] wrote: > > > On 8 April 2024 21:51:46 BST, Jordan LeDoux > wrote: > >I have mentioned before that my understanding of the deeper aspects of how > >zvals work is very lacking compared to some others, so this is very > >helpful. > > My own

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

On Mon, Apr 8, 2024, 16:40 Rowan Tommins [IMSoP] wrote: > On Mon, 8 Apr 2024, at 13:42, Arvids Godjuks wrote: > > The ini setting I was considering would function similarly to what it does > for floats right now - I assume it changes the exponent, thereby increasing >

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

On Mon, 8 Apr 2024 at 14:33, Barney Laurance wrote: > On 2024-04-08 12:17, Arvids Godjuks wrote: > > > Why not have decimal be represented as 2 64-bit ints at the engine > > level > > Just to clarify this point, what's the formula to convert back and > forth between

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

Hello everyone, I've been following the discussion threads and forming my own opinion to share since I have done a bunch of financial stuff throughout my career: I did the integers only at the application level and DECIMAL(20,8) in the database due to handling Bitcoin, Litecoin, etc. My feeling

Re: [RFC] OOP API for cURL extension

On Thu, 15 Feb 2024 at 03:53, Sara Golemon wrote: > Good afternoon folks, I'd like to open discussion on adding OOP APIs to > the cURL extension. > https://wiki.php.net/rfc/curl-oop > > This has been a long standing bug-bear of mine, and I think its time has > come. > > try { > (new

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

On Thu, Feb 8, 2024, 12:12 Alexander Pravdin wrote: > On Thu, Feb 8, 2024 at 6:25 PM Григорий Senior PHP / Разработчик Web > <6562...@gmail.com> wrote: > > > > PHPStan is out the case. > > > > May I know why is it out? > > I'm actively using it in my projects and it helps me a lot to not > relax

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

On Tue, 6 Feb 2024 at 22:09, Larry Garfield wrote: > On Tue, Feb 6, 2024, at 7:18 PM, Arvids Godjuks wrote: > > >> To be clear: I really like this concept and have discussed it with > others > >> before, using almost exactly this syntax. I have not propose

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

On Tue, 6 Feb 2024 at 19:14, Larry Garfield wrote: > On Tue, Feb 6, 2024, at 4:13 PM, Григорий Senior PHP / Разработчик Web > wrote: > > Btw, i agree about Javascript, but on a low level it produces the most > > clean code, because there's no types and rules. All types moved to > > TypeScript's

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

JavaScript is JavaScript - it's not a good role model to look at. If anything, JavaScript is a collection of things of how not to design a language :) What you are looking for is Golang. The level of changes you are proposing require it to go thriugh an RFC process, have 2/3rds of voters to

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks wrote: > > > On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web < > 6562...@gmail.com> wrote: > >> Hello, please discuss about error collecting implementation in next PHP >> releases >>

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web < 6562...@gmail.com> wrote: > Hello, please discuss about error collecting implementation in next PHP > releases > > Exceptions have common differences that restrict using them to collect > errors > 1. Timeloss (trace collection)

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Fri, 15 Dec 2023 at 22:32, Jordan LeDoux wrote: > On Fri, Dec 15, 2023 at 12:14 AM Robert Landers > wrote: > > > > > nobody will likely ever try this again, at least in the foreseeable > > future. With comments like that, there is simply no way forward. > > There's no convincing (at least

Re: [PHP-DEV] PHP Package for PHP

On Fri, May 19, 2023, 09:26 Mike Schinkel wrote: > > On May 18, 2023, at 1:34 PM, Rowan Tommins > wrote: > > On Thu, 18 May 2023 at 16:27, Deleu wrote: > >> Monolog is a great example of what PHP is missing - a single library > for a > >> purpose. I have never worked with any other library

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

On Fri, 12 May 2023 at 18:12, Andreas Heigl wrote: > Hey Larry, Hey all > > On 12.05.23 16:42, Larry Garfield wrote: > > On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote: > >> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka wrote: > >> > >>> Hi, > >>> > >>> The vote is now open for the RFC

Re: [PHP-DEV] [VOTE] PHP Technical Committee

On Mon, 1 May 2023 at 19:29, Jakub Zelenka wrote: > Hi, > > Thanks for the feedback. > > On Mon, May 1, 2023 at 4:09 PM Benjamin Außenhofer > wrote: > > However the main problem with the RFC process is that for purely technical > changes it could result in a set of rules that will limit core

Re: [PHP-DEV] [VOTE] PHP Technical Committee

On Mon, 1 May 2023 at 18:09, Benjamin Außenhofer wrote: > On Fri, Apr 28, 2023 at 12:01 PM Jakub Zelenka wrote: > > > Hi, > > > > The vote is now open for the RFC about introduction of the PHP Technical > > Committee: > > > > https://wiki.php.net/rfc/php_technical_committee > > > I found this

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 23:05, tag Knife wrote: > > > On Wed, 12 Apr 2023 at 20:41, Arvids Godjuks > wrote: > > >> If people want to mirror internals to GitHub and manage it all and then >> feed back the information into the list with links and feedback - >> p

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 22:07, tag Knife wrote: > On Wed, 12 Apr 2023 at 19:42, Rowan Tommins > wrote: > > > > > Which brings me back to my earlier point: I wonder how much of the > > reaction is really about e-mail itself, and how much is just the > > documentation and sign-up forms you

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 16:53, Alex Wells wrote: > Hey. > > PHP currently uses internals@lists.php.net for communication. That > includes > mostly RFCs (or their votings, or their pre-discussion) and sometimes > questions about the implementation or possible bugs. > > While emailing definitely

Re: [PHP-DEV] Future stability of PHP?

On Tue, Apr 11, 2023, 22:14 Gunnard engebreth wrote: > > On 4/11/23 3:09 PM,  Good Guy  wrote: > > On 08/04/2023 19:36, Stephan Soller wrote: > >> > >> > >> A few days ago I migrated a project from PHP 7.1 to 8.2 and the > >> amount of > >> deprecations and fatal errors spooked me a bit

Re: [PHP-DEV] Future stability of PHP?

On Tue, Apr 11, 2023, 17:18 Robert Landers wrote: > > You can add `#[AllowDynamicProperties]` to classes where you want to > allow > > dynamic properties. > > I don't think that will work in PHP 9? > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] PHP Modules

On Tue, 11 Apr 2023 at 04:41, Michael Morris wrote: > This will be long. I've read over the Future Stability thread and taken it > in, and decided to mull over an idea I touched on over a decade ago that I > think might help. Also, in the interceding years the JavaScript community > has overcome

Re: [PHP-DEV] Future stability of PHP?

On Tue, 11 Apr 2023 at 01:08, Deleu wrote: > > > On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks > wrote: > >> >> >> On Tue, 11 Apr 2023 at 00:03, Deleu wrote: >> >>> >>> >>> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks

Re: [PHP-DEV] Future stability of PHP?

On Tue, 11 Apr 2023 at 01:12, Mark Baker wrote: > On 10/04/2023 23:33, Arvids Godjuks wrote: > > > >> Yes we know, and we're very grateful; but that doesn't mean we should be > >> unquestioningly grateful! > >> > >> And some of us are also open-sour

Re: [PHP-DEV] Future stability of PHP?

On Tue, 11 Apr 2023 at 00:03, Deleu wrote: > > > On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks > wrote: > >> >> >> >>> *snip to keep the email short* >>> >>> >> Hello Deleu, I want to highlight your response specifically,

Re: [PHP-DEV] Future stability of PHP?

On Mon, 10 Apr 2023 at 23:43, Mark Baker wrote: > On 10/04/2023 19:04, Arvids Godjuks wrote: > > I also want to add that PHP is purely developed by open-source > contributor > > efforts who are limited in their numbers and not a lot of them are > getting > > compensat

Re: [PHP-DEV] Future stability of PHP?

On Mon, 10 Apr 2023 at 21:30, Deleu wrote: > On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: > > > hello, > > > > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > > > wrote: > > > > > Hello, > > > > > > I'm sorry if this isn't the correct mailing list for that discussion > but > > I > > >

Re: [PHP-DEV] Future stability of PHP?

On Mon, 10 Apr 2023 at 19:18, Pierre Joye wrote: > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > wrote: > > > Hello, > > > > I'm sorry if this isn't the correct mailing list for that discussion but > I > > couldn't find a more appropriate one where people actually know how the > >

Re: [PHP-DEV] [VOTE] include cleanup

Good day dear Internals! I've been following this thread/RFC from its inception to the current moment. I have watched the situation deteriorate and at this point, I have major concerns about the events that transpired, the motivations of some decisions and the apparent major lack of

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

On Wed, 2 Mar 2022 at 11:31, Victor Bolshov wrote: > Hello internals. > > In these dark days for humanity, we as people of civilization, people > of sanity, kind and caring people with children and families - we have > to speak up, loud and clear, in support for Ukraine. To stop Russian >

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

On Wed, 29 Dec 2021 at 17:42, Vincent Langlet wrote: > Hi, > > I recently discovered that an array was automatically casting > numeric-string keys to int if it was possible. For instance, the following > array: > > $a = ['01' => '01', '10' => '10']; > > Is not an array with the key '01' and '10'

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

On Wed, Aug 25, 2021 at 1:03 PM Nikita Popov wrote: > Hi internals, > > I'd like to propose the deprecation of "dynamic properties", that is > properties that have not been declared in the class (stdClass and > __get/__set excluded, of course): > >

Re: [PHP-DEV] PHP 8 release announcement page on php.net

Can confirm, Gmail ate the email into spam folder. On Mon, Oct 12, 2020, 10:16 Lynn wrote: > On Mon, Oct 12, 2020 at 9:57 AM Roman Pronskiy < > roman.prons...@jetbrains.com> > wrote: > > > Hello Internals, > > > > Hi, this message ended up in my spam directory with the message, could be > that

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

On Wed, 2 Sep 2020 at 18:58, Ben Ramsey wrote: > > > On Sep 2, 2020, at 11:14, Lester Caine wrote: > > > > 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

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

Hello everyone, I would like everyone to slow down a bit and give a think about this: English is not the primary language for the vast majority of people. are a thing and a lot of people, actually, work with PHP that either does not know English at all or, know the basics and rarely have the

Re: [PHP-DEV] Deprecating uniqid()

Hello Ben, On Thu, 7 May 2020 at 17:29, Ben Ramsey wrote: > > On May 7, 2020, at 09:33, Dan Ackroyd wrote: > > *snip* > > I’m done waxing philosophical, so what I can say about `uniqid()`? > > This is one of those functions I think (without doing the research) is > used a lot in CLI scripts

Re: [PHP-DEV] Deprecating uniqid()

On Tue, 5 May 2020 at 10:26, Rowan Tommins wrote: > On Tue, 5 May 2020 at 08:52, Peter Bowyer > wrote: > > > > > On Tue, 5 May 2020 at 07:38, Niklas Keller wrote: > > > >> Rowan Tommins schrieb am Mo., 4. Mai 2020, > >> 10:59: > >> > Although the name sounds similar, I don't think UUID would

Re: [PHP-DEV] Simplify classes syntax proposal

On Fri, 1 May 2020 at 16:45, Max D wrote: > Greetings, Internals! > > This is my first try to input the proposal, please don't be strict ) > > All the years with PHP I hate writing classes. The need to prefix EVERY > property and method use looks horrible and writes horrible. So, the > proposal:

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Sat, 7 Mar 2020 at 23:50, Paul M. Jones wrote: > Hi Arvids, > > > On Mar 5, 2020, at 05:19, Arvids Godjuks > wrote: > > > > one question I do have here is about how PHP-PM process manager will be > > able to interact with this layer? > > Cause right no

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Fri, 28 Feb 2020 at 16:25, Paul M. Jones wrote: > Hi everyone, > > All outstanding issues on this RFC appear to be resolved one way or > another. With that in mind: > > Are there any members here who currently expect to vote "no", who have not > yet chimed in? I'd like to hear your criticisms

Re: [PHP-DEV] [RFC] Object Initializer

чт, 12 сент. 2019 г. в 16:00, Michał Brzuchalski < michal.brzuchal...@gmail.com>: > Hi internals, > > I'd like to open discussion about RFC: Object Initializer. > > This proposal reduces boilerplate of object instantiation and properties > initialization in case of classes without required

Re: [PHP-DEV] Changing fundamental language behaviors

чт, 12 сент. 2019 г. в 16:53, Dan Ackroyd : > On Thu, 12 Sep 2019 at 15:44, Zeev Suraski wrote: > > > > The RFC process was never, ever meant to handle fundamental changes to > the > > language. > > The only appropriate response to this is "lolwat?". > > You keep making up rules...that don't

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

чт, 12 сент. 2019 г. в 16:02, Chase Peeler : > On Thu, Sep 12, 2019 at 9:55 AM Claude Pache > wrote: > > > > > > > > Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > > > > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > > > > > Marco Pivetta > > > > That violates blatantly DRY

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

чт, 12 сент. 2019 г. в 15:33, Marco Pivetta : > Hey Rowan, > > > > On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins > wrote: > > > For instance, for undefined array keys, what if we had an operator for > > "initialise and retrieve", such as $foo[? 'bar']. Then we could

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

чт, 12 сент. 2019 г. в 12:32, Benjamin Morel : > > > > For example when I’m writing a throw-away script, some notices are okay > to > > indicate possible problems > > > Maybe it's just me, but even in throw-away scripts, *I've lost much more > time because of warnings/notices going unnoticed,

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

On Mon, Sep 2, 2019, 19:02 Sara Golemon wrote: > On Thu, Aug 29, 2019 at 2:29 PM Stanislav Malyshev > wrote: > > > >> I knew it worked, but I always considered this to basically be > > >> the PHP equivalent of undefined behavior in C. And I don't think > anyone > > > > It's not. It's very well

Re: [PHP-DEV] Make error_reporting=E_ALL the default

пт, 30 авг. 2019 г. в 11:33, Nikita Popov : > Hi internals, > > Relating to the recent discussions on undefined variables & co. One thing > that is particularly annoying about the undefined variable case is that our > default error_reporting level (without a php.ini) does not include > E_NOTICE.

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Hello, as many later posters in the thread have said - a lot of notices, especially uninitialised variables, are classic technical debt. For example, I just recently fixed a bug, that did this: `$array['key'] += $cost` - the array key was not initialised. Well, turned out that in this case

Re: [PHP-DEV] Bringing Peace to the Galaxy

чт, 8 авг. 2019 г. в 22:17, Zeev Suraski : > [... and not in the Sith Lord kind of way.] > > *snip* > > Thoughts? > > Zeev > Apparently, this exists: "ezmlm-reject: fatal: Sorry, I don't accept messages larger than 3 bytes (#5.2.3)", so re-sending with Zeev's part sniped out :) Good day

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

чт, 8 авг. 2019 г. в 17:42, Chase Peeler : > > > On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks > wrote: > >> чт, 8 авг. 2019 г. в 16:42, Peter Kokot : >> >>> Hello, >>> Thanks for sharing your stories about issues. Maybe we should start >&

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

чт, 8 авг. 2019 г. в 17:56, Robert Korulczyk : > > Many people have talked about the potential impacts of keeping short > tags. > > I have yet to see anyone give an actual example where they have been > > negatively impacted by their existence. I've given you my personal story > of > > how

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

чт, 8 авг. 2019 г. в 17:57, Peter Bowyer : > > > On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks > wrote: > >> I really liked how language picked up the cleanup pace in the last few >> years and it needs it. I finally see genuine interest in people to >> actually

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

чт, 8 авг. 2019 г. в 16:42, Peter Kokot : > Hello, > Thanks for sharing your stories about issues. Maybe we should start > also thinking about the impact on the language attractiveness to pick > it when starting a new web project since the core people can't come to > conclusions how to make the

Re: [PHP-DEV] Handling of null arguments to internal functions

чт, 6 июн. 2019 г. в 10:55, Nikita Popov : > Hi internals, > > The https://wiki.php.net/rfc/consistent_type_errors RFC resolved one of > the > big differences in argument handling between internal and userland > functions. This change allowed us to add return type information (available > through

Re: [PHP-DEV] open_basedir?

Hello, as an end-user, I'd say that it should go the way of the dinosaurs as request globals and alike went - these days there are a lot of ways to do it better and way more securely. Makes it easier on everyone and removes abuse of it for security purposes. Deprecate 7.4, dump it in 8.0.

Re: [PHP-DEV] PHP Docker images

Hello Martins, The core leaves building and packaging of PHP to distros and other community efforts and focuses their efforts on PHP itself. It's a constant tug of war here on what to maintain or not by the core because whatever is taken on means it needs to happen for years and decades going

Re: [PHP-DEV] random_seed()

On Mon, Apr 1, 2019, 05:52 David Rodrigues wrote: > Just to know, can we have a random_seed() for random_int()/random_bytes() > like we have mt_srand() to mt_rand()? > > I don't know if random_int() is more "random" than mt_rand(), but if it is, > so maybe is valid a random_seed() function. > >

Re: [PHP-DEV] Re: PHP 8 Preview Releases

Hello, I'd like to add that as the userland developer, it would be nice to be able to build JIT against an active branch (a.k.a PHP 7.4), cause if PHP 8 brings enough changes, it would not be realistic to fix our apps to be compatible with PHP 8 months or years away from actual release. пт, 29

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

Hello, On the one hand - seems logical. On the other hand - makes things less clear when reading the code. With parenthesis, the code is made explicit, so you treat code like given in an example as a code smell. I'd encourage people to always use parentheses. But overall I'd say the change makes

Re: [PHP-DEV] [RFC] Saner string to number comparisons

ср, 27 февр. 2019 г. в 10:06, Kingsquare.nl - Robin Speekenbrink < ro...@kingsquare.nl>: > Op di 26 feb. 2019 om 13:27 schreef Nikita Popov : > > > Hi internals, > > > > I think it is well known that == in PHP is a pretty big footgun. It > doesn't > > have to be. I think that type juggling

Re: [PHP-DEV] [RFC] JIT

пт, 15 февр. 2019 г. в 13:05, Benjamin Eberlei : > > > On Fri, Feb 15, 2019 at 10:37 AM Dmitry Stogov wrote: > >> Just two things. >> >> I definitely don't think, I "just made it 100x more complicated". >> I hate complication, and trying to make things simpler and more >> efficient. This,

Re: [PHP-DEV] [RFC] JIT

чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas : > > [...] I think that whether or not we include it in 7.4 > > is a tactical decision (and I'm not sure myself where I stand on it), > but I > > do think there's a reasonable case for both directions. > > > > If I may add some voice to Zeev's

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

сб, 2 февр. 2019 г. в 18:24, Nikita Popov : > Hi internals, > > After discussing the topic with a number of current and former > contributors, I feel that the workflow & voting RFC currently under > discussion is moving us in the wrong direction. I will not comment on the > rather questionable

Re: [PHP-DEV] Deprecation ideas for PHP 8

ср, 23 янв. 2019 г. в 12:04, Jani Ollikainen : > Hi, > > The arguments why to deprecate didn't seem much more than, this maybe > could be deprecated. I think there should usually be some > benefits of deprecating, otherwise why not just leave it as it is? > > But some comments that I didn't

Re: [PHP-DEV] Idea for better function callbacks (another syntactic sugar)

пт, 26 окт. 2018 г. в 18:57, Kalle Sommer Nielsen : > Den fre. 26. okt. 2018 kl. 17.43 skrev Larry Garfield < > la...@garfieldtech.com>: > > I believe the proposal for short lambas (which should get resurrected at > some > > point) would handle this case well enough as well as help a dozen other

Re: [PHP-DEV] News and mailing lists were down. Up again?

Seems to work, got this thread from internals :) On Wed, Aug 29, 2018, 18:08 Rasmus Lerdorf wrote: > On Tue, Aug 28, 2018 at 2:52 AM, Jan Ehrhardt wrote: > > > https://bugs.php.net/bug.php?id=76743 > > > > Are we back? > > > > Hopefully. Watching it closely today. >

Re: [PHP-DEV] [RFC] Optional typehint check for parameters

пн, 16 июл. 2018 г. в 14:14, Zeljko Mitic : > > > On Mon, Jul 16, 2018 at 1:06 PM Arvids Godjuks > wrote: > >> пн, 16 июл. 2018 г. в 13:56, Zeljko Mitic : >> >>> I tried to, but I honestly can't see the problem. No decent programmer >>> m

Re: [PHP-DEV] [RFC] Optional typehint check for parameters

пн, 16 июл. 2018 г. в 13:56, Zeljko Mitic : > I tried to, but I honestly can't see the problem. No decent programmer > makes error by sending wrong type of parameter and this feature is 100% > optional. I know for sure that even in my dev computer, I would use this > feature, and probably most

Re: [PHP-DEV] [RFC] Optional typehint check for parameters

On Sun, Jul 15, 2018, 22:45 Zeljko Mitic wrote: > PHP is dynamic language and each typed typehinted parameter has to be > checked every time. I am suggesting new php.ini value "typecheck.enable = > 1" which can be turned off. > > Example: > with default php config, a code like this would check

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

2018-05-11 17:19 GMT+02:00 Alice Wonder <al...@librelamp.com>: > On 05/11/2018 05:34 AM, Alice Wonder wrote: > >> On 05/11/2018 05:10 AM, Alice Wonder wrote: >> >>> On 05/11/2018 03:50 AM, Arvids Godjuks wrote: >>> >>>> 2018-0

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

2018-05-11 12:36 GMT+02:00 Alice Wonder <al...@librelamp.com>: > On 05/11/2018 01:59 AM, Arvids Godjuks wrote: > >> 2018-05-10 16:33 GMT+02:00 Niklas Keller <m...@kelunik.com>: >> >> Hey, >>> >>> I hereby propose to deprecate uniqid().

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

2018-05-10 16:33 GMT+02:00 Niklas Keller : > Hey, > > I hereby propose to deprecate uniqid(). There have been attempts to fix it > ( > https://wiki.php.net/rfc/uniqid), but those were rejected during > discussion, because there's no possible fix without breaking BC. Instead of >

Re: [PHP-DEV] PHP FFI extenesion

2018-04-13 16:27 GMT+03:00 Dmitry Stogov : > Hi, > > > I've spent some time thinking about simple FFI for PHP, and finally, > borrowed most ideas from LuaJIT. > > This is an initial PoC. It was tested on Linux only. > > > https://github.com/dstogov/php-ffi > > > I would

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

2017-09-15 20:52 GMT+03:00 Ryan Pallas : > On Fri, Sep 15, 2017 at 11:38 AM, wrote: > > > Hi Ryan > > > > I can see your argument. The reasoning behind it is that a function in > the > > standard library should not encourage unsafe code. Admittedly,

Re: [PHP-DEV] [VOTE] UUID

I'd seriously start considering to start doing PHP code for things like these, so they are not bogged down by the fact that they are in C and there is 0.5 devs interested in supporting it. On Wed, 6 Sep 2017, 14:09 Dan Ackroyd wrote: > On 5 September 2017 at 18:24,

Re: [PHP-DEV] [VOTE] UUID

2017-09-04 19:03 GMT+03:00 Sammy Kaye Powers : > I really, really wanted to vote yes for this as I've wanted simple > UUID creation in core for a long time, but I can't agree this is the > correct implementation. Something like "uuid_v4_create()" seems to > make a lot more

Re: [PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects

2017-01-10 22:11 GMT+02:00 Davey Shafik : > On Mon, Jan 9, 2017 at 10:43 AM, Paul Jones wrote: > > > > > > On Jan 7, 2017, at 15:41, Joe Watkins wrote: > > > > > > That doesn't sound like a positive consensus that this is a good idea, >

Re: [PHP-DEV] Modern practices ...

Hello, For myself I have adopted the "vagrant vm per project" workflow. I never mix projects, because while some are "primitive" and do not require anything beyond a standard install, others have a custom provisioning and setup stuff. And specific options on the software that can interfere with

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 15:46 GMT+03:00 Niklas Keller <m...@kelunik.com>: > 2016-09-09 13:18 GMT+02:00 Arvids Godjuks <arvids.godj...@gmail.com>: > >> >> >> 2016-09-09 13:37 GMT+03:00 Niklas Keller <m...@kelunik.com>: >> >>> 2016-09-09 10:36 GMT+02:00

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 13:37 GMT+03:00 Niklas Keller <m...@kelunik.com>: > 2016-09-09 10:36 GMT+02:00 Arvids Godjuks <arvids.godj...@gmail.com>: > >> 2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki <yohg...@ohgaki.net>: >> >>> On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki : > On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller wrote: > > I think it's better to leave it as is and deprecate and discourage its > use. > > There's already a big warning there. Dunno whether there are really valid >

Re: [PHP-DEV] Suggestion

As was said, this was debated a lot. Both sides had valid arguments, but this should not be taken lightly just because there is no "BC break". There is such thing as too much syntactic sugar, and PHP is one of those, rare these days, languages that keep options of doing the same thing low. On

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Yasuo! 2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki <yohg...@ohgaki.net>: > Hi Arvids, > > On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks > <arvids.godj...@gmail.com> wrote: > > i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on > by > &

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi internals, i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by default and having any INI settings that affect how engine processes data in runtime. People just don't learn until they shotgun themselves I guess. What I personally would be for, is a CSRF aPI module that

Re: [PHP-DEV] [RFC] Pipe Operator

I like the proposal, but readability should be on the forefront of things that need to be done right. Yes, there are people that will make it an unreadable mess, but we have code reformat, so if the syntax is verbose enought to be read at a glance, I'm all for it. +1 as long as syntax gets a hard

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

On Mon, 25 Apr 2016, 21:07 S.A.N, wrote: > 2016-04-25 20:56 GMT+03:00 Rowan Collins : > > S.A.N wrote on 25/04/2016 18:49: > >>> > >>> There's not really a huge connection between opcode caching and > >>> optimization > >>> >(OpCache) and shared

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

2016-03-11 12:03 GMT+02:00 Jakub Kubíček : > From the RFC: > > > > var is therefore a limited subset of public. > > > No, this is wrong. `var` was here much much longer than `public`, therefore > `var` is not a subset of public, but rather `public` is _an extension_ of >

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

On Thu, 10 Mar 2016, 12:29 Tony Marston, wrote: > "James Titcumb" wrote in message > news:CAKnqCEZMh-P8XmAeQtdPnw4ZaZGb4=wmm_9qyzphtupuwax...@mail.gmail.com... > > > >> > >> need to have their competence, professionalism, and intelligence > >> questioned. > > > >Tony,

Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types

. Arvids Godjuks. On Wed, 9 Mar 2016, 15:24 Pierrick Charron, <pierr...@adoy.net> wrote: > On 9 March 2016 at 08:08, Marco Pivetta <ocram...@gmail.com> wrote: > > > On 9 March 2016 at 14:03, Pierrick Charron <pierr...@adoy.net> wrote: > > > >> Hi D

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

All languages are evolving, and part of that is removing old baggage, even if that baggage is harmful. Because ease of maintenance. When you have multiple ways to do a thing, that means that when you touch some part of it, you have to remember to update everything else. It's easy with

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

ut deprecate it > by doc in 7.1, deprecate(Raise error) it in 7.2, then remove it by > 7.3? > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > Hello, As a user-land developer I approve this message (with correction from Pierre that final removal should be in PHP 8 and keep it deprecated in PHP 7.1 by docs, 7.2 with a error message). Regards, Arvids Godjuks, Areto Development.

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

2016-01-19 20:03 GMT+02:00 Arvids Godjuks <arvids.godj...@gmail.com>: > Hello to everyone. > > The Draft states: > > "This Code of Conduct applies both within project spaces and in public > spaces when an individual is representing the project or its community.&

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

Hello to everyone. The Draft states: "This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community." TL;DR: Just no. Long version: What is the definition of "representing project or it's community". If I make a

Re: [PHP-DEV] Re: PHP 5.6 life cycle

2015-12-07 17:11 GMT+02:00 Zeev Suraski : > > -Original Message- > > From: Rowan Collins [mailto:rowan.coll...@gmail.com] > > Sent: Monday, December 07, 2015 4:42 PM > > To: internals@lists.php.net > > Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycle > > > > Rowan Collins

Re: [PHP-DEV] PHP 5.6 life cycle

Hello internals, In my opinion, right now what dictates the timeframes is Release Process RFC: https://wiki.php.net/rfc/releaseprocess It clearly states the rules of how things are done. If dates for the PHP 5.6 are to be adjusted, than it requires an RFC process and should be an exception, not

Re: [PHP-DEV] taint

I fully support your effort to get this into the PHP to be part of core extensions, or at least one of those that keep up with the language releases. This is a very good tool to have, and you can actually run it in production to catch things that may slipped the stating (things happen). And it's

Re: [PHP-DEV] Re: Adding numeric type hint

пн, 11 Май 2015, 10:21, Yasuo Ohgaki yohg...@ohgaki.net: Hi all, I've never wrote my blog in English, but I wrote one because peice by piece discussion is not going to anywhere. http://blog.ohgaki.net/dont-use-php7-type-hint-for-external-data How many of you think current scalar type hint is

  1   2   3   4   >