Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

Ok, sorry for the buzz, have to re-read it then to catch up. 2010/12/3 la...@garfieldtech.com : > On 12/3/10 7:12 AM, Arvids Godjuks wrote: > >> I'm sorry if in last 10-15 emails there was any change to better >> understanding the PHP, I just didn't follow any more.

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Definitely a -1 for making read only. I kind'a like to apply filters to POST directly when validating forms so I clean up the user mess in it and if he makes a mistake in a form, to show him a cleaned up input. Also this is useful in other ways. Mixed feelings on other parts. From one point of vie

Re: [PHP-DEV] Re: Clarification on the Enum language structure

Hello! I should comment on why people want strings as enum values - just look at ENUM type in MySQL. People use it, and if you take a look from that perspective - it makes sense. But we are not a MySQL only world, so it does not make sense to do strings, because in other databases usually 1 byte

Re: [PHP-DEV] [RFC] Return type-hint

There was no consensus on that, but as i remember the tendency was more to the weak type hinting because of dynamic nature of PHP. You know - all the http data comes as strings, most db data comes as strings and so on. 27.04.2011 11:30 пользователь "Pas" написал: > On Wed, Apr 27, 2011 at 09:23, F

Re: [PHP-DEV] 5.4 again

Hello Internals! Here is a point of view from an active user land developer on PHP development and feature requests and the politics going on in internals. Right now I think PHP has reached a milestone, where it is a need to take a break from large feature developing, witch takes a lot of time an

Re: [PHP-DEV] 5.4 again

2011/5/10 Ferenc Kovacs : > > >> >> The Tainted Variable RFC - https://wiki.php.net/rfc/taint - personally >> I would prefer that feature right now over any new feature, because it >> gives the ability to check for insecure variable handling and make >> sure you don't miss something. A major securi

Re: [PHP-DEV] 5.4 again

Well, maybe it's time to make some decisions and start to spin the wheels? I's quite obvious that annotations are out for next release until they are a docbook/phpDoc style. Personally I do not understand the concept fully, but my vote will definetly go to the docbook/phpdoc variant. Adding a whol

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

Hello. As a userland developer i'm all for it. Remove short_tags and decouple : > So what would be there to discuss or agree on?, now that the topic is at > hand. > > Regards, > > David > > On Wed, May 18, 2011 at 9:05 PM, Stas Malyshev wrote: > >> Hi! >> >> >>  As far as I remember there weren't

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

ople really use <% ? 2011/5/19 Ferenc Kovacs : > > > On Thu, May 19, 2011 at 8:53 AM, Arvids Godjuks > wrote: >> >> Hello. >> >> As a userland developer i'm all for it. Remove short_tags and decouple >> > > > I think that it's a little

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Holly crap, god save us from that. +1 on short syntax (personally I try to avoid it in JS too - I use new Array() or JSON), but no : please. It's just ridiculous for PHP. 2011/6/1 Patrick ALLAERT : > 2011/5/31 Brian Moon : >> https://wiki.php.net/rfc/shortsyntaxforarrays >> >> Since this was brou

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

My personal feel about this is that yes, short arrays are not bad, but things like $a = new A; $a[array()]; just scare the crap of me when I see them. To me PHP is easy on syntax and it's good. When I see Ruby or Python code with all it's crazy magic I feel sick. Still one day I will have to lear

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

2011/6/2 Ford, Mike : >> -Original Message- >> From: John Crenshaw [mailto:johncrens...@priacta.com] >> Sent: 01 June 2011 23:00 >> > skip > >> 4. The format most consistent with other languages is JSON > > Again, matter of experience. Last time I counted, I'd used upward of > 30 different

Re: [PHP-DEV] [PATCH] Notice on array to string convertion

+1 on E_NOTICE 02.06.2011 19:13 пользователь "Ilia Alshanetsky" написал: > I like the idea of an error message when this happens, but as few > other people in the thread had mentioned, I think it should be a > warning (E_WARNING) because the conversion results in data loss > (content of the array

Re: [PHP-DEV] 5.4 moving forward

Hello. A PHP developers view on windows installation: it's screwed as hell right now. I use apache + php for my developing envoirment on Windows 7. Guys - I spend 1.5, freaking 1.5 hours setting up apache + php!!! essentially i just had to download and try multiple binaries for windows to find the

Re: [PHP-DEV] [VOTE] voting rfc

That really neads clearing, because if i understand correctly, I should get ability to vote (userland developer activly reading the list and writing to list on some maters). So the question - do i get a vote ability? :-) 21.06.2011 17:36 пользователь "Philip Olson" написал: > > > On Jun 20, 2011,

Re: RE: [PHP-DEV] foreach() for strings

As a userland developer due to my geographical nature i have to work with 3 languages constantly - english, russian (cyryllic) and latvian (witch has it's own share of non latin characters). I end up using utf-8 in every project. And some give me a headake of dealing with text parsing. mb_string co

Re: [PHP-DEV] [PATCH] getimagesize - return named keys for width, height, type and attributes

This one is quite positive, I'm all +1 on this as a user land developer. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Magic Quotes in PHP, the Finalle

Hello. I have only one question - is really that many old applications able to run on 5.3 who require magic_quotes, safe mode, register globals and other legacy stuff? How long are you planing on keeping the BC? 10 years, 15 years? Maybe 20? Reality is - break it in 5.4 or in 6.0 in two-three years

Re: [PHP-DEV] An implementation of a short syntax for closures

2011/8/4 Lazare Inepologlou : > Hello everyone. > > I am new to the php-internals list. I have joined because I have > implemented a feature that I would like to be included in the php > language: a shorter syntax for lambdas. I am going to briefly present > it here. Apologies for the long (and yet

Re: [PHP-DEV] An implementation of a short syntax for closures

Oh, and I forgot one more thing: As I read the internals, I noticed many times that PHP lexer is somewhat limited in it's capabilities and sometimes the features are dropped because of this issue. It can be the case that the can be ambiguous and it will be just impossible to add at this stage. As

Re: [PHP-DEV] [VOTE] Weak References

I have mixed feelings about this proposal - from one point it's quite neat - ability to mark circular references for the memory manager so it can free them sounds very delicious, especially for some cases. I had run into my own bunch of problems with memory in PHP in the past and right now I'm runn

Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default

Just add a check on what format is used on read, write with the new format. Deprecate the old format in next version after 5.4 (or drop it at all in 6.0 or whatever the new major version will be). Make a noise about the change (I can do that for the Russian speaking community with ease). It will b

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 in

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 th

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 wrote on 07/12/2015

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 sin

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

2016-01-19 20:03 GMT+02:00 Arvids Godjuks : > 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.

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

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 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 functions/met

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

is a good idea. Arvids Godjuks. On Wed, 9 Mar 2016, 15:24 Pierrick Charron, wrote: > On 9 March 2016 at 08:08, Marco Pivetta wrote: > > > On 9 March 2016 at 14:03, Pierrick Charron wrote: > > > >> Hi Derick > >> > >> I agree that most of the t

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, making a statement like thi

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 > `var`. The keyword `var` i

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 memory data caches (APCu, memcached, etc), so I > >

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] [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 c

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

Hi Yasuo! 2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki : > Hi Arvids, > > On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks > wrote: > > 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 affec

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 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, because

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

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] 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, 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: https://www.p

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 (detail

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 wor

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 encounte

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] [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 id

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 dev

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] 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 besi

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 via

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) o

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

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 agree

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 c

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 proposed i

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: [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 \CurlHandle

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 on

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 be

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 > thei

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 knowled

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 tom

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] 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 people

Re: [PHP-DEV] PDO subclass names

On Tue, 30 Apr 2024 at 12:07, Matteo Beccati wrote: > Hi, > > > > If MariaDB wants to maintain a specific PDO Driver they can do so > > themselves and publish it on PECL, same as how CUBRID (and others) does > > currently. > > That is true, however it's mysqlnd the part that deals with the networ

[PHP-DEV] Proposal to Create a MariaDB Alias for the MySQL PDO Driver

Hello, I'm splitting this discussion from https://externals.io/message/123183, see details at https://externals.io/message/123183#123234 and https://externals.io/message/123183#123236 to keep the original thread clean. There's a clear divergence in functionality between MySQL and MariaDB. As PDO

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

On Tue, 30 Apr 2024 at 09:19, Rowan Tommins [IMSoP] wrote: > > > On 28 April 2024 07:47:40 GMT-07:00, Robert Landers < > landers.rob...@gmail.com> wrote: > > >I'm not so sure this could be implemented as an extension, there just > >isn't the right hooks for it. > > The whole point of my email was

[PHP-DEV] Re: Proposal to Create a MariaDB Alias for the MySQL PDO Driver

On Tue, 30 Apr 2024 at 21:32, Matteo Beccati wrote: > Hi Arvids, > > > > It's not clear to me what divergences need to be addressed at the PDO > level at this point. Could you please shed some light? > > Is it just identification? If so, I think the best place to do it is > some user-land config

Re: [PHP-DEV] [RFC] [Vote] #[\Deprecated] attribute

On Wed, 22 May 2024 at 11:01, Pierre wrote: > Le 22/05/2024 à 09:33, Nicolas Grekas a écrit : > > Hi Benjamin, > > The vote for the RFC #[\Deprecated] attribute is now open: >> >> https://wiki.php.net/rfc/deprecated_attribute >> >> Voting will close on Wednesday 5th June, 08:00 GMT. >> > > I vote

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Wed, 5 Jun 2024 at 19:59, Claude Pache wrote: > *snip* > Hi Larry and Ilija, > > Thanks for your work. Here is my opinion: > > First, I do think that `readonly` should integrate with aviz, unless that > implies truly controversial changes on `readonly`. As Theodore Brown > commented in the pre

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, 7 Jun 2024 at 17:30, Larry Garfield wrote: > On Wed, Jun 5, 2024, at 7:55 PM, Arvids Godjuks wrote: > > On Wed, 5 Jun 2024 at 19:59, Claude Pache > wrote: > > *snip* > > Hello everyone, > > I've been seeing readonly bashed/blamed/being roadblock, et

Re: [PHP-DEV] [Early Feedback] Pattern matching

On Wed, 26 Jun 2024 at 11:00, Rob Landers wrote: > > > On Wed, Jun 26, 2024, at 09:54, Rob Landers wrote: > > > > On Wed, Jun 26, 2024, at 00:19, Morgan wrote: > > On 2024-06-26 08:24, Rob Landers wrote: > > On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote: > > >> If null array values were inde

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

On Sun, 30 Jun 2024 at 23:30, Michael Morris wrote: > So let's take another crack at this based on all the points raised in the > thread. This should also underline why I don't consider this an RFC - I am > iterating until we arrive at something that may be refinable into an RFC. > And I say we b

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

On Mon, 1 Jul 2024 at 19:22, Mike Schinkel wrote: > > On Jul 1, 2024, at 7:57 AM, Arvids Godjuks > wrote: > > > > TL;DR: As a userland developer, in my opinion, this is just a downgrade > from what we have now. Enhance namespaces to have the ability to have &g

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

Q On Sun, Jul 7, 2024, 03:03 Michael Morris wrote: > > > >> >> ... >> Many (most?) people on PHP Internals view WordPress coding standards as >> bad and some even view addressing WordPress developers needs as bad for >> PHP >> > > I really don't want to get into that crossfire. WordPress i

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 argument

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, sometim

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 compari

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] 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] 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] 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 forw

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. Implem

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] [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 la

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 г. в 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 removin

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] 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 ever

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 instea

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

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 d

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, than

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 г. в 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 (tw

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 exis

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 constru

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: 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

<    1   2   3   4   >