Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties
On 23 November 2023 01:37:06 GMT, Claude Pache wrote: >What you describe in the last sentence is what was initially designed and >implemented by the RFC: https://wiki.php.net/rfc/typed_properties_v2 (section >Overloaded Properties). > >However, it was later changed to the current semantics (unset() needed in >order to trigger __get()) in https://github.com/php/php-src/pull/4974 Good find. So not only is it not specified this way in the RFC, it actually made it into a live release, then someone complained and we rushed out a more complicated version "to avoid WTF". That's really unfortunate. I'm not at all convinced by the argument in the linked bug report - whether you get an error or an unexpected call to __get, the solution is to assign a valid value to the property. And making the behaviour different after unset() just hides the user's problem, which is that they didn't expect to *ever* have a call to __get for that property. But I guess I'm 4 years too late to make that case. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - static modifier for classes
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 specific RFC either
> way - a *similar enough* result is already possible by grouping static
> methods in an abstract class, but 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/incomplete builtin
> functionality.
>
> Despite the way some treat it, this isn't the composer internals list, nor is
> composer a required or even bundled part of PHP.
>
>
> Does that mean you shouldn't use composer? No, if it works for your project,
> that's great.
>
> Does that mean gaps in the php language/standard library should be
> automatically ignored/glossed over because composer may provide a
> work-around? Also, no.
>
>
> PHP has for a very long time stood out amongst other web-focused languages
> for having a very rich standard library out of the box ('batteries included',
> I think the cool kids would say now).
>
> Let's please not take PHP in the direction of "modern JavaScript" where
> language deficiencies mean that an entire alphabet of constantly changing
> third-party tooling is required to do anything but the simplest tasks.
>
>
> Cheers
>
>
> Stephen
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hello,
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 in the functions themselves, which isn't
quite the same thing). Two, you still have inheritance that you can
use with static functions. You can't really have inheritance with
regular functions unless you are strictly passing around closures.
Third, static functions can also use traits (in theory) to allow for
code reuse. Fouthly, not everyone is writing s Symfony/Laravel
application that needs highly testable code and might just be throwing
a prototype together -- static classes could hold static configuration
for the app.
In something like C#, static classes are used as a way to extend parts
of the language.
One thing for Lanre: please do not remove the requirement to
explicitly mark a method as static with this. As someone who has read
very long readonly classes, when you make a change, you usually don't
find out it is readonly until you make that change. This is because
the "readonly" is at, and only at, the very top of the class. Now, if
you need to make the class non-readonly, but want to keep all the old
variables readonly, you have to make dozens of changes. Please, for
the life of sane refactoring, don't make "static class" a shortcut for
not being explicit, just make it so that things MUST be declared
static. Long classes are (unfortunately) a thing, and it makes
everything more obvious as to what is going on. Further, removing
static from the class, the class should still function, IMHO.
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - static modifier for classes
> 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 by grouping static methods in
an abstract class, but 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/incomplete builtin functionality.
Despite the way some treat it, this isn't the composer internals list, nor is
composer a required or even bundled part of PHP.
Does that mean you shouldn't use composer? No, if it works for your project,
that's great.
Does that mean gaps in the php language/standard library should be
automatically ignored/glossed over because composer may provide a work-around?
Also, no.
PHP has for a very long time stood out amongst other web-focused languages for
having a very rich standard library out of the box ('batteries included', I
think the cool kids would say now).
Let's please not take PHP in the direction of "modern JavaScript" where
language deficiencies mean that an entire alphabet of constantly changing
third-party tooling is required to do anything but the simplest tasks.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP-8.1 open for bug fixes UNTIL 25 Nov
On 11/21/23 20:17, Ben Ramsey wrote: On Nov 21, 2023, at 18:22, G. P. B. wrote: On Tue, 21 Nov 2023 at 21:10, Ben Ramsey mailto:ram...@php.net>> wrote: We’ve discussed this among release managers, and I’m updating this thread to clarify that I was mistaken about what the dates for supported versions mean. These are the dates up until we will accept patches to a version branch. So, for example, we will accept bug fix patches in the PHP-8.1 version branch until 25 November. This means there may be another release following the end-of-active-support date, if there are bug fixes in the version branch. The PHP-8.1 branch is open for bug fixes UNTIL 25 November. I’m very sorry for the confusion. Does this mean any bug-fix merged into 8.2 already needs to be backported? Or will 8.1 RMs do this? Since this was my mistake, I will help resolve this. Let me know what bug fixes would have otherwise gone into the PHP-8.1 branch, and I’ll take care of merging them. I cherry-picked all the bug fixes from PHP-8.2 that folks didn't commit into PHP-8.1 (because of my earlier misunderstanding). You can see all of these commits here: https://github.com/php/php-src/commits/PHP-8.1?since=2023-11-22=2023-11-23 The only two commits that did not appear relevant to PHP-8.1 were: - https://github.com/php/php-src/commit/5a77870492e8e293a3d12b0e94d91b890ed78197 - https://github.com/php/php-src/commit/4d41dffb4f355872476bae561264c4796eef26b8 So, I did not cherry-pick these two commits into PHP-8.1. Please let me know if any of this looks incorrect, and I'll fix it. Cheers, Ben OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties
> Le 22 nov. 2023 à 23:17, Rowan Tommins a écrit : > > I'm probably going to regret asking this, but is there some reason it works > that way? Is there any chance of changing it to just: > >> Typed properties start off as uninitialized. >> >> Once you've assigned a value, you can't go back to the original >> uninitialized state using unset() >> >> Accessing an uninitialized property will first check for __get, and throw an >> error if that isn't defined. Hi Rowan, What you describe in the last sentence is what was initially designed and implemented by the RFC: https://wiki.php.net/rfc/typed_properties_v2 (section Overloaded Properties). However, it was later changed to the current semantics (unset() needed in order to trigger __get()) in https://github.com/php/php-src/pull/4974 —Claude
Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties
On 22 November 2023 14:12:09 GMT, Nicolas Grekas
wrote:
>I think there is an inaccuracy that needs to be fixed in the after-unset
>state : as noted later in the RFC, magic accessors are called after an
>unset($this->typedProps). This means the state cannot be described as
>identical ("uninitialized') before and after unset() in the first table in
>the RFC. Isn't there some vocabulary in the source that we can use to
>describe those states more accurately?
Oh. Wow. That's more than just inaccurate terminology...
I always assumed the rule was "access to uninitialised properties triggers
__get", not that there was yet another magical state buried in the
implementation. From a user point of view, I find that frankly terrible:
> Typed properties start off as uninitialized, but if you use unset(), you can
> make them *super-uninitialized*.
>
> There's no way to actually see if something's uninitialized or
> super-uninitialized; and once you've assigned a value, you can't go back to
> the original uninitialized, only to super-uninitialized.
>
> Accessing an uninitialized property always throws an error, whereas accessing
> a super-uninitialized property will first check for __get.
I'm not sure choosing a different name from "super-uninitialized" makes much
difference to how that reads.
I'm probably going to regret asking this, but is there some reason it works
that way? Is there any chance of changing it to just:
> Typed properties start off as uninitialized.
>
> Once you've assigned a value, you can't go back to the original uninitialized
> state using unset()
>
> Accessing an uninitialized property will first check for __get, and throw an
> error if that isn't defined.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion
On Wed, Nov 22, 2023 at 2:08 PM G. P. B. wrote: > On Wed, 22 Nov 2023 at 07:36, Mike Schinkel wrote: > > > On Nov 21, 2023 at 11:33 PM, > > 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 now and it seems they have > > gotten the backward compatibility issue nailed, and that pays great > > dividends in developer confidence in the language, i.e.: > > > > > > > https://www.reddit.com/r/golang/comments/17v4xja/anyone_face_issues_when_updating_version_of_go/ > > > > They recently explained in depth how they do it: > > > > https://go.dev/blog/compat > > > > Also see: > > > > https://thenewstack.io/how-golang-evolves-without-breaking-programs/ > > > > Although Go is compiled and PHP is not, I think there still may be > > significant insight that can be gained for PHP by studying how Go is > > handling it and applying any lessons learned. > > > > Go is a "new" programming language, with its 1.0.0 version being from 2012. > It was also designed from the ground up. > > PHP on the other hand wasn't designed, but the language grew organically, > and is 28 years old. > Comparing it to Go, in my opinion, makes no sense. > > We should be comparing ourselves to languages of that age or older, the > most famous example being Python, which did a major BC break between its > version 2 and 3. > But Fortran, C, Perl (with Raku), and for sure others have all made changes > to the language, recent or not, that break compatibility. > > Go even has a cave out that they *may* release a Go 2 specification, which > does not guarantee any backwards compatibility with Go 1. [1] > Even if the current lead engineer says this is "never" going to happen, the > cave out still exists. > > More importantly, it is possible to write cross compatible code, even > without changing anything about is_resource(), if we convert streams to > opaque objects. > It might be tedious and one might need to have redundant instanceof checks > with is_resource() if one does not want to check for a false return, or > duplicate checks for closed resources. > But it is possible, which was *not* the case for Python 2 and 3 as it > changed fundamentally how strings behaved. > > Finally, I think people would have more confidence in the language if it > stopped coming with various foot guns included that need to be explicitly > kept in check by using external tools such as static analysis tools, or > code style tools. > And removing those, or making the language overall more coherent and > consistent, requires us to break backwards compatibility. > > Sincerely, > > Gina P. Banyard > I sympathise with both sides on this topic. As a Software Engineer, not breaking 10-30 years of BC promise is unsustainable, but as a PHP user BC breaks have a heavy impact on legacy codebase written 10~20 years ago. A lot of discussion has happened around this subject, but unfortunately no consensus is ever reached. I've talked about increasing the stability and the pool of maintainers by providing PHP Packages under PHP namespace ( https://externals.io/message/120335#120354). There were a lot of discussions on language evolution and editions that ultimately didn't go much further. Given how much time has passed and how this subject is always present, I now look at this with the optics that both PHP internals devs and PHP users suffer from the same condition of dealing with legacy. Between 1990 up to 2010, give or take, the way software used to be built vastly differs from how software is built today and these old software can be very hard to decommission given their lack of automation tests and inability to be statically analysed. With today's practices, I believe it's easier to introduce BC breaks that affect software written after 2018. And since I believe that, it's a natural consequence for me to believe that if PHP introduced a new `declare(backward_compatibility=0)`, it could be used for users to signal to the engine that 1) we're writing this file after 2023 and 2) we will cover this file with automation tests and/or static analysis tools. PHP Internals wouldn't need to make a huge big-bang BC break all-at-once. Every year new BC breaks could be introduced affecting only the "new engine version". The idea isn't to build several combination of "PHP Editions" as it was discussed in the past, but rather to have a consensus between PHP Internals and PHP Developers that a new Engine is constantly being developed, this engine will break compatibility with the past 20 years of PHP whenever PHP Internals manage to rebuild something (throughout multiple versions), a migration path assumes users will use of Rector, Static Analysers and PHPUnit and the old engine keeps the BC promise in order to allow old software to keep running, but is expected to degrade in performance and to only support new stuff if it has no added burden
Re: [PHP-DEV] Ability to session_decode() in a stateless manner?
On Wed, Nov 22, 2023 at 10:06 PM Deleu wrote: > > Hi! > > Earlier today I was working on a small tool to invalidate PHP Sessions in a > legacy system. I quickly found out about the `session_decode()` function, > but unfortunately this function requires an active session and it is > completely stateful, which means when I try to decode a specific session > data, I end up overriding the existing session. > > I also tried combining `ob_start()` with `session_id()`, `session_start()`, > `session_destroy()` and `ob_end_clean()`, but this would still cause some > weird behaviors by sending two PHP Cookies through the Response Headers. > > In an ideal world, I would override `session.serialize_handler` and be done > with it, but that would require invalidating every existing session and > some non-trivial changes in the 20 year old codebase. > > To my original question, is there any exposed API that would give userland > access to the session deserializer algorithm in a stateless manner? > Something like `session_deserialize(string $data): array;`, preferably in a > way that > 1) doesn't require or doesn't conflict with any existing session and > 2) returns the session array without any side effects? > > If not, would this be something that requires an RFC? Are there any > controversial thoughts around it? > > Thanks! > > -- > Marco Deleu Hey Marco, I vaguely remember dealing with something like this about 10 years ago-ish. If I remember correctly, 1. copy the _SESSION var to a temp var 2. clear the _session var 3. decode the session 4. copy the _session var to an output array 5. clear the _session var 6. restore the original _session var Or something like that. I doubt that is immensely helpful, but maybe it is. Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Ability to session_decode() in a stateless manner?
Hi! Earlier today I was working on a small tool to invalidate PHP Sessions in a legacy system. I quickly found out about the `session_decode()` function, but unfortunately this function requires an active session and it is completely stateful, which means when I try to decode a specific session data, I end up overriding the existing session. I also tried combining `ob_start()` with `session_id()`, `session_start()`, `session_destroy()` and `ob_end_clean()`, but this would still cause some weird behaviors by sending two PHP Cookies through the Response Headers. In an ideal world, I would override `session.serialize_handler` and be done with it, but that would require invalidating every existing session and some non-trivial changes in the 20 year old codebase. To my original question, is there any exposed API that would give userland access to the session deserializer algorithm in a stateless manner? Something like `session_deserialize(string $data): array;`, preferably in a way that 1) doesn't require or doesn't conflict with any existing session and 2) returns the session array without any side effects? If not, would this be something that requires an RFC? Are there any controversial thoughts around it? Thanks! -- Marco Deleu
[PHP-DEV] Re: [RFC] Pass Scope to Magic Accessors
Hi all, Ilija and I would like to start a discussion about the following RFC: > https://wiki.php.net/rfc/pass_scope_to_magic_accessors > > When using magic methods to access actual properties, respecting their > declared visibility is often desired. Yet, accessing the calling scope to > emulate the visibility restrictions is unreasonably difficult at the > moment. This RFC proposes to pass the calling scope to magic accessors to > make it trivial to get it. > Just a quick heads up on this thread to let you know that I'm withdrawing the RFC. I'm working with Arnaud Le Blanc on a native implementation of lazy objects and I don't need fast access to the calling scope for any other use case. If anyone has, feel free to follow up, but on my side I'm going to focus on that new soon-to-be RFC for lazy objects. Stay tuned :) Even if I'm withdrawing, I'm sending a Big Thank You to Ilija for writing the prototype implementation. Also thank you to everybody who took some time to review the proposal! Cheers, Nicolas
Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion
> More importantly, it is possible to write cross compatible code, even > without changing anything about is_resource(), if we convert streams to > opaque objects. > It might be tedious and one might need to have redundant instanceof checks > with is_resource() if one does not want to check for a false return, or > duplicate checks for closed resources. > Extensions like GD, IMAP, Curl, and FTP were once very "resource heavy", but they already received this migration with next to none disruptions. Shameless plug here (https://php.watch/articles/resource-object) where I track the progress. As these changes were merged in the last couple years, I spent a few hours grepping the Composer top 1000 packages. There were not that many `is_resource` checks, and it was quite easy and straightforward to update them to account for the class objects. I'm supportive of our trajectory so far by slowly but steadily moving resource objects to class objects. I also support that we do not modify `is_resource` to mark resource class objects as a resource. I really look forward to the day that we remove `is_resource` and kill the final resource object in PHP 梁. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion
On Wed, 22 Nov 2023 at 07:36, Mike Schinkel wrote: > On Nov 21, 2023 at 11:33 PM, > 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 now and it seems they have > gotten the backward compatibility issue nailed, and that pays great > dividends in developer confidence in the language, i.e.: > > > https://www.reddit.com/r/golang/comments/17v4xja/anyone_face_issues_when_updating_version_of_go/ > > They recently explained in depth how they do it: > > https://go.dev/blog/compat > > Also see: > > https://thenewstack.io/how-golang-evolves-without-breaking-programs/ > > Although Go is compiled and PHP is not, I think there still may be > significant insight that can be gained for PHP by studying how Go is > handling it and applying any lessons learned. > Go is a "new" programming language, with its 1.0.0 version being from 2012. It was also designed from the ground up. PHP on the other hand wasn't designed, but the language grew organically, and is 28 years old. Comparing it to Go, in my opinion, makes no sense. We should be comparing ourselves to languages of that age or older, the most famous example being Python, which did a major BC break between its version 2 and 3. But Fortran, C, Perl (with Raku), and for sure others have all made changes to the language, recent or not, that break compatibility. Go even has a cave out that they *may* release a Go 2 specification, which does not guarantee any backwards compatibility with Go 1. [1] Even if the current lead engineer says this is "never" going to happen, the cave out still exists. More importantly, it is possible to write cross compatible code, even without changing anything about is_resource(), if we convert streams to opaque objects. It might be tedious and one might need to have redundant instanceof checks with is_resource() if one does not want to check for a false return, or duplicate checks for closed resources. But it is possible, which was *not* the case for Python 2 and 3 as it changed fundamentally how strings behaved. Finally, I think people would have more confidence in the language if it stopped coming with various foot guns included that need to be explicitly kept in check by using external tools such as static analysis tools, or code style tools. And removing those, or making the language overall more coherent and consistent, requires us to break backwards compatibility. Sincerely, Gina P. Banyard [1] https://go.dev/doc/go1compat: > It is intended that programs written to the Go 1 specification will > continue to compile and run correctly, unchanged, over the lifetime of that > specification. At some indefinite point, a Go 2 specification may arise, > but until that time, Go programs that work today should continue to work > even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).
Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties
> Le 21 nov. 2023 à 00:08, Rowan Tommins a écrit : > > I've revised the RFC; it now proposes to keep the implicit "= null" for > untyped properties, although I'm still interested in suggestions for other > strategies around that. Hi, If you really want untyped property not being implicitly initialised to “null” in the long term, here is my suggestion: 1. In 8.next, deprecate untyped property without initialiser, suggesting to add an explicit “= null” (one deprecation notice per class definition containing at least one untyped property without initialiser); 2. In 9.0, an untyped property without initialiser becomes a syntax error; 3. Later, reintroduce untyped property without initialiser with the new semantics. —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties
Hi Rowan, Larry,
Thanks for the RFC.
I think there is an inaccuracy that needs to be fixed in the after-unset
state : as noted later in the RFC, magic accessors are called after an
unset($this->typedProps). This means the state cannot be described as
identical ("uninitialized') before and after unset() in the first table in
the RFC. Isn't there some vocabulary in the source that we can use to
describe those states more accurately?
My initial gut reaction is that both ReflectionParameter and
> ReflectionProperty should treat "omitted" as "mixed", and just evaluate
> their type to "mixed". It is in practice a distinction without meaning, or
> will be after this RFC. That said, I also have an itch telling me that
> there are a few small-but-important edge cases where you would care about
> the difference between mixed and none in reflection, and that I'd be the
> one to run into them, but I cannot think of what they would be.
>
I think this needs to be clarified. I can't think of when this difference
could matter. I never wrote any code that could give any meaning to mixed
vs untyped properties, and many here know that I can write unusual PHP
code. I actually always wondered why we have this difference and I
therefore welcome the RFC.
Maybe this can be evaluated up to the point where we realize that the
change could go into 8.4?
I'd be happy to run a patched PHP on some codebases I maintain to see how
it goes.
Nicolas
Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties
On Tue, Nov 21, 2023 at 12:41 AM Larry Garfield wrote: > > On Mon, Nov 20, 2023, at 11:08 PM, Rowan Tommins wrote: > > On 16/11/2023 20:41, Rowan Tommins wrote: > >> Hi all, > >> > >> I have finally written up an RFC I have been considering for some > >> time: Harmonise "untyped" and "typed" properties > >> > >> RFC URL: https://wiki.php.net/rfc/mixed_vs_untyped_properties > > > > > > I've revised the RFC; it now proposes to keep the implicit "= null" for > > untyped properties, although I'm still interested in suggestions for > > other strategies around that. I have also added discussion of variance > > checks (thanks Claude for the tips on that). > > Thanks. It's looking pretty good, and should simplify things considerably. > > > While doing so, I checked Reflection, and am unsure how to proceed. > > Currently ReflectionParameter shows a difference between "function > > foo($bar)" and "function foo(mixed $bar)", even though these are > > analysed as equivalent in inheritance checks. Should ReflectionProperty > > also retain this distinction? Was the possibility discussed when "mixed" > > was introduced of using a ReflectionType of mixed for both cases? > > I don't recall any discussion of ReflectionType when mixed was added, no. > > My initial gut reaction is that both ReflectionParameter and > ReflectionProperty should treat "omitted" as "mixed", and just evaluate their > type to "mixed". It is in practice a distinction without meaning, or will be > after this RFC. That said, I also have an itch telling me that there are a > few small-but-important edge cases where you would care about the difference > between mixed and none in reflection, and that I'd be the one to run into > them, but I cannot think of what they would be. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hmmm, > That said, I also have an itch telling me that there are a few > small-but-important edge cases where you would care about the difference > between mixed and none in reflection, I'd also probably run into them, and the only one I can think of will be moot after this RFC: - `unset($this->var)` to use magic methods instead of the properties in some older proxies Other than that, I can't think of anything, though that isn't really important for reflection... Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - static modifier for classes
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 have static members, > so please elaborate on the maintenance burden that adding static to a class > as that could help explain better, i mean what feature doesn't have technical > debt associated with it? The new JIT engine? That is his point: The benefit has to outweigh the debt and for something like a class modifier this can lead to a matrix of possible combinations, complication things down the line. >>> 3. It is entirely opt-in. If you hold reservations about using static >>> classes, you can simply choose not to use them. >> This is a spurious and disingenuous argument, even if it gets trotted out >> frequently on many RFCs. I'm not picking on you in particular here, but >> it's a bad argument to use, period, 99% of the time, no matter who is saying >> it. > If you insist, Mr. Larry. I’m with Larry there: Being able to just ignore new features is sometimes helpful (i.e. avoids the discussion about BC) but not a strong argument on *why* something should be added. This lists very much also cares about the implementation and maintenance costs as well as the simplicity/consistency of PHP. Being opt-in just does not carry much weight in that context. >> Similarly, if we add a static marker to classes, that means all future >> improvements to classes need to consider "but what if the class is static?" >> Eg, there was discussion a while back about `data` classes. What happens if >> you have a `static data class`? Is that a syntax error? Does it work? If >> it works, what does "work" mean? What about sealed classes? Can you have a >> sealed static class? What would that mean? Those are questions that would >> need to be answered, because this feature exists. > Either i'm in an alternate reality where the data classes and sealed classes > rfcs passed, or I've just been straw-manned. Either way, is it really that > difficult to decide on as a community what a static data class implies? We > have already established that a static class means all the members are > static, but i can try to dumb it down for you if need be. Being a long time member of this list (even though with only very occasional contributions to the source code) I have to say: There is a wide range of experience in both language design and implementation (for both PHP and in general) represented here, some members coming from an almost exclusively language-user point of view. And that is a great thing! But I’d recommend to not underestimate the knowledge contributed by people who have been involved for some time and possibly even learned from previous mistakes :-) Having said all that I just wanted to add that I would most probably vote against static classes even though we use class-as-a-namespace here sometimes but still don’t feel the need for it to being a language feature for the reasons mentioned by Rowan and Larry. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
