Re: [PHP-DEV] [RFC] Property hooks, nee accessors
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.
>
> 1. It's shorter and less typing for what will be a common pattern.
> 2. That makes it consistent between hook implementations. In working on
> examples, I found many cases where I was adding basically the same line to
> multiple hooks on the same class. Making the code easier to copy-paste seems
> like a win.
> 3. It also will be helpful if hook packages are added in the future, as
> they'll need a more "generic" way to access the backing property. (See
> Future Scope.) Eg, "$field = someLogic($value)" applied to a dozen different
> properties; it wouldn't work if it was "$this->specificProperty =
> someLogic($value)".
> 4. We're used to our eyes glossing over "$this->propName", as it's so common.
> Having a separate name to mentally scan for to determine if a property is
> virtual or not seems like it will be helpful in practice.
> 5. There's precedent for it: Kotlin has almost the same functionality as we
> describe here, and uses a `field` variable in the exact same way.
>
> So it's mainly an ergonomics argument rather than a technical one. "Compile
> time macro" means it translates to the same AST as if you'd used
> $this->propName. There's precedent for that. Constructor Property Promotion
> works basically the same way.
With using a common name for say, $value, open the door for a library
of common hook implementations (eventually)?
Maybe something like:
class User {
// snip
public string $fullName { get => FancyLibrary\fullName(...) }
// snip
}
I could imagine something like this would be a huge boon to PHP if it
automatically bound the closure.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property hooks, nee accessors
On Wed, May 10, 2023, at 11:35 AM, Robert Landers wrote:
>> Regarding $field vs. $this->propName, there's a few reasons we went that
>> route.
>>
>> 1. It's shorter and less typing for what will be a common pattern.
>> 2. That makes it consistent between hook implementations. In working on
>> examples, I found many cases where I was adding basically the same line to
>> multiple hooks on the same class. Making the code easier to copy-paste
>> seems like a win.
>> 3. It also will be helpful if hook packages are added in the future, as
>> they'll need a more "generic" way to access the backing property. (See
>> Future Scope.) Eg, "$field = someLogic($value)" applied to a dozen
>> different properties; it wouldn't work if it was "$this->specificProperty =
>> someLogic($value)".
>> 4. We're used to our eyes glossing over "$this->propName", as it's so
>> common. Having a separate name to mentally scan for to determine if a
>> property is virtual or not seems like it will be helpful in practice.
>> 5. There's precedent for it: Kotlin has almost the same functionality as we
>> describe here, and uses a `field` variable in the exact same way.
>>
>> So it's mainly an ergonomics argument rather than a technical one. "Compile
>> time macro" means it translates to the same AST as if you'd used
>> $this->propName. There's precedent for that. Constructor Property
>> Promotion works basically the same way.
>
> With using a common name for say, $value, open the door for a library
> of common hook implementations (eventually)?
>
> Maybe something like:
>
> class User {
> // snip
> public string $fullName { get => FancyLibrary\fullName(...) }
> // snip
> }
>
> I could imagine something like this would be a huge boon to PHP if it
> automatically bound the closure.
$field is only available inside the hook itself, not inside functions called
from it. But that does mean you could do this instead:
class User {
// snip
public string $fullName { get => FancyLibrary\fullName($field) }
// snip
}
Which, yes, should work fine.
If such a library actually became popular, that would be an argument to
implement the "property hook packages" or "property traits" concept that Swift
has, as noted in Future Scope.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] PHP Technical Committee
On Mon, 1 May 2023 at 18:09, Benjamin Außenhofer wrote: > On Fri, Apr 28, 2023 at 12:01 PM Jakub Zelenka wrote: > > > Hi, > > > > The vote is now open for the RFC about introduction of the PHP Technical > > Committee: > > > > https://wiki.php.net/rfc/php_technical_committee > > > I found this idea of a TC interesting on the outset, but after carefully > consideirng I voted no on this RFC because > > a.) i believe it to be too much bearucracy for the little benefit > b.) potentially harmful depending on who is on the TC. > c.) There is also no process of overuling the TC, or voting a TC out due to > no confidence or something. Without the votes known of TC members, voters > of the TC have no insights into who they might want to boot or keep in the > next election. However introducing these data points would make everything > even more complicated. > > Ultimately, already at the moment each controversial change can be asked to > be RFCed and then the voters can decide with arguments made by people > knowledgable in the area. Yes, there is always some politics involved, but > the same would be true of the TC decisions. > So, basically what you have said: "Let's kick the can down the road and let somebody else deal with the issue in the future"? The problem this RFC is trying to solve has happened multiple times. There are numerous cases where a technical committee should have been involved, preventing problematic implementations being put into a release (read-only ended up, by the admission of the authors and multiple other devs, being a mistake in the form it is now) or prevented much-needed maintenance work be done on the code base that has nothing to do with public-facing changes. Also, the point c) is a contradiction. The TC is meant to break indecision, the byproduct of that is that half the people are not getting their way. It's the nature of any decision-making, where you must make a judgement call. So what you are saying here, is you want the decisions not to be made at all, unless everybody sings kumbaya and drinks beer until lights out? -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] [VOTE] PHP Technical Committee
On Mon, 1 May 2023 at 19:29, Jakub Zelenka wrote: > Hi, > > Thanks for the feedback. > > On Mon, May 1, 2023 at 4:09 PM Benjamin Außenhofer > wrote: > > However the main problem with the RFC process is that for purely technical > changes it could result in a set of rules that will limit core development. > When the previous disagreement happened, it ended up with this sort of RFC: > https://wiki.php.net/rfc/code_optimizations . I know that it was later > withdrawn but just imaging the impact of this being accepted and honoured. > And also why should something like this be decided by people that have > nothing to do with a core development? That was actually one of the main > triggers for this initiative and we wanted come up with something sensible > that would decide those sort of things in a better way. > > Cheers > > Jakub > I do want to point out that framing what happened with that RFC as "withdrawn" is analogous to "covering up a murder". The Internals list basically bullied a new contributor to dropping it and made them give up on ever committing their work to the PHP project. Actually, multiple people, because if I understand it correctly, there was at least one colleague of them who also was doing some work and they dropped everything too. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Hi Rowan, > As an aside, I don't think "other deprecations are already more difficult" > is a good argument - it's like saying "yes, I punched him, but not as hard > as someone else already had". I think the change can be defended from other > angles, but wanted to call that out. > I admit that my argument was not a good one, but I intended to mean that most of the suggested alternatives are not too difficult to implement: since numerous other proposals were accepted in the past with a much more difficult upgrade path, I think this aspect of my RFC shouldn't be a deal breaker considering the benefits. Maybe because the function names are so similar? In general, I hate > variable and function names that differ only by an "s", it's far too easy > to misread or mistype them. Maybe "session_set_save_handler_functions"? To be honest, I'm not a fan of using the longer names (session_set_save_handler_functions and stream_context_set_option_array), especially the latter one looks weird to me, and it doesn't go well with stream_context_get_options(). Besides, a most interesting development is that I've just discovered the stream_context_get_params() and stream_context_set_params() functions which do nearly the same what the stream_context_*et_option functions do: the only difference between them is that the latter functions wrap the options inside the "options" key and also has an additional "notification" key. It *is* strictly related, though: the current function has two purposes: > get an option, and set an option; the RFC proposes to split that into two > functions, and there are three ways we can do that: Thanks for the idea, your explanation made sense to me, so finally, I removed assert_options() from my proposal and the deprecation of assert_options() relies on the PHP 8.3 deprecations RFC. Regards: Máté
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Hi Dan (and Larry and Tim who responded to the same topic),
Would leaving the current versions in place and working actually cause
> any maintenance issues?
Yes, unfortunately they cause some maintenance issues: since they don't
have a single
signature, gen_stub.php generates the wrong signature for them in the
manual. For example
https://www.php.net/manual/en/function.stream-context-set-option.php
displays two distinct
signatures, however gen_stub.php only knows one signature, so obviously
generation won't work well:
function stream_context_set_option($context, array|string
$wrapper_or_options, ?string $option_name = null, mixed $value = UNKNOWN):
bool {}
I use gen_stub.php for automatically detecting the outdated
function/method/class signatures which I can then
commit with minimal effort. Actually my doc-en PRs (
https://github.com/php/doc-en/pulls?page=1&q=is%3Apr+is%3Aclosed+author%3Akocsismate
)
are either fixing outdated information in the manual, or ensuring that
gen_stub.php can generate the same
information that we display in the docs. Now, there are only ~50-60
function/method signatures
in master which are not in line with the output of gen_stub.php, and most
of them are due to
overloaded signatures (the rest is due to PHP 8.3 changes which shouldn't
be documented yet).
For reference, the number of outdated function signatures used to be many
hundreds or probably 1000+
when the project started, just before PHP 8.0 came out.
If not, then we could just move really slowly on deprecating them. We
> could deprecate them at some point in the 9.x release cycle and remove
> them in 10.0.
Although I would love to get rid of as many overloaded signatures as
possible due to the above mentioned fact,
I admit that there might be some signatures which other internals would
prefer to phase out slower than me. So
thanks for the idea! Now, the individual votes in the RFC contain 2 options
for removing a signature: a shorter path (deprecation
in PHP 8.4, removal in PHP 9.0) and a longer one (deprecation in PHP 9.0
and removal in PHP 10.0).
Additionally, I wrote a very explicit and detailed list about the suggested
BC compatible alternatives for each deprecation so that
now it should be very clear how difficult it is to replace a
function/method invocation.
The RFC says:
Impact analysis: 1 out of the 2000 most popular PHP packages rely on
> calling session_set_save_handler() with 6 or more arguments.
> I doubt analysing github is going to give a useful measure of the
> impact of this RFC. Functions like session_set_save_handler are going
> to be used in custom code written for a company than in shared
> libraries.
Yes, I'm aware of this glitch, but that's the best I could provide for
estimating the impact of the deprecations.
Cheers,
Máté
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Hi Derick and Tim, Derick, I incorporated most of your suggestions into the RFC with the sole exception of the argument names ($start/$finish,$begi/$end): it would feel odd if these parameters and their related properties were called differently: https://www.php.net/manual/en/class.dateperiod.php#dateperiod.props.start Actually, when we renamed the majority of parameters together with Nikita, this was one of few rules that we had: parameters should be called the same way as the property they initialize. > Please no consecutive uppercase letters in the function name. I find > createFromIso8601 (or createFromIso8601String if find the 'String' > suffix useful) much more readable than createFromISO8601String. > Uppercase acronyms are especially bad if followed by another ucfirst > word, because the word boundary is not immediately visible there. Not > the case here (it's digits), but still bad. Yes, generally, I wholeheartedly agree, but unfortunately I still "had to" go with Derick's suggestion of using consecutive uppercase letters because there is already a DateTime::setISODate() method with the same casing and I want to follow the established naming convention of ext/date. Personally, I like the "String" suffix, probably it makes the name better, but since I don't really care about this problem too much, I'd leave it for Derick to decide about it. Máté
