On Jun 7 2024, at 8:49 pm, Erick de Azevedo Lima
wrote:
> The new keyword is meaningful and everyone knows what's being done just by
> looking at it. Removing it would make the language less readable. But it's a
> BC so big that I don't think it can be done anyway.
>
>
FWIW Languages like Da
> Please, don't make PHP as unreadable as Perl. IMO It's two extra
characters at worst and would be solved much more elegantly by removing the
new keyword entirely.
The new keyword is meaningful and everyone knows what's being done just by
looking at it. Removing it would make the language less r
> So here is my proposal :
>
> Add a "new" shorthand, using the tilde character : "~"
-10.
Please, don't make PHP as unreadable as Perl. IMO It's two extra characters at
worst and would be solved much more elegantly by removing the new keyword
entirely.
J
On 07/06/2024 22:34, Erick de Azevedo Lima wrote:
I also think that `new `(4 chars, if we count the blank space) is
short enough.
Strongly agree. This solves a problem nobody has. Feel free to carry on
regardless, though; curious to see where this ends up going.
Bilge
On Fri, Jun 7, 2024 at 11:50 PM Larry Garfield
wrote:
> On Fri, Jun 7, 2024, at 9:34 PM, Erick de Azevedo Lima wrote:
> > Hi all.
> >
> >> Em sex., 7 de jun. de 2024 às 17:53, Pierre
> escreveu:
> >> I do agree with you that when you use value objects, you need it a lot,
> >> but I'd much prefer
On Fri, Jun 7, 2024, at 9:34 PM, Erick de Azevedo Lima wrote:
> Hi all.
>
>> Em sex., 7 de jun. de 2024 às 17:53, Pierre
>> escreveu:
>> I do agree with you that when you use value objects, you need it a lot,
>> but I'd much prefer having a JS like value objects initializer syntax,
>> such as `
Hi all.
> Em sex., 7 de jun. de 2024 às 17:53, Pierre
escreveu:
> I do agree with you that when you use value objects, you need it a lot,
> but I'd much prefer having a JS like value objects initializer syntax,
> such as `Point {x: 1, y: 2}` syntax than creating another way to call
> the construc
Le ven. 7 juin 2024, 21:31, Larry Garfield a
écrit :
> On Fri, Jun 7, 2024, at 5:56 PM, ericm...@php.net wrote:
>
> >> Instead of ~ (which reminds me of the pendulum of symbols to written to
> symbols and back again every 10ish years; “or” vs “||”), why not make a
> shorthand way to write a funct
Le 07/06/2024 à 21:38, Larry Garfield a écrit :
On Fri, Jun 7, 2024, at 7:20 PM, Pierre wrote:
I sincerely do not want to see a new operator for replacing the "new"
operator, because then we would have two different syntaxes which would
be semantically equivalent.
Creating a new object, in mos
On Fri, Jun 7, 2024, at 7:20 PM, Pierre wrote:
> I sincerely do not want to see a new operator for replacing the "new"
> operator, because then we would have two different syntaxes which would
> be semantically equivalent.
>
> Creating a new object, in most API design, is not something you do ve
On Fri, 7 Jun 2024 at 21:17, Rob Landers wrote:
>
>
>
> On Fri, Jun 7, 2024, at 21:02, Andreas Hennings wrote:
>
> On Fri, 7 Jun 2024 at 20:31, Larry Garfield wrote:
> >
> > On Fri, Jun 7, 2024, at 5:56 PM, ericm...@php.net wrote:
> >
> > >> Instead of ~ (which reminds me of the pendulum of symbo
Le 07/06/2024 à 18:03, Benoît Condaminet a écrit :
Hello,
Following the RFC process, I'm sending this to propose a PHP change.
More precisely a new zend language token.
This is somehow linked to the recently accepted RFC called "new
MyClass()->method() without parentheses", the goal is to in
On Fri, Jun 7, 2024, at 21:02, Andreas Hennings wrote:
> On Fri, 7 Jun 2024 at 20:31, Larry Garfield wrote:
> >
> > On Fri, Jun 7, 2024, at 5:56 PM, ericm...@php.net wrote:
> >
> > >> Instead of ~ (which reminds me of the pendulum of symbols to written to
> > >> symbols and back again every 10i
On Fri, 7 Jun 2024 at 20:31, Larry Garfield wrote:
>
> On Fri, Jun 7, 2024, at 5:56 PM, ericm...@php.net wrote:
>
> >> Instead of ~ (which reminds me of the pendulum of symbols to written to
> >> symbols and back again every 10ish years; “or” vs “||”), why not make a
> >> shorthand way to write
On Fri, Jun 7, 2024, at 5:56 PM, ericm...@php.net wrote:
>> Instead of ~ (which reminds me of the pendulum of symbols to written to
>> symbols and back again every 10ish years; “or” vs “||”), why not make a
>> shorthand way to write a function that calls a constructor (kinda sorta like
>> C# ex
On 6/7/24 10:35, Rob Landers wrote:
On Fri, Jun 7, 2024, at 18:03, Benoît Condaminet wrote:
Hello,
Following the RFC process, I'm sending this to propose a PHP change.
More precisely a new zend language token.
This is somehow linked to the recently accepted RFC called "new
MyClass()->metho
On Fri, Jun 7, 2024, at 18:03, Benoît Condaminet wrote:
> Hello,
>
> Following the RFC process, I'm sending this to propose a PHP change. More
> precisely a new zend language token.
>
> This is somehow linked to the recently accepted RFC called "new
> MyClass()->method() without parentheses"
Hi Benoît,
> On Jun 7, 2024, at 12:03, Benoît Condaminet
> wrote:
>
> As a first try, I start updated code to completely make the new keyword
> optional, like in Dart language for example, but it require very big change,
> with lot of impact (collision with function).
>
> So here is my prop
For the reference to the others: https://3v4l.org/UmPVo
Kind regards,
Jorg
> Le 17 févr. 2024 à 16:51, Larry Garfield a écrit :
>
> On Fri, Feb 16, 2024, at 7:56 PM, 하늘아부지 wrote:
>> Hi.
>> I'd like to propose an RFC, but I don't have the authority.
>> Below is my suggestion.
>> If you think this makes sense, please write an RFC for me.
>> Sincerely.
>>
>> --
On Fri, Feb 16, 2024, at 7:56 PM, 하늘아부지 wrote:
> Hi.
> I'd like to propose an RFC, but I don't have the authority.
> Below is my suggestion.
> If you think this makes sense, please write an RFC for me.
> Sincerely.
>
> --
>
> = Introductio
Hi
On 1/7/24 07:17, Jim Winstead wrote:
I've created a simple RFC so a vote can be taken on adding a link to the PHP
Foundation from the PHP.net site.
If there's no substantial discussion ongoing, I'll plan on opening the voting
on January 13th.
https://wiki.php.net/rfc/promote_php_foundatio
On Fri, Jan 5, 2024 at 9:40 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> There are indeed dozens of libraries already working with PSR nicely but
> IMHO
> the API should provide all the necessary information in a way that allows
> the construction of such objects,
> but su
On 5 January 2024 12:18:51 GMT, Robert Landers wrote:
>This is easy to handle from C. If the callback takes an argument,
>don't fill in the super-globals.
Again, that's compatible only in a narrow sense: it provides both APIs on any
run-time which can do so safely.
You still have an incompatibl
pt., 5 sty 2024 o 13:19 Robert Landers
napisał(a):
> On Fri, Jan 5, 2024 at 11:59 AM Rowan Tommins
> wrote:
>
> > > Globals is how this works (atm)
> >
> > It's how it works for native SAPIs. It's not, as far as I know, how any
> worker system other than FrankenPHP has implemented its API. Every
On Fri, Jan 5, 2024 at 11:59 AM Rowan Tommins wrote:
>
> On 5 January 2024 09:02:05 GMT, Robert Landers
> wrote:
> > I don't think they are fundamentally incompatible. If we look at
> >FrankenPHP's implementation, you pass a callback that gets called when
> >there is a request.
>
> No, you pass
On 5 January 2024 09:02:05 GMT, Robert Landers wrote:
> I don't think they are fundamentally incompatible. If we look at
>FrankenPHP's implementation, you pass a callback that gets called when
>there is a request.
No, you pass a callback which is called exactly once, for the next request. You
ha
Hi,
> But holding up the entire conversation because these things don't even
> exist,
BTW, I'm not asking to wait for the implementation of a native event loop
before implementing a worker mode, I'm asking to design the worker mode API in
a way that is compatible with an eventual native event l
On Fri, Jan 5, 2024 at 8:47 AM Rowan Tommins wrote:
>
> On 5 January 2024 06:55:34 GMT, Robert Landers
> wrote:
>
> >I already said this, but to reiterate: I, personally, hear what you
> >are saying and largely agree with you; however, before we can really
> >have any kind of discussion on concu
On 5 January 2024 06:55:34 GMT, Robert Landers wrote:
>I already said this, but to reiterate: I, personally, hear what you
>are saying and largely agree with you; however, before we can really
>have any kind of discussion on concurrent servers, we HAVE to address
>the underlying issues that are m
On Fri, Jan 5, 2024 at 2:56 AM Daniil Gentili wrote:
>
> Hi,
>
> I've been lurking around in the discussion for a while, and I'd like to chime
> in now since the main, glaring issue with this proposal has only been
> explicitly mentioned by Rowan Tomminis, with that subthread quickly
> degenera
Hi,
I've been lurking around in the discussion for a while, and I'd like to chime
in now since the main, glaring issue with this proposal has only been
explicitly mentioned by Rowan Tomminis, with that subthread quickly
degenerating with misguided replies.
PHP as a language absolutely needs a
On Tue, Jan 2, 2024 at 3:46 PM Jeffrey Dafoe wrote:
> > > Again, the representation as objects isn't a key requirement. Python's
> > > WSGI spec simply has a dictionary (read: associative array) of the
> > > environment based on CGI. The application might well turn that into a
> > > more powerful
> > Again, the representation as objects isn't a key requirement. Python's
> > WSGI spec simply has a dictionary (read: associative array) of the
> > environment based on CGI. The application might well turn that into a
> > more powerful object, but standardisation of such wasn't considered a
> > p
I'm running out of different ways to say the same thing, and not really
sure which part of my previous messages people haven't understood. I'm
really not saying anything very controversial or complicated, just "had
you considered that style B would offer these additional possibilities
over styl
On Mon, Jan 1, 2024 at 12:18 PM Rowan Tommins wrote:
>
> On 31 December 2023 16:31:31 GMT, Pierre Joye wrote:
>
> >php handles this in threadsafe mode
>
> Depending on your exact definition of "php", this is either irrelevant or
> just plain wrong.
>
> If you mean "the HTTP SAPIs shipped with of
On Mon, Jan 1, 2024, 6:18 PM Rowan Tommins wrote:
> On 31 December 2023 16:31:31 GMT, Pierre Joye
> wrote:
>
> >php handles this in threadsafe mode
>
> Depending on your exact definition of "php", this is either irrelevant or
> just plain wrong.
>
> If you mean "the HTTP SAPIs shipped with offic
On 31 December 2023 16:31:31 GMT, Pierre Joye wrote:
>php handles this in threadsafe mode
Depending on your exact definition of "php", this is either irrelevant or just
plain wrong.
If you mean "the HTTP SAPIs shipped with official builds of PHP", then it's
true, none handle multiple concurre
hello,
On Sun, Dec 31, 2023, 6:59 PM Rowan Tommins wrote:
Then one of us is missing something very fundamental. As I understand it,
> Swoole's model is similar to that popularised by node.js: a single thread
> processes multiple incoming requests concurrently, using asynchronous I/O.
The nodej
On 31 December 2023 08:31:16 GMT, "Kévin Dunglas" wrote:
>This new function is intended for SAPIs. Swoole was given as an example of
>worker mode, but it isn't a SAPI. AFAIK, it doesn't use the SAPI
>infrastructure provided by PHP.
>The scope of my proposal is only to provide a new feature in the
On Sun, Dec 31, 2023 at 2:20 AM Rowan Tommins
wrote:
> On 30 December 2023 19:48:39 GMT, Larry Garfield
> wrote:
> >The Franken-model is closer to how PHP-FPM works today, which means that
> is easier to port existing code to, especially existing code that has lots
> of globals or hidden globals
On 30 December 2023 19:48:39 GMT, Larry Garfield wrote:
>The Franken-model is closer to how PHP-FPM works today, which means that is
>easier to port existing code to, especially existing code that has lots of
>globals or hidden globals. (Eg, Laravel.) That may or may not make it the
>better m
Hi Larry,
sob., 30 gru 2023 o 20:49 Larry Garfield
napisał(a):
> On Sat, Dec 30, 2023, at 4:53 AM, Rowan Tommins wrote:
> > On 30 December 2023 09:59:07 GMT, Robert Landers
> > wrote:
> >>For this to happen in PHP Core, there would need to be request objects
> >>instead of a global state.
> >
>
On Sat, Dec 30, 2023, at 4:53 AM, Rowan Tommins wrote:
> On 30 December 2023 09:59:07 GMT, Robert Landers
> wrote:
>>For this to happen in PHP Core, there would need to be request objects
>>instead of a global state.
>
> Again, the representation as objects isn't a key requirement. Python's
> WS
On 30 December 2023 09:59:07 GMT, Robert Landers
wrote:
>For this to happen in PHP Core, there would need to be request objects
>instead of a global state.
Again, the representation as objects isn't a key requirement. Python's WSGI
spec simply has a dictionary (read: associative array) of the e
Hi Robert,
sob., 30 gru 2023, 10:59 użytkownik Robert Landers
napisał:
> > > - FrankenPHP expects the user to manage the main event loop ...
> > >
> > >
> > > This isn't exact. FrankenPHP does manage the event loop (the Go
> > > runtime manages it - through a channel - under the hood).
> >
>
> > - FrankenPHP expects the user to manage the main event loop ...
> >
> >
> > This isn't exact. FrankenPHP does manage the event loop (the Go
> > runtime manages it - through a channel - under the hood).
>
>
> Perhaps "event loop" was the wrong term; what I was highlighting is that
> to use F
Hi Rowan,
pt., 29 gru 2023 o 23:56 Rowan Tommins napisał(a):
> On 29/12/2023 21:14, Kévin Dunglas wrote:
> ...
> The use of objects vs arrays wasn't the main difference I was trying to
> highlight there, but rather the overall API of how information gets into
> and out of the application. Franke
On 29/12/2023 21:14, Kévin Dunglas wrote:
On Fri, Dec 29, 2023 at 8:14 PM Rowan Tommins
wrote:
- FrankenPHP expects the user to manage the main event loop ...
This isn't exact. FrankenPHP does manage the event loop (the Go
runtime manages it - through a channel - under the hood).
Per
On Fri, Dec 29, 2023 at 8:14 PM Rowan Tommins
wrote:
> - FrankenPHP expects the user to manage the main event loop, repeatedly
> passing the server a function to be called once; it doesn't pass
> anything into or out of the userland handler, instead resetting global
> state to mimic a non-worker
On 23/12/2023 20:34, Kévin Dunglas wrote:
In addition to sharing code, maintenance, performance optimization, etc.,
the existence of a common infrastructure would standardize the way worker
scripts are created and provide a high-level PHP API for writing worker
scripts that work with all SAPIs th
Hi
On 12/25/23 19:56, Jordan LeDoux wrote:
So you want to introduce a SAPI that doesn't work with any of the existing
HTTP solutions people use that only supports HTTP requests? Or am I
misunderstanding something?
This sounds a bit like you want to merge in a tool that is designed for
your pers
>
> So you want to introduce a SAPI that doesn't work with any of the existing
> HTTP solutions people use that only supports HTTP requests? Or am I
> misunderstanding something?
>
> This sounds a bit like you want to merge in a tool that is designed for
> your personal product directly into core.
Hello,
On Tue, Dec 26, 2023, 1:56 AM Jordan LeDoux wrote:
>
> So you want to introduce a SAPI that doesn't work with any of the existing
> HTTP solutions people use that only supports HTTP requests? Or am I
> misunderstanding something?
>
> This sounds a bit like you want to merge in a tool that
Why not just build this into the embed sapi instead? since its only for
third party sapis?
On 2023-12-23 1:34 p.m., Kévin Dunglas wrote:
Hello and Merry Christmas!
One of the main features of FrankenPHP is its worker mode, which lets you
keep a PHP application in memory to handle multiple HTTP
Hi,
On Tue, Dec 26, 2023 at 12:09 AM Robert Landers
wrote:
> Hi Jakub,
>
> > I have been thinking about something similar for FPM and if you had some
> > sort pool manager process, you could maybe do some sort of initial
> > execution but then it gets really tricky especially with sharing
> reso
On Mon, Dec 25, 2023 at 7:06 PM Kévin Dunglas wrote:
>
> On Mon, Dec 25, 2023 at 6:30 PM Jakub Zelenka wrote:
>
>>
>>
>> On Mon, Dec 25, 2023 at 12:34 PM Kévin Dunglas wrote:
>>
>>> On Sun, Dec 24, 2023 at 4:21 PM Larry Garfield
>>> wrote:
>>>
>>> In practice, I want to understand the implicat
Hi Jakub,
> I have been thinking about something similar for FPM and if you had some
> sort pool manager process, you could maybe do some sort of initial
> execution but then it gets really tricky especially with sharing resources
> and managing connections. I think it would be a big can of worms
On Mon, Dec 25, 2023 at 7:56 PM Jordan LeDoux
wrote:
>
>
> On Mon, Dec 25, 2023 at 8:19 AM Kévin Dunglas wrote:
>
>>
>> On Sun, Dec 24, 2023 at 10:44 PM Jordan LeDoux
>> wrote:
>>
>>>
>>>
>>> On Sat, Dec 23, 2023 at 12:34 PM Kévin Dunglas wrote:
>>>
Hello and Merry Christmas!
On
On Mon, Dec 25, 2023 at 6:30 PM Jakub Zelenka wrote:
>
>
> On Mon, Dec 25, 2023 at 12:34 PM Kévin Dunglas wrote:
>
>> On Sun, Dec 24, 2023 at 4:21 PM Larry Garfield
>> wrote:
>>
>> In practice, I want to understand the implications for user-space code.
>> > Does this mean FPM could be configure
On Mon, Dec 25, 2023 at 8:19 AM Kévin Dunglas wrote:
>
> On Sun, Dec 24, 2023 at 10:44 PM Jordan LeDoux
> wrote:
>
>>
>>
>> On Sat, Dec 23, 2023 at 12:34 PM Kévin Dunglas wrote:
>>
>>> Hello and Merry Christmas!
>>>
>>> One of the main features of FrankenPHP is its worker mode, which lets you
>
On Mon, Dec 25, 2023 at 12:34 PM Kévin Dunglas wrote:
> On Sun, Dec 24, 2023 at 4:21 PM Larry Garfield
> wrote:
>
> In practice, I want to understand the implications for user-space code.
> > Does this mean FPM could be configured in a way to execute a file like
> that
> > shown in the docs page
> Forgive my ignorance, but why no connection? You mean the
> pre-worker-start part needs to avoid an SQL connection? Why is that? That
> would be something that needs to be super-well documented, and possibly
> some guards in place to prevent it, if there's no good way around it.
> (This is the
On Mon, Dec 25, 2023, at 6:34 AM, Kévin Dunglas wrote:
> However, I suggest doing this as a second step, because as described in
> my first post, it will still be the responsibility of each SAPI to
> manage long-running processes and communication with them. This is
> simple to do with Go's GoR
On Sun, Dec 24, 2023 at 10:44 PM Jordan LeDoux
wrote:
>
>
> On Sat, Dec 23, 2023 at 12:34 PM Kévin Dunglas wrote:
>
>> Hello and Merry Christmas!
>>
>> One of the main features of FrankenPHP is its worker mode, which lets you
>> keep a PHP application in memory to handle multiple HTTP requests.
On Sun, Dec 24, 2023 at 4:21 PM Larry Garfield
wrote:
In practice, I want to understand the implications for user-space code.
> Does this mean FPM could be configured in a way to execute a file like that
> shown in the docs page above? Or would it only work with third party SAPIs
> like FrankenP
On Sat, Dec 23, 2023 at 12:34 PM Kévin Dunglas wrote:
> Hello and Merry Christmas!
>
> One of the main features of FrankenPHP is its worker mode, which lets you
> keep a PHP application in memory to handle multiple HTTP requests.
>
> Worker modes are becoming increasingly popular in the PHP world
On Sat, Dec 23, 2023, at 2:34 PM, Kévin Dunglas wrote:
> Hello and Merry Christmas!
>
> One of the main features of FrankenPHP is its worker mode, which lets you
> keep a PHP application in memory to handle multiple HTTP requests.
>
> Worker modes are becoming increasingly popular in the PHP world.
> On 24 Nov 2023, at 01:09, Rowan Tommins wrote:
>
> On Thu, 23 Nov 2023 at 14:20, Stephen Reay wrote:
>
>>
>> Out of the box, with no package manager or module loader or anything, you
>> can do as little as call `spl_autoload_register` with no arguments, and
>> have working class autoloadi
Seriously? Are you really this stupid or just feigning ignorance? How is
this a global:
class X {
private static $count = 0;
}
I am no longer pushing this RFC because idiots like you are in charge of
the votes but seriously your argument is dumb as fuck. If you aren't
sure then why say anythi
On Thu, 23 Nov 2023 at 14:20, Stephen Reay wrote:
>
> Out of the box, with no package manager or module loader or anything, you
> can do as little as call `spl_autoload_register` with no arguments, and
> have working class autoloading.
>
Sure, it's just about possible that you could paste that
Again, with so many absolutes. Static APIs aren't inherently bad;
rather, bad programmers write poor code. It seems like you're assuming
that PHP developers can't make decisions about what tools to use
independently and need explicit encouragement or endorsement from you.
Just because you are u
On Thu, Nov 23, 2023, at 1:43 AM, Robert Landers wrote:
> I'd venture to say that static classes have some unique benefits over
> plain functions. One, you can encapsulate state using private static
> variables. That simply isn't possible with regular functions (unless
> you use static variables i
> On 23 Nov 2023, at 19:42, Rowan Tommins wrote:
>
> On Thu, 23 Nov 2023 at 11:48, Stephen Reay wrote:
>
>>
>> Respectively, I disagree that it's "not a big problem" if your goal is to
>> encourage people to use regular functions over classes with static methods.
>>
>
>
> Just to be clea
On Thu, 23 Nov 2023 at 11:48, Stephen Reay wrote:
>
> Respectively, I disagree that it's "not a big problem" if your goal is to
> encourage people to use regular functions over classes with static methods.
>
Just to be clear, my answer was specifically addressing your point about
using Composer
> On 23 Nov 2023, at 17:21, Rowan Tommins wrote:
>
> On Thu, 23 Nov 2023 at 06:00, Stephen Reay wrote:
>
>> I'm disappointed to see yet again that there's this implied notion that
>> working with PHP in 2023 means "well surely you must be using composer",
>> which leads to "but composer..." s
On Thu, 23 Nov 2023 at 06:00, Stephen Reay wrote:
> I'm disappointed to see yet again that there's this implied notion that
> working with PHP in 2023 means "well surely you must be using composer",
> which leads to "but composer..." somehow being an accepted argument when
> it comes to missing/
On Thu, Nov 23, 2023 at 7:00 AM Stephen Reay wrote:
>
>
>
> > On 21 Nov 2023, at 06:48, Mike Schinkel wrote:
> >
> > Wow.
> >
>
> Hi,
>
> (This is not a direct reply to Mike, his just seems to be less shouty than
> other recent emails)
>
> I'm not *particularly* bothered by the results of this s
> On 21 Nov 2023, at 06:48, Mike Schinkel wrote:
>
> Wow.
>
Hi,
(This is not a direct reply to Mike, his just seems to be less shouty than
other recent emails)
I'm not *particularly* bothered by the results of this specific RFC either way
- a *similar enough* result is already possible
Am 20.11.2023 um 22:00 schrieb Lanre Waju :
> I will have to disagree with everything you said:
Side-note: This is IMHO not a good intro into a discussion ;-)
> I outlined what a static class would be: A class that cannot be instantiated
> in which all members are implicitly static. We already h
I wouldn't support this, personally. I'm not a voter but I mean just in
terms of gauging community feel about the proposal, without unnecessarily
repeating what's already been said I just want to register that I'm in
agreement with Larry and Kamil's comments.
What static classes would achieve goes
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 use-cas
On Mon, Nov 20, 2023, at 9:00 PM, Lanre Waju wrote:
> I will have to disagree with everything you said:
>
> I outlined what a static class would be: A class that cannot be
> instantiated in which all members are implicitly static. We already have
> static members, so please elaborate on the maint
A class with a private constructor can still be instantiated. A class that
cannot be instantiated is pretty much useless. A static class would be just
a collection of functions. And I know that many developers write such
classes but it doesn't mean the language should encourage it. After all, if
so
Hi Lanre,
I like your idea and I was even thinking about proposing the same addition.
The thing that is missing in the description is how the static class should
handle magic methods. Should they be disabled for them?
One plus of static classes which exist in other languages are that we
wouldn't
I will have to disagree with everything you said:
I outlined what a static class would be: A class that cannot be
instantiated in which all members are implicitly static. We already have
static members, so please elaborate on the maintenance burden that
adding static to a class as that could h
On 20 November 2023 18:53:50 GMT, Deleu wrote:
>> It's probably not productive to just say "the people who voted last time
>> are wrong", but it was long enough ago that a new RFC on the topic wouldn't
>> break any rules.
>
>
>9 years is long enough to conclude that whatever happens, they weren't
On Mon, Nov 20, 2023, at 7:52 AM, Rowan Tommins wrote:
> On 19 November 2023 21:28:08 GMT, Lanre Waju wrote:
>>Hi, similar to the abstract and readonly modifiers to classes (similar in
>>syntax only), I propose a class level "static" modifier that ensures:
>
>
> Hi Lanre,
>
> There was a proposal
On Mon, Nov 20, 2023 at 1:43 PM Rowan Tommins
wrote:
> On 20 November 2023 08:35:15 GMT, Lanre Waju
> wrote:
>
> >1. I will personally implement this feature.
>
> That's good to hear, but the initial implementation is not the main cost
> of a new feature. Once we add something, it's very hard to
On 20 November 2023 08:35:15 GMT, Lanre Waju wrote:
>1. I will personally implement this feature.
That's good to hear, but the initial implementation is not the main cost of a
new feature. Once we add something, it's very hard to remove, and every future
change has to consider that feature and
Thank you for bringing those threads to my attention. I hadn't
encountered them before, but it appears to be the typical argument of "I
don't want this, so you shouldn't," along with "why do x when you can
just do y (notice how y is not x)."
1. I will personally implement this feature.
2. Thi
On 19 November 2023 21:28:08 GMT, Lanre Waju wrote:
>Hi, similar to the abstract and readonly modifiers to classes (similar in
>syntax only), I propose a class level "static" modifier that ensures:
Hi Lanre,
There was a proposal for this several years ago which was declined at the
voting stag
Hi again,
> Super on board with this
Sorry for top posting everyone, my bad, forgot to delete the rest of the
message :)
Regards,
Daniil Gentili
19 nov 2023 22:28:16 Lanre Waju :
> Hi, similar to the abstract and readonly modifiers to classes (similar in
> syntax only), I propose a class level "static" modifier that ensures:
>
> 1. The class cannot be instantiated and will throw an exception if attempted.
>
> 2. All methods and variable
On Fri, Sep 8, 2023, at 1:12 PM, Lanre Waju wrote:
> Dear PHP Internals,
>
> I am writing to propose a new feature for PHP that introduces the
> concept of structs. This feature aims to provide a more concise and
> expressive way to define and work with immutable data structures. Below
> is a de
On Sat, Sep 9, 2023 at 1:09 AM David Gebler wrote:
>
> On Fri, Sep 8, 2023 at 2:12 PM Lanre Waju wrote:
>
> > Dear PHP Internals,
> >
> > I am writing to propose a new feature for PHP that introduces the
> > concept of structs. This feature aims to provide a more concise and
> > expressive way to
On Fri, Sep 8, 2023 at 2:12 PM Lanre Waju wrote:
> Dear PHP Internals,
>
> I am writing to propose a new feature for PHP that introduces the
> concept of structs. This feature aims to provide a more concise and
> expressive way to define and work with immutable data structures. Below
> is a detai
On Fri, 8 Sept 2023 at 14:12, Lanre Waju wrote:
> Dear PHP Internals,
>
> I am writing to propose a new feature for PHP that introduces the
> concept of structs. This feature aims to provide a more concise and
> expressive way to define and work with immutable data structures. Below
> is a detail
Hi internals!
I think it can be useful for structured data obtained from decoding JSONs
or from a relational database. However, maybe there is an even better idea,
which combines the best of two worlds: the world of your structs RFC, and
native PHP arrays - something like "array shapes".
For inst
I really like the idea of making structs opaque in that sense,
definitely going to put it to vote in the RFC. I agree with the decision
to exclude methods from structs, as they are intended to be pure data
types and If methods are required, classes can be used instead. I guess
based on the resp
1 - 100 of 400 matches
Mail list logo
