Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3

> On Apr 25, 2024, at 5:47 PM, Rowan Tommins [IMSoP] > wrote: > I think you missed the context of that sentence - or I'm missing something in > yours. I meant specifically that the "deprecated since" information is > useless if there's no published policy on how long something will stay >

Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3

> On Apr 25, 2024, at 11:28 AM, Rowan Tommins [IMSoP] > wrote: > If the project has no clear deprecation policy, the information is useless > anyway. Not true. Having standardized notation for deprecation would allow tooling to analyze a codebase and determine if it contains deprecated code

Re: [PHP-DEV] [RFC][Discussion] Why can constructors violate LSP?

> On Nov 23, 2023, at 4:50 PM, Robert Landers wrote: > > On Thu, Nov 23, 2023 at 10:30 PM Deleu wrote: >> >> Constructors are an implementation detail of a specialized class and as such >> they're not subject to LSP because the goal of LSP is to be able to make >> sure that any object of a

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

> > On Nov 21, 2023 at 11:33 PM, mailto:george.bany...@gmail.com)> > wrote: > > > > What is the point of a major release if we cannot even do such a BC break? > We don't even know when PHP 9.0 is going to happen yet. > > I have been using Go for about four years

Re: [PHP-DEV] RFC Proposal - static modifier for classes

Wow. This thread has gone from zero-to-toxic in no time flat, and with some participants being borderline condescending. It is almost as if some folk are still in kindergarten. Maybe try a different approach, from both sides of this debate? For the advocates, how about explaining the

Re: [PHP-DEV] Basic Type Alias

> On Oct 26, 2023, at 3:23 PM, Larry Garfield wrote: > > App-wide aliases run into the autoloading problem. If the engine runs across > the add() function above, and "numeric" isn't defined, what can it do? > Currently, all it can do is trigger autoloading, which only works for > class-ish

Re: [PHP-DEV] RFC [Concept] - Interface Properties

With "Interface Default Methods" potentially becoming a thing, it begs the question for the need to have Interface Properties, at least `private` ones and `private static` ones. How can we have default getters and default setters in an interface if there are no private interface properties to

Re: [PHP-DEV] PHP Package for PHP

> 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 besides Monolog and I >> never worked on any project which didn't

Re: [PHP-DEV] PHP Package for PHP

> On May 18, 2023, at 10:27 AM, Rowan Tommins wrote: > > On the one hand, PEAR was a single "baseline" that everyone expected; on > the other hand, packages tended to be slow to adapt to new needs and > fashions, and inflexible to different environments. So instead, people > moved to: > > -

Re: [PHP-DEV] 'Uninitialized' creates a lot of cluttering

> On Feb 8, 2023, at 9:22 AM, Lydia de Jongh wrote: > > Hi, > > After posting this in the issues list > , I was asked to mail it here. > This is my first time here, so I hope I do it the right way. > > --- > > At last

Re: [PHP-DEV] Re: [RFC] Unicode Text Processing

> > On Dec 17, 2022 at 10:20 PM, (mailto:voris...@fjfi.cvut.cz)> wrote: > > > > I also suggest `substring` instead of ugly (IMHO) `subString`. - in PHP, we > have substring() function, not sub_string() - in C#, there in Substring() > method, not SubString()

Re: [PHP-DEV] [VOTE] Improve unserialize() error handling

Larry, > On Oct 17, 2022, at 6:01 PM, Larry Garfield wrote: > > On Mon, Oct 17, 2022, at 12:33 PM, Tim Düsterhus wrote: > Okay, now the Exception message changed. Personally I do not consider this a BC break: I believe Exception messages are meant for human consumption, not for

Re: [PHP-DEV] Experimental features

> On Oct 11, 2022, at 8:24 AM, Christian Schneider > wrote: > > We seem to have two different views on experimental feature here: You are > saying they could get removed again while others stated it is for stuff which > will definitely end up in stable when the next major release is done. >

Re: [PHP-DEV] Experimental features

> On Oct 10, 2022, at 6:20 PM, David Gebler wrote: > > My two cents... > > Why can't "common users" install a PECL extension? It's not a difficult, > obscure or undocumented process. A lot of developers (most?) who build PHP applications run them in shared-hosted or managed hosted servers

Re: [PHP-DEV] [RFC] Asymmetric visibility

> On Aug 11, 2022, at 7:38 PM, André Hänsel wrote: > > Nicolas Grekas wrote: > >> But I'm also wondering about the use case where asymmetry would be >> useful in practice now that we have readonly? >> I voted against readonly at the time because it didn't address >> cloning, and also because

Re: [PHP-DEV] [RFC] Asymmetric visibility

> On Aug 5, 2022, at 1:08 PM, Larry Garfield wrote: > > Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: > Asymmetric Visibility. > > https://wiki.php.net/rfc/asymmetric-visibility Conceptually, I believe this would add useful capabilities to PHP that are impossible

Re: [PHP-DEV] [RFC] [VOTE] Constants in traits

> On Jul 5, 2022, at 5:38 PM, shinji igarashi wrote: > > Hello internals, > > I've started the vote for the Constants in Traits RFC: > https://wiki.php.net/rfc/constants_in_traits > > The vote will end on 19. July 2022. > > Thanks! > > -- > Shinji Igarashi The reaction to this RFC has been

Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3

> On Jun 13, 2022, at 1:39 PM, Rowan Tommins wrote: > > On 13/06/2022 14:52, Larry Garfield wrote: >>> That's one perspective. The other perspective is that the proposal is to >>> extend closure syntax to support automatic capture. >> As noted before, this is a distinction without a

[PHP-DEV] Constraints vs. values as types?

Hi PHPers, As I have been following the discussion about the need for a "true" type to allow documenting that a function should only be able to return true vs. bool which would allow false, and in the past the same argument for false vs. true, it occurs to me that there is another approach to

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

> On Mar 14, 2022, at 3:20 PM, Lynn wrote: > > On Mon, Mar 14, 2022 at 8:04 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote: > > Variable variables provide functionality[1] that if removed would force major > rewrites of PHP applications that were archit

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

> On Mar 12, 2022, at 5:44 AM, Lynn wrote: > > Variable variables should be removed from PHP asap. It's 2022 and I still > encounter bugs due to this "working" in legacy applications. > On Mar 12, 2022, at 5:48 AM, Kamil Tekiela wrote: > > +1 on removing variable variables as soon as

Re: [PHP-DEV] RFC: Trait expects interface

> On Jan 7, 2022, at 1:56 PM, Rowan Tommins wrote: > > On 07/01/2022 13:47, Robert Korulczyk wrote: >> I'm not really sure why would you not want this - what is the point of >> marking method as interface implementation, if it is not reflected by type >> system in actual execution? > > >

Re: [PHP-DEV] Function list declaration syntax?

> On Oct 5, 2021, at 3:18 PM, Dan Ackroyd wrote: > > On Tue, 5 Oct 2021 at 18:47, Mike Schinkel wrote: > >> Consider the `Type` class[3] in the `SebastianBergmann\Type` namespace. It >> contains 60 lines of function declaration to define 14 functions that all >

[PHP-DEV] Function list declaration syntax?

Hi all, This email proposes a shorthand syntax for declaring a list of single-expression functions. A similar albeit more verbose attempt to provide short functions[1] failed late last year, but I was recently inspired by Sebastian Bergmann's Type library[2] that he referenced in a comment

Re: [PHP-DEV] [RFC] Allow null as standalone type

> On Oct 2, 2021, at 11:06 AM, G. P. B. wrote: > > Hello internals, > > I'm proposing a new RFC to make 'null' usable as a standalone type. > > RFC: https://wiki.php.net/rfc/null-standalone-type Regarding the RFC's proposed disallowing of `?null`, is that really needed? Obviously it doesn't

Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?

> On Sep 25, 2021, at 12:03 PM, Marco Pivetta wrote: > > Hey Tyson, > > On Sat, 25 Sep 2021, 18:00 tyson andre, wrote: > >> My original message had a section with reasons why an end user might want >> that. >> > > Yeh, it sounds like stuff we wanna get away from  Point of order here: "we"

Re: [PHP-DEV] Adding `final class Deque` to PHP

> On Sep 21, 2021, at 1:12 PM, Pierre Joye wrote: > On Tue, Sep 21, 2021, 11:56 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote: > > On Sep 21, 2021, at 3:45 AM, Pierre Joye > <mailto:pierre@gmail.com>> wrote: > > > > On Tue, Sep 21

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

> On Sep 19, 2021, at 8:55 AM, tyson andre wrote: > > Hi Mike Schinkel, >> >> Hmm. I must have missed that thread as I was definitely following the list >> at that time. >> >> But I found the thread, which only had three (3) comments from others: >

Re: [PHP-DEV] Adding `final class Deque` to PHP

> On Sep 21, 2021, at 3:45 AM, Pierre Joye wrote: > > On Tue, Sep 21, 2021 at 11:21 AM Mike Schinkel wrote: > >> Honestly, at first I confused `Deque` with `Dequeue` and was wondering why >> we would name a class with a verb? It wasn't until Rowan's comment th

Re: [PHP-DEV] Adding `final class Deque` to PHP

> On Sep 19, 2021, at 8:03 PM, tyson andre wrote: > > Hi internals, > > I've created a new RFC https://wiki.php.net/rfc/deque to add a `final class > Deque` > > This is based on the `Teds\Deque` implementation I've worked on > for the https://github.com/TysonAndre/pecl-teds PECL. With one

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

Hi Tyson, Thanks for the reply. > On Sep 18, 2021, at 7:26 PM, tyson andre wrote: > > Hi Mike Schinkel, > >> Given there seems to be a lot of concern about the approach the RFC proposes >> would it not address the concerns about memory usage and performance if >&

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

Hi Larry, > On Sep 18, 2021, at 12:03 PM, Larry Garfield wrote: > > Rather than go point by point, I'm going to respond globally here. > > I am frequently on-record hating on PHP arrays, and stating that I want > something better. The problems with PHP arrays include: > > 1. They're badly

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

> On Sep 16, 2021, at 10:09 PM, tyson andre wrote: > > Hi internals, > > I've created a new RFC https://wiki.php.net/rfc/vector proposing to add > `final class Vector` to PHP. > > PHP's native `array` type is rare among programming language in that it is > used as an associative map of

Re: [PHP-DEV] Class static initialization block

> On Sep 13, 2021, at 12:26 PM, Rowan Tommins wrote: > >> 2.) Make the initialization function private. > > I'm not sure how that would work: a private constructor means that it has to > be explicitly called from within the same class, but a static initialiser > would be called by the engine,

Re: [PHP-DEV] Class static initialization block

> On Sep 11, 2021, at 7:35 PM, Marco Pivetta wrote: > > On Sun, 12 Sep 2021, 01:28 David Rodrigues, wrote: > >> Hello! >> >> I would like to suggest a feature I saw being implemented in the V8 9.4 >> engine called "*class static initialization block*". >> >> https://v8.dev/blog/v8-release-94

Re: [PHP-DEV] [RFC] $this return type

> On Sep 9, 2021, at 10:26 AM, Flávio Heleno wrote: > > On Tue, Sep 7, 2021 at 10:27 AM Sebastian Bergmann > wrote: > >> Am 07.09.2021 um 12:28 schrieb Nikita Popov: >>> I have some reservations about this (which basically come down to $this >> not >>> being a proper "type", so should it be in

Re: [PHP-DEV] Alias stdClass to DynamicObject?

> On Sep 8, 2021, at 4:59 PM, Rowan Tommins wrote: >> I assume we would also disallow dynamic properties in anonymous classes too, >> right? After all, they are just statically declared classes that the >> developer do not assign a name. > > The difference I see is that stdClass/DynamicObject

Re: [PHP-DEV] Alias stdClass to DynamicObject?

> On Sep 8, 2021, at 5:44 AM, Rowan Tommins wrote: >> Is it just a special-cases that will cause as much confusion for developers >> trying to understand why there are too names for the same thing as it will >> help those who will better understand the new name > > That is certainly a risk,

Re: [PHP-DEV] Alias stdClass to DynamicObject?

> On Sep 6, 2021, at 11:28 AM, Nikita Popov wrote: > > Hi internals, > > In the thread for deprecation of dynamic properties, Rowan suggested that > we alias "stdClass" to "DynamicObject" in > https://externals.io/message/115800#115802. I wanted to split this > discussion off into a separate

Re: [PHP-DEV] Make namespace part of runtime

> On Aug 28, 2021, at 5:12 PM, Olle Härstedt wrote: > > 2021-08-27 23:07 GMT+02:00, Rowan Tommins >: >> On 27/08/2021 20:47, Olle Härstedt wrote: >>> As a followup for my previous post, I think this could be a good place >>> to start to enable attribute writers

Re: [PHP-DEV] Make namespace part of runtime

> On Aug 27, 2021, at 5:07 PM, Rowan Tommins wrote: > > On 27/08/2021 20:47, Olle Härstedt wrote: >> As a followup for my previous post, I think this could be a good place >> to start to enable attribute writers to create encapsulation mechanics >> for composition, like namespace visibility,

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

> On Aug 26, 2021, at 11:02 PM, Pierre Joye wrote: > I don't know how others feel about it, I think most want to go the > path to (2) and a more strict, if not almost fully strict PHP. Core > devs to simplify the engine, users to allow them easier checks and > safety in their frameworks or libs.

Re: [PHP-DEV] Alternatives for encapsulation when using composition instead of inheritance

> On Aug 26, 2021, at 9:47 AM, Olle Härstedt wrote: > > Don't know if this already exists, but maybe we could consider > brainstorming or gather alternatives for different types of > encapsulation when using composition? Currently, encapsulation like > private and protected is only possible when

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

> On Aug 26, 2021, at 4:04 AM, Reindl Harald (privat) wrote: > Am 26.08.21 um 09:24 schrieb Mike Schinkel: >> https://3v4l.org/HAkhjW#v8.0.9 >> Total execution time for 5000 iterations for BadActor = 0.351906 milliseconds >> Total execution time for 5000 iterations

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

> On Aug 26, 2021, at 2:27 AM, Reindl Harald (privat) wrote: > Am 26.08.21 um 00:59 schrieb Mike Schinkel: >>> On Aug 25, 2021, at 6:41 PM, Reindl Harald (privat) >>> wrote: >>> Am 26.08.21 um 00:37 schrieb Mike Schinkel: >>>> That said, I'd be reall

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

> On Aug 25, 2021, at 6:41 PM, Reindl Harald (privat) wrote: > Am 26.08.21 um 00:37 schrieb Mike Schinkel: >> That said, I'd be really interested in seeing use-cases where having dynamic >> properties is essential to an architecture and where it could not be easily >&g

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

> On Aug 25, 2021, at 10:04 AM, Chase Peeler wrote: > > On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins > wrote: > >> On 25/08/2021 13:45, Nikita Popov wrote: >> >>> We obviously need to keep support for dynamic properties on stdClass, >>> and if we do so, I would expect that to apply to

Re: [PHP-DEV] [RFC] Never For Argument Types

> On Aug 15, 2021, at 7:06 PM, Alexandru Pătrănescu wrote: > > If I see an interface that was created just so it can be implemented by > multiple classes but the caller doesn't use the interface but it uses the > actual classes, I call it out as that is the wrong abstraction and the > interface

Re: [PHP-DEV] [RFC] Never For Argument Types

> On Aug 14, 2021, at 10:40 AM, Jordan LeDoux wrote: > > Never is treated as the bottom type for the purpose of Liskov substitution > already with its use as a return type. The exception to this in its use as > a return type is that it isn't treated as the union identity in the return > type.

Re: [PHP-DEV] Revisiting Userland Operator Overloads

> On Aug 11, 2021, at 5:25 AM, Jordan LeDoux wrote: > > I want to avoid this. :) The implementations in my actual math libraries are > much more thorough and thought out. This is an example. If people want to see > something that is closer to what would actually be done in a library, they >

Re: [PHP-DEV] Revisiting Userland Operator Overloads

> On Aug 11, 2021, at 12:06 AM, Jordan LeDoux wrote: > > Here is a quick and dirty example of just the complex number use case. It > assumes that the operator overloads already are built in. A couple of > things of note: Excellent. Thank you for taking the time to do this. Very helpful. One

Re: [PHP-DEV] Revisiting Userland Operator Overloads

> On Aug 10, 2021, at 10:22 AM, Larry Garfield wrote: > > Point of order: I do not support a dedicated value-object/data-object > construct, and have said so explicitly. I support targeted tools that make > using objects in that fashion cleaner and more robust. (readonly, asymmetric >

Re: [PHP-DEV] Revisiting Userland Operator Overloads

> On Aug 9, 2021, at 8:40 PM, Jordan LeDoux wrote: > That is in part of why I asked for use-case examples, to see if there really > were a lot of use-cases where operator overloading makes sense. You only > provided two categories; Math and the already existing DateInterval. > > This

Re: [PHP-DEV] Revisiting Userland Operator Overloads

On Aug 9, 2021, at 5:32 PM, Mike Schinkel wrote: > On Aug 9, 2021, at 1:48 PM, Jordan LeDoux wrote: > You claim that this would be documented on php.net and this would be > sufficient. Yet the DateTime class has had operator overloads for comparison > operators since 5.2 and th

Re: [PHP-DEV] Revisiting Userland Operator Overloads

> On Aug 8, 2021, at 3:41 AM, Jordan LeDoux wrote: > > Off the top of my head here are some of the use cases that I think benefit > greatly from this: > > - Complex number objects > - Fractions objects > - Matrix objects (math) > - Vector objects (math) > - Time/Date intervals > - Collections

Re: [PHP-DEV] Revisiting Userland Operator Overloads

> On Aug 7, 2021, at 10:28 AM, Larry Garfield wrote: > > The downside is that 30 seconds after that, 15 other libraries would do the > same in subtly incompatible ways, and then both Laravel and Symfony would > release their own that are incompatible with each other, and it would just be > a

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

> On Aug 6, 2021, at 3:51 AM, Aleksander Machniak wrote: > > I agree about the _string suffix removal. However, I know we have > parse_url() already, but parse_query() might be too generic. I would > suggest adding "http" to the name. And as we already have > http_build_query() I would rather

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

> On Aug 5, 2021, at 6:21 PM, Kamil Tekiela wrote: > > I have added implementation for > https://wiki.php.net/rfc/parse_str_alternative. If there are no other > comments, I would like to start voting on Saturday. I too would appreciate having a function in the PHP library that returns an

[PHP-DEV] Implicit Interfaces? (was [PHP-DEV] [RFC] Nullable intersection types)

> On Jul 27, 2021, at 11:02 PM, Jordan LeDoux wrote: > > Intersection types are very useful if you use composition over inheritance. > That is, in PHP, they are most useful when you are using multiple > interfaces and/or traits to represent different aspects of an object which > might be

Re: [PHP-DEV] [RFC] Nullable intersection types

> On Jul 24, 2021, at 1:33 AM, Tobias Nyholm wrote: >> If you are not willing to compromise you will probably get nothing. >> >> It is relevant because I was trying to get you to ask yourself if you would >> be happier if you get half of what you want rather than none of what you >> want. >>

Re: [PHP-DEV] [RFC] Nullable intersection types

g my message above could make it sound like I am pessimistic. That > is not true. I am excited about this change and I am happy PHP has a long > feature freeze so issues like this can show up before the release. > > Regards, > Tobias > > >> On 23 Jul 2021, at 20:53,

Re: [PHP-DEV] [RFC] Nullable intersection types

> On Jul 23, 2021, at 5:58 AM, Nicolas Grekas wrote: > > Hi everyone, > > as proposed by Nikita and Joe, I'm submitting this late RFC for your > consideration for inclusion in PHP 8.1. Intersection types as currently > accepted are not nullable. This RFC proposes to make them so. > > I wrote

Re: [PHP-DEV] Problems with the mailing list [was: Re: [PHP-DEV] Request for karma to vote on RFCs]

> On Jul 20, 2021, at 3:44 AM, Lynn wrote: > > On Tue, Jul 20, 2021 at 9:33 AM Peter Bowyer > wrote: > >> I have now been contacted by 2 people who tried multiple times to join this >> mailing list and cannot. >> >> It took me 5 weeks for my signup to work. During that time I emailed the >>

Re: [PHP-DEV] Problems with the mailing list [was: Re: [PHP-DEV] Request for karma to vote on RFCs]

> On Jul 22, 2021, at 1:53 PM, Tiffany Taylor > wrote: > > Forwarding this to internals because I mistakenly replied to an email > directly. > > On Tue, Jul 20, 2021 at 2:33 AM Peter Bowyer > wrote: > Currently there are people with voting permissions that do vote, yet do >> not

Re: [PHP-DEV] Request for karma to vote on RFCs

> On Jul 20, 2021, at 9:39 AM, Rowan Tommins wrote: > > When decisions are just a matter of bikeshedding, or deciding what "style" > the language should have, there is a strong argument for general democracy, > and a strong voice for those who use the language. > > But some decisions have

Re: [PHP-DEV] Request for karma to vote on RFCs

> On Jul 20, 2021, at 8:55 AM, Andreas Heigl wrote: > > Hey Mike > > Thank you for your feedback! > > Am 20.07.21 um 11:57 schrieb Mike Schinkel: >> Quoting the RFC >> >>> the requester has contributed to the PHP sourcecode ecosystem. >>

Re: [PHP-DEV] License for PHP 8.x?

> On Jul 20, 2021, at 6:16 AM, Nikita Popov wrote: > > On Tue, Jul 20, 2021 at 12:01 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote: >> On Jul 19, 2021, at 3:31 AM, Nikita Popov > <mailto:nikita@gmail.com>> wrote: >> >> On Mon, J

Re: [PHP-DEV] License for PHP 8.x?

> On Jul 19, 2021, at 3:31 AM, Nikita Popov wrote: > > On Mon, Jul 19, 2021 at 5:56 AM Mike Schinkel <mailto:m...@newclarity.net>> wrote: > I was just checking to see what the license was for PHP and this page[1] > states: > > "PHP 4, PHP 5 and

Re: [PHP-DEV] Request for karma to vote on RFCs

Quoting the RFC > the requester has contributed to the PHP sourcecode ecosystem. You mention what types of contributions apply, but give no indication of quantity. If someone fixes one bug, does that give them voting rights? I would assume not. So is it two bugs, 10 bugs, 100? > these

[PHP-DEV] License for PHP 8.x?

I was just checking to see what the license was for PHP and this page[1] states: "PHP 4, PHP 5 and PHP 7 are distributed under the PHP License v3.01, copyright (c) the PHP Group." Can I assume that PHP 8 is also distributed under the PHP License v3.01 and that this page on PHP.net

Re: [PHP-DEV] Readonly properties - immutability by default

> On Jul 17, 2021, at 1:40 AM, Eugene Sidelnyk wrote: > > > Having a "readonly" class where the properties are read-only by default > > makes sense to me, but maybe the better way to do it is with an attribute? > > We already have such an attribute provided. It is called >

Re: [PHP-DEV] Readonly properties - immutability by default

> On Jul 16, 2021, at 6:12 AM, Bruce Weirdan wrote: > > On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk wrote: > >> Readonly properties are really useful for DDD, where everything is going to >> be immutable. It promotes best practices. However for people to use it, >> syntax should be concise

Re: [PHP-DEV] Type casting syntax

> On Jul 12, 2021, at 4:28 PM, Lynn wrote: > On Mon, Jul 12, 2021 at 10:20 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote: > It seems you have just illustrated why in reality we really do not need type > casting/assertions in PHP given its current features, because we

Re: [PHP-DEV] Type casting syntax

> On Jul 12, 2021, at 1:56 PM, Max Semenik wrote: > > On Mon, Jul 12, 2021 at 8:01 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote: > Additionally in Go a type assertion can return a second value which is > boolean telling if the type assertion succeeded

Re: [PHP-DEV] Type casting syntax

> On Jul 12, 2021, at 11:00 AM, Larry Garfield wrote: > x > On Mon, Jul 12, 2021, at 9:54 AM, Max Semenik wrote: > >> I was thinking of something akin to many compiled languages' approach of >> "consider this expression is now of that type, and throw an exception if >> it's not". An example of

Re: [PHP-DEV] Type casting syntax

> On Jul 11, 2021, at 7:19 PM, Larry Garfield wrote: > > What are the use cases for integrated object to object (ie, class to class) > conversion in PHP? > I'm not entirely clear on what the use case is in PHP. When would that be > superior to "just write an asFoo() method and move on

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

> On Jul 8, 2021, at 1:26 PM, Rowan Tommins wrote: > > for the record, here is what I think: > > * Removal of a deprecated feature can be at any point in the future, even the > indefinite future, just not "never". > * Very short deprecation periods can be harmful, because they don't give >

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

Replying to Rowan and commenting on Nikita's message. > On Jul 6, 2021, at 4:24 AM, Rowan Tommins wrote: > >> Instead I replied because your email strongly implied (stated?) that >> "deprecation required removal" > > I stand by that interpretation, which while not universal is very widely >

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

Replying in one long email to all three who replied to me: > On Jul 5, 2021, at 8:03 AM, Guilliam Xavier wrote: > Hi Mike, > > Your links speak *in general*. However this is *specifically for PHP*: >

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

> On Jul 5, 2021, at 7:14 AM, Rowan Tommins wrote: > > On 05/07/2021 11:46, Patrick ALLAERT wrote: >> Did we ever deprecated something without the immediate intention of >> removing it? > > > What would that even mean? It would mean that although the functions are available and allowed, they

Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named parameter mapping for call_user_func*

> On Jul 2, 2021, at 12:30 AM, Hossein Baghayi > wrote: > > Hello, > > On Sun, 27 Jun 2021 at 19:09, Ralph Schindler > wrote: > >> >> This proposes a method for a publisher/framework/producer (the caller of >> the callback) to document all the parameters that are available as named >>

Re: [PHP-DEV] [RFC] Readonly properties

> On Jun 29, 2021, at 9:08 AM, Nikita Popov wrote: > > In any case, I don't want to include changes to cloning in this proposal -- > the topic is related, but also orthogonal to readonly properties. > Unfortunately, it will not be possible to get cloning changes into PHP 8.1 > anymore, due to

Re: [PHP-DEV] is_literal() is back

xcept to use a technique that your RFC describes as "clearly the developer doing something wrong." -Mike [1] https://github.com/nilportugues/php-sql-query-builder > On Sat, 26 Jun 2021 at 2:51 pm, Mike Schinkel <mailto:m...@newclarity.net>> wrote: > The idea behind is_li

Re: [PHP-DEV] is_literal() is back

The idea behind is_literal() is of good intention, but as they say the road to hell is paved with good intentions. The RFC proposes to add an internal "literal" flag to a string, the is_literal() function, and nothing else. Further the RFC states a vision to get "libraries to start using

Re: [PHP-DEV] Introduce str_left/right In 8.1

> On Jun 24, 2021, at 8:04 AM, G. P. B. wrote: > > Moreover, the fact that only a very restricted number of programming > languages, which are some of the earliest languages ever, implement those > functions should tell you something about programming language design > as a whole, which is that

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On Jun 24, 2021, at 6:33 AM, Stephen Reay wrote: > >> On 24 Jun 2021, at 17:07, Kamil Tekiela wrote: >> >> Hi Stephen, >> >> I believe the idea was for dynamically generate table names, or numbered >> tables/columns. E.g. >> >> function getTable(string $table){ >>// is_literal check

Re: [PHP-DEV] [RFC] clamp

> On Jun 24, 2021, at 7:59 AM, Pierre wrote: > > Le 24/06/2021 à 11:44, Michał Marcin Brzuchalski a écrit : >> I get an impression that we constantly add things into standard library >> which are from a language perspective irrelevant >> and that all could be developed in userland with no

Re: [PHP-DEV] Introduce str_left/right In 8.1

Replying to both Sara's and G.P.B.'s emails below: > On Jun 23, 2021, at 12:48 PM, Sara Golemon wrote: > > Using some context, I would assume you mean this: > > function str_left(string $str, int $len): string { > return substr($str, 0, $len); > } > > function str_right(string $str, int

[PHP-DEV] Add mysqi_stmt->query? (Was Sql Object Model Parser & Sanitizer)

> On Jun 22, 2021, at 12:54 PM, Kamil Tekiela wrote: > While it's true that a lot of the internet is using mysqli due to WordPress, > this doesn't change the fact that PHP already offers a solution to the > problem. Both PDO and mysqli support server-side prepared statements. > Hi Kamil,

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

> On Jun 22, 2021, at 11:41 AM, Larry Garfield wrote: > > On Tue, Jun 22, 2021, at 8:39 AM, Mike Schinkel wrote: >>> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: >>> >>> Hi Mike, >>> >>> Please don't do this. We already have PDO

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

> On Jun 22, 2021, at 11:56 AM, Pierre wrote: > > Le 22/06/2021 à 17:35, Mike Schinkel a écrit : >> https://github.com/WordPress/WordPress/blob/master/wp-includes/wp-db.php#L2050 > Sorry for the discussion pollution here but, but ouch, plugins are still > using this unsaf

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

> On Jun 22, 2021, at 10:35 AM, Stephen Reay wrote: > >> On 22 Jun 2021, at 20:39, Mike Schinkel wrote: >> >>> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: >>> >>> Hi Mike, >>> >>> Please don't do this. We already

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: > > Hi Mike, > > Please don't do this. We already have PDO with prepared statements. The data > must be bound. This is the secure way of writing SQL queries. The problem is that over 40% of the web currently runs on PHP code that using

[PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

> On Jun 22, 2021, at 6:45 AM, Pierre wrote: > > Le 22/06/2021 à 11:28, Dan Ackroyd a écrit : >> On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: >>> Should(n't?) PHP add a basic SQL builder class that can be extended for >>> special cas

Re: [PHP-DEV] [RFC] is_literal

> On Jun 22, 2021, at 5:28 AM, Dan Ackroyd wrote: > > On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: >> >> Should(n't?) PHP add a basic SQL builder class that can be extended for >> special cases, e.g. different flavors of SQL? >> > > No. Or at

Re: [PHP-DEV] [RFC] is_literal

> On Jun 22, 2021, at 4:53 AM, Dan Ackroyd wrote: > > The whole point of the idea of literal strings is to make it be easier > to write some code that: > > i) is safe. > ii) can be reasoned about at scale. > > Passing bare strings around is not so great for either of those > things. You have

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

> On Jun 21, 2021, at 7:18 PM, Benjamin Morel wrote: > > On Tue, 22 Jun 2021 at 01:06, Derick Rethans wrote: > >> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki wrote: >>> >>> The name "is_trusted" is misleading. >>> Literal is nothing but literal. >> >> I agree with this. The name is_trusted

Re: [PHP-DEV] [PROPOSAL] Bare name array literals (again)

> On Jun 21, 2021, at 1:34 PM, Rowan Tommins wrote: > > On 21/06/2021 17:54, tyson andre wrote: >> In every place where `key` is a valid php identifier >> (e.g. can be used in PHP 8.0's named parameters), >> I propose to allow `[key: expr]` to be used instead of `['key' => expr]`. > > This is

Re: [PHP-DEV] [Vote] Partial Function Application

> On Jun 18, 2021, at 7:41 PM, Benjamin Eberlei wrote: > > On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield > wrote: > >> Hi folks. The vote for the Partial Function Application RFC is now open, >> and will run until 30 June. >> >> https://wiki.php.net/rfc/partial_function_application > > I

Re: [PHP-DEV] [RFC] is_literal

> On Jun 18, 2021, at 8:30 AM, Mike Schinkel wrote: > > >> On Jun 18, 2021, at 7:22 AM, Craig Francis > <mailto:cr...@craigfrancis.co.uk>> wrote: >> >> On Fri, 18 Jun 2021 at 11:45 am, Guilliam Xavier > <mailto:guilliam.xav...@gmail.com>> &g

  1   2   3   4   5   >