Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

[Tobias Nyholm]

That is a cool idea. 
But I am not a big fan of having code in strings. Wouldn’t this open the door 
to all kinds of new attacks?

// Tobias

> On 17 Mar 2022, at 23:30, Marco Pivetta  wrote:
> 
> Hey Ilija,
> 
> Overall not a fan: want more `sprintf()` and less interpolation, where
> possible 
> 
> Couldn't we let the construct slowly decay into nothingness, perhaps?
> 
> On Thu, 17 Mar 2022, 23:27 Ilija Tovilo,  wrote:
> 
>> Hi everyone
>> 
>> I'd like to start discussion on a new RFC for arbitrary string
>> interpolation.
>> https://wiki.php.net/rfc/arbitrary_string_interpolation
>> 
>> Let me know what you think.
>> 
>> Ilija

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Tobias Nyholm]

Thank you Sara!
I could not agree more with you. I think this answers to most tweets and 
messages that I’ve seen the past few weeks. 

// Tobias

> On 16 Nov 2021, at 14:20, Sara Golemon  wrote:
> 
> Serious questions for all the folks worried that this is some kind of death
> nail for PHP.
> 
> 1. Do you have code you're responsible for which uses dynamic properties so
> broadly that adding this attribute is a burden?
> 2. Do you know of real code in widespread use which uses dynamic properties
> so broadly that adding this attribute is a burden?
> 
> All I see being bandied about are hypotheticals.  So here's my answers: In
> my entire career (which granted, is only about half actually written IN
> php) I can point to exactly one class* which makes use of dynamic props and
> it would take me a hot minute to add the attribute and commit it to the
> repo (note: This code base is running on 5.x, so it doesn't need it, but it
> can handle the attribute all the same).  I don't consider that hot minute
> to be problematic.
> 
> For those wondering what's the point: Making the engine better is the
> point.  We won't see the payoff in 8.2, or even 9.0, but by 10.0 we should
> be able to be in a better place and have a better engine out of it.
> 
> -Sara
> 
> * Not counting uses of stdClass which is going to implicitly have this
> attribute.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Guidelines for RFC post feature-freeze

[Tobias Nyholm]

Hey Dan. 

I do appriciate to hear your point of view. This thread is now very off-topic. 
With respect to Marco and other people that wants to discuss guidelines for the 
RFCs and the role of RMs, I will not answer you anymore. 

Feel free to reach out to me privately or in a new thread.

// Tobias
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Guidelines for RFC post feature-freeze

[Tobias Nyholm]

Hey Dan.

I see that you read what I wrote and intrepid it in the worst possible way. I 
will try to be more clear and more carefully chose my words in the future. 

I called it an “obvious mistake” because it was clear to me that we missed 
something. We are not bad people or worse developers because we made a mistake. 
We (the community) are also not shielded from making mistakes just because we 
have a voting process. I understand that other people are not consider it to be 
a mistake. That is fine. I am wrong to call it “obvious”. 

>> one way of reading this proposal is that we don’t trust the release managers 
>> to decide what to include and not to include in a release.
> 
> To be clear, I don't trust release managers to decide that. Though
> they are all lovely people, not all of them have a deep enough
> understanding of PHP core to be fully able to evaluate changes.

I think there are over 1000 people with “voting powers”. I assume you trust a 
majority of them to have this “deep enough understanding of PHP core”.

If you don’t trust the release managers to manage the release, then I suggest 
you should improve the way we select new release managers. 


> One of the hardest things to do in an Open Source project is to say
> 'no' to someone when they are making a request that isn't completely
> unreasonable. IMO, it would have been better if the 8.1 RM managers
> had said no to opening the "Nullable Intersection types" RFC,

Yes, but it does not mean that you *have to* say no.
But I do agree with you. The process would have been way better if they said 
“no". Or if they clearly and unanimously said “yes” which would remove focus on 
“it feels rushed” and “we can’t because of feature freeze”.
This is the the extended power I would like the RMs (as a group) to have. 

To be clear, Im not suggesting they should veto every RFC. Just changes during 
feature freeze. Since RMs are experienced open source developers, Im sure they 
know to ask for help privately whenever they need it. 

// Tobias


> On 27 Aug 2021, at 10:44, Dan Ackroyd  wrote:
> 
> Tobias wrote:
> 
>> I know you are not a bad person...
>> 
>> The fact that you unprompted (as far as I can tell) decided to in
>> detail specify how RMs should make their decision about an RFC is
>> giving me a strong signal that you don’t trust the role of the Release
>> Manager. The timing of your RFC is also unfortunate assuming you don’t
>> want to imply they are doing a poor job as they just got some criticism
>> in a different thread.
>> 
>> I may be wrong and the current and previous release managers feel like
>> they really need another policy dictating their work, if so I really
>> hope you worked with a few of them while you drafted this RFC.
> 
> If you're going to call people names, you may as well do it openly,
> rather than through passive aggressive phrasing like this.
> 
> Also, if you could stop describing decisions that you disagree with as
> "obvious mistakes" when the RFC author was pretty clear about the
> intention, and the vote passed 30 - 3.
> 
> Quite a few times you're giving the impression that you think other
> people are dumb if they can't even see this "obvious mistake".
> 
>> And to state something I hope is obvious: I am not accusing you for trying 
>> to reduce the role of Release Manager or anything else.
> 
> You are projecting here.
> 
> You're the person who is proposing giving Release Managers new powers
> to have special RFCs where "vote should not consider “if it is too
> late” or “this is rushed”."
> 
>> To allow the release managers to have this decision power is not a
>> “violation of voter rights”, that is just a silly argument.
> 
> It's a change from what we've had before, and blowing off other
> people's concerns about putting too much power in the hands of a few
> people is condescending.
> 
>> one way of reading this proposal is that we don’t trust the release managers 
>> to decide what to include and not to include in a release.
> 
> To be clear, I don't trust release managers to decide that. Though
> they are all lovely people, not all of them have a deep enough
> understanding of PHP core to be fully able to evaluate changes.
> 
> Coincidentally, it is explicitly listed that the Release Manager role
> does not include deciding what gets shipped -
> https://wiki.php.net/rfc/releaseprocess#rms_role
> 
> "RMs Role - But they are not: Decide which features, extension or SAPI
> get in a release or not"
> 
> Nicolas Grekas wrote:
>> Can you please let me know how that helps?
> 
> It helps point out how obtuse you are being.
> 
> Yeah, everyone gets it, there are quite a few people who commit to
> Symfony who don't like that the "Pure intersection types" RFC only
> implemented a pure intersection type and didn't allow a union type
> with null.
> 
> But having people from that community turn up, call people names, call
> things "obvious mistakes" and try to change what feature freeze means
> e.g.
> 
>> but what is 

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

[Tobias Nyholm]

Just giving my 2 cents: 

> 2. Remove support for dynamic properties entirely. 

I support this RFC and I like the end goal to be to remove the dynamic 
properties entirely. 

Dynamic properties are just confusing for beginners. “This is how you declare 
properties, the scope, the type, name etc.. but you don’t have too…”
I also remember that I’ve fixed more than one bug because I misspelled a 
property name. 

I understand there will be an impact on legacy code but there is help to find 
dynamic properties (static analysers) and there is also a clear upgrade path. 

// Tobias
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Guidelines for RFC post feature-freeze

[Tobias Nyholm]

Hey Marco. 

I know you are not a bad person and Im sure your intention is to bring more 
clarity and to add something that is helpful. 
And to state something I hope is obvious: I am not accusing you for trying to 
reduce the role of Release Manager or anything else. 

> I'm interested in understanding how the proposal gives this impression

The fact that you unprompted (as far as I can tell) decided to in detail 
specify how RMs should make their decision about an RFC is giving me a strong 
signal that you don’t trust the role of the Release Manager. The timing of your 
RFC is also unfortunate assuming you don’t want to imply they are doing a poor 
job as they just got some criticism in a different thread. 

I may be wrong and the current and previous release managers feel like they 
really need another policy dictating their work, if so I really hope you worked 
with a few of them while you drafted this RFC. 


// Tobias
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Guidelines for RFC post feature-freeze

[Tobias Nyholm]

> Tobias Nyholm wrote:
>> then the discussion and the vote should not consider “if it is too late”
>> or “this is rushed”.
> 
> This is a really bad idea. Previously (but not recently), some of the
> more heated RFC discussions moved from being about the RFC to being
> about what are "right" and "wrong" reasons for voting.
> 
> That type of discussion very quickly descends into either name
> calling, or people just refusing to take part in discussions.
> 
> If nothing else, how would you 'prove' that someone has voted for the
> 'wrong reason', and so needs to have their vote discounted?

The issue I have with adding more guidelines for RFCs “post feature freeze” is 
that it removes decision power from the release managers. Ie, one way of 
reading this proposal is that we don’t trust the release managers to decide 
what to include and not to include in a release. 

To allow the release managers to have this decision power is not a “violation 
of voter rights”, that is just a silly argument. 


> The proposal is rooted in making it easier for release managers and rfc
> authors to refine code changes that may or may not be necessary to
> accomplish a previously approved RFC.

Maybe we should hear what the current and previous release managers think? Do 
they feel like they need more policies around their work?

// Tobias
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Guidelines for RFC post feature-freeze

[Tobias Nyholm]

Thank you. 
I appriciate you bring up this issue. 

Situations like this often requires a judgement call rather than something that 
could be defined as a policy. 
I suggest the release managers always should be in agreement before a RFC is 
created during a “feature freeze”. If the release managers agree that a change 
can be added, then the discussion and the vote should not consider “if it is 
too late” or “this is rushed”. I think we can trust the release managers to 
make the correct desiccation without an extra policy. 

// Tobias

> On 23 Aug 2021, at 13:48, Deleu  wrote:
> 
> Hello everyone!
> 
> We recently had the Nullable Intersection Types RFC process in an
> unconventional way starting a new RFC post feature freeze. If memory serves
> me right, another similar incident happened with the Attributes RFC which
> had a syntax that could not be implemented without a secondary RFC [1] and
> went through a secondary RFC which proposed a different syntax [2].
> 
> [1] https://wiki.php.net/rfc/namespaced_names_as_token
> [2] https://wiki.php.net/rfc/attributes_v2
> 
> I would like to gather opinion on a potential Policy RFC that would define
> some guidelines for such a process. As Nikita pointed out [3], the ability
> to refine new features is both important for the developer and undocumented
> for the PHP Project.
> 
> In order to not be empty-handed, I started a gist that can be seen as the
> starting point for this discussion, available at
> https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105.
> 
> Generally speaking, I'm first looking for feedback on whether this is
> something that deserves attention and an RFC or is it so rare that it's
> fine to leave it unchanged. If there is interest in moving forward, I would
> then also be interested in suggestions on things that should be
> included/excluded in the RFC.
> 
> Marco Aurélio Deleu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Tobias Nyholm]

Hey. 

> No mistake: the "pure intersection types" RFC was explicitly designed to 
> avoid scope creep (this RFC).


Just because it was intentional, does not make it less of a mistake. 
I see that we have different views of this. And I understand that you are happy 
with this change, but only for 8.2. 

>  the decision to halt this vote (if desired), is with the RMs,
> not the internal contributors.

Yes, naturally. Sorry if I implied something else. 

// Tobias
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Tobias Nyholm]

> On 15 Aug 2021, at 16:46, Patrick ALLAERT  wrote:
> 
> Le ven. 13 août 2021 à 11:35, Nicolas Grekas  a
> écrit :
> 
>> Hi everyone,
>> 
>> I'm happy to announce that the vote for nullable intersection types is now
>> open:
>> https://wiki.php.net/rfc/nullable_intersection_types
>> 
>> It'll close in two weeks, on the 27th.
>> 
>> Cheers,
>> Nicolas
>> 
> 
> Hi Nicolas,
> 
> I am afraid that this is way too late for PHP 8.1. We are 2 weeks away from
> RC 1 and we are in feature freeze.
> 
> I would recommend closing the vote and re-open it for PHP 8.2 unless I
> missed something that justifies breaking the feature freeze rule.
> 
> @Joe, @Ben Ramsey : your opinion?
> 
> Cheers,
> Patrick


Hey Patrick. 

This has been discussed already. See https://externals.io/message/115554 


TLDR; This is not a feature. It is to correct a mistake which is exactly what 
the stabilisation phase is for. 
Some people still think this should be for 8.2. 
The discussion started 4(!) months before the release of 8.1. It is now more 
than 3(!) months before release of 8.1. 

Some people claim this is being “rushed”. I really don’t think that adding this 
patch 3 months before a release is “rushing it”. 

// Tobias

Re: [PHP-DEV] Unwrap reference after foreach

[Tobias Nyholm]

I’m happy with this too. I’m +1 for most things that makes a smoother developer 
experience. 

//Tobias Nyholm

> On 13 Aug 2021, at 06:44, Hans Henrik Bergan  wrote:
> 
> +1 from me, and yeah lets not care about that edge case, i hope the edge
> gets removed at some point.. (but that's an issue for another thread)
> 
> FWIW if attempts at getting it in 8.2 fails, i would welcome another
> attempt at this for PHP9
> 
> 
>> On Fri, 13 Aug 2021 at 15:29, Nikita Popov  wrote:
>> 
>> Hi internals,
>> 
>> I'd like to address a common footgun when using foreach by reference:
>> https://wiki.php.net/rfc/foreach_unwrap_ref
>> 
>> This addresses the issue described in the big red box at
>> https://www.php.net/manual/en/control-structures.foreach.php. While this
>> is
>> "not a bug" (as our bug tracker can regularly attest), it's rather
>> unexpected, and we could easily avoid it...
>> 
>> Regards,
>> Nikita
>> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Tobias Nyholm]

>> @Larry makes an argument to keep them: 
>> 
>>> Requiring parenthesis now leaves the option open in the future to make them 
>>> optional when doing full mixed types.
>> 
>> 
>> I don’t understand why we should require something that is not needed simply 
>> because it would give us an option to remove it later… Could you elaborate 
>> why this is important? (Im probably missing something)
> 
> The difference is if we make the decision to use the `?X` syntax and we 
> later realize it was a mistake then we are stuck with it. 
> 
> OTOH if we use the (X)|null syntax and later realize it is okay to also 
> allow `?X` PHP could later be changed to allow it.
> 
> The later is the choice that manages future risk better.

I thought Larry was discussing `X & Y | null` vs `(X & Y) | null`. 
I’ve dropped `?X` because Derick had technical arguments against it. 

The way I see it, there is no benefit in requiring the parentheses in `(X & Y) 
| null`. I suggest we use  `X & Y | null`.

>>> Given both of these sets of assertions I would ask the RFC's author and 
>>> proponents what would be a worse outcome?
>> 
>> I don’t see how this question is relevant. We are not seeking compromises at 
>> the moment. We are seeking the best technical solution to a technical issue. 
> 
> 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.  
> 
> Because there is a very real possibility you will get none of what you want 
> if the RFC requires the syntax so many have objected to.
> 
> BTW, I do not have a strong opinion either way, but since I see than many do 
> have a strong opinion I was trying to play arbitrator between two sets of 
> people who each have very entrenched opinions where their opinions are in 
> conflict.  If neither side will budge, nobody wins.  


That is a strange attitude. You are saying that you rather see a release with a 
know flaw than actually trying to find the best solution. 
The release will be in 4 months. There is a process to clearly find issues like 
this. There is plenty of time to review this RFC and release it in beta 2 and 
let people test it. This is not a last minute thing, the process is designed 
for this. 

>>> o, the entire discussion has claimed a "need" for nullable intersection 
>>> types but AFAIIK they have been presented in completely abstract terms; 
>>> i.e. no one has presented any real-world scenarios where they would 
>>> actually use nullable intersection types.  
>> 
>> 
>> The “need” is covered by the discussion about PHP 7.0. See this post as an 
>> example: https://externals.io/message/115554#115563 
>> 
> That message mentioned the need in abstract, but it did not provide any 
> real-world examples.  It claims that there were real-world examples, but did 
> not show any.  
> 
> That message was also not part of the RFC.

The first paragraph under “Rational” mentioned this: 
https://wiki.php.net/rfc/nullable_intersection_types#rationale 


In my world maintaining PHP libraries, it is obvious that 7.0 was missing this 
feature. As Benjamin mentioned, you could see that all libraries that migrated 
from 5.x just skipped 7.0 and went straight to support 7.1. I did the same for 
all my packages because of this reason. I made a misstake to assume that 
everybody had the same “world of maintaining PHP libraries” as I do. 

So the “real world examples” you are looking for is: 
If we don’t merge a version of this RFC in 8.1, PHP packages will not take 
leverage of the inspection types until PHP 8.2. The reason for a package to 
drop PHP 7 support is to be able to use the cool features in PHP 8. This will 
require a major release (something all maintainer should do sparsely). Why 
would I do a new major release if I cannot properly define my API (interfaces)? 
I rather wait to next PHP version where I can express my API and do my major 
release then. 

As the RFC states and Benjamin made extra clear, this is exactly what happened 
with PHP 7.0. 

> 
> Listen, I am trying to help make the RFC better to improve its chance of 
> passing.  If you don't want that, then I will just demure.

> 

Sorry if I sounded (or keep sounding negative). I appriciate you and everybody 
else participate in this discussion. We are all trying to make PHP better and 
we are all trying to move this RFC forward. 

// Tobias

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

[Tobias Nyholm]

> It seems this RFC is actually trying to accomplish two(2) things:
> 
> 1. Add typehints for nullable intersection types to PHP.
> 2. Get PHP to support a preferred syntax for type-hinting nullable 
> intersection types.

Yes of course. You cannot really do #1 without #2. 

I agree with Nicolas that `?X` makes more sense. You add ? before the type. 
If the type is scalar, a class or an intersection type should not matter. But I 
hear some technical arguments from Derick so I won’t argue against that. 

Im fine with the syntax: `X & Y | null`
I don’t think parentheses should be required. From a mathematical perspective 
you want to add parentheses when you want to override the operation order. If 
you remove the parentheses and the expression has the same order of operations, 
then the parentheses is clearly not needed. 

@Larry makes an argument to keep them: 

> Requiring parenthesis now leaves the option open in the future to make them 
> optional when doing full mixed types.


I don’t understand why we should require something that is not needed simply 
because it would give us an option to remove it later… Could you elaborate why 
this is important? (Im probably missing something)

> Given both of these sets of assertions I would ask the RFC's author and 
> proponents what would be a worse outcome?

I don’t see how this question is relevant. We are not seeking compromises at 
the moment. We are seeking the best technical solution to a technical issue. 

> Also, the entire discussion has claimed a "need" for nullable intersection 
> types but AFAIIK they have been presented in completely abstract terms; i.e. 
> no one has presented any real-world scenarios where they would actually use 
> nullable intersection types.  


The “need” is covered by the discussion about PHP 7.0. See this post as an 
example: https://externals.io/message/115554#115563 


——

When reading 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, Mike Schinkel  wrote:
> 
>> 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 everything down about the reasons why here:
>> https://wiki.php.net/rfc/nullable_intersection_types
>> 
>> Please have a look and let me know what you think.
>> 
>> Have a nice read,
>> 
>> Nicolas
> 
> It seems this RFC is actually trying to accomplish two(2) things:
> 
> 1. Add typehints for nullable intersection types to PHP.
> 2. Get PHP to support a preferred syntax for type-hinting nullable 
> intersection types.
> 
> Further:
> 
> A. There seems to be consensus on the value of #1.
> B. There seems to be consensus on using a syntax with parentheses for #1. 
> C. There is a lot of pushback on #2.
> D. The desired syntax in #2 would reduce future flexibility, as Larry 
> Garfield commented. 
> 
> Given both of these sets of assertions I would ask the RFC's author and 
> proponents what would be a worse outcome?
> 
> X. Getting typehints for nullable intersection types added to PHP, but not 
> the desired syntax?
> Y. Not getting typehints for nullable intersection types added to PHP? 
> 
> When answering please consider that #X is the outcome that would not preclude 
> possibly getting #2 at a future date.
> 
> -
> 
> Also, the entire discussion has claimed a "need" for nullable intersection 
> types but AFAIIK they have been presented in completely abstract terms; i.e. 
> no one has presented any real-world scenarios where they would actually use 
> nullable intersection types.  
> 
> It might be helpful — or at least it would be for me — if the RFC could add 
> two or three real-world example use-cases where the author and proponents 
> would actually like to use nullable intersection types in their future PHP 
> code.  
> 
> #jmtcw
> 
> -Mike

Re: [PHP-DEV] Reply to an old thread

[Tobias Nyholm]

Note to self:
Adding “Re: “ before the title does not work. 

=)

https://news-web.php.net/php.internals/115546 
<https://news-web.php.net/php.internals/115546>

// Tobias

> On 21 Jul 2021, at 11:23, Tobias Nyholm  wrote:
> 
> Thank you for your quick reply.
> 
> I am not familiar with https://gmane.io/ <https://gmane.io/>. But I assume it 
> can be used as a workaround. 
> 
> Im still curious if there is any official way to do this. 
> I think we (the php community) should encourage new people to participate in 
> discussions. I don’t think the rule should be 
> 
> > “you need to be subscribed before the interesting discussion starts”. 
> 
> =)
> 
> //Toibas
> 
> 
>> On 21 Jul 2021, at 11:01,  Good Guy  > <mailto:xfs...@hotmail.com>> wrote:
>> 
>> On 21/07/2021 18:46, Tobias Nyholm wrote:
>>> Hey.
>>> Sorry for my beginner questions.
>>> 
>>> I’ve decided to be more active on the mailing list now and to reply to 
>>> different threads. I’ve saw this RFC 
>>> [https://wiki.php.net/rfc/parse_str_alternative 
>>> <https://wiki.php.net/rfc/parse_str_alternative> 
>>> <https://wiki.php.net/rfc/parse_str_alternative 
>>> <https://wiki.php.net/rfc/parse_str_alternative>>] which interest me and I 
>>> would like to rely to to this message: 
>>> https://news-web.php.net/php.internals/115081 
>>> <https://news-web.php.net/php.internals/115081> 
>>> <https://news-web.php.net/php.internals/115081 
>>> <https://news-web.php.net/php.internals/115081>>
>>> 
>>> I was not subscribed at the time, so how would I properly reply to that 
>>> thread in the mailing list?
>>> 
>>> // Tobias
>> 
>> I don't use the mailing list but I get the feeds on gmane. Perhaps you can 
>> try this link:
>> 
>> <news://news.gmane.io/gmane.comp.php.devel 
>> <news://news.gmane.io/gmane.comp.php.devel>>
>> 
>> You need a news reader such as Mozilla Thunderbird or something similar. 
>> This allows you to down all the messages in a particular mail list and then 
>> you can reply from it.
>> 
>> 
>> -- 
>> 
>> With over 1.3 billion devices now running Windows 10, customer satisfaction 
>> is higher than any previous version of windows.
>> 
>> -- 
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php 
>> <https://www.php.net/unsub.php>
>> 
> 

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

[Tobias Nyholm]

Hey. 

I see the RFC [https://wiki.php.net/rfc/parse_str_alternative 
] is just a rename of 
parse_str()

I agree with this. parse_str() is a really confusing name and it does not 
behave as I expect it to. I very much support changing it to 
parse_query_string() and make sure it gets a return value. 

// Tobias


PS. I hope this message will add as a thread on 
https://news-web.php.net/php.internals/115081 
. 

Re: [PHP-DEV] Reply to an old thread

[Tobias Nyholm]

Thank you for your quick reply.

I am not familiar with https://gmane.io/ <https://gmane.io/>. But I assume it 
can be used as a workaround. 

Im still curious if there is any official way to do this. 
I think we (the php community) should encourage new people to participate in 
discussions. I don’t think the rule should be 

> “you need to be subscribed before the interesting discussion starts”. 

=)

//Toibas


> On 21 Jul 2021, at 11:01,  Good Guy   wrote:
> 
> On 21/07/2021 18:46, Tobias Nyholm wrote:
>> Hey.
>> Sorry for my beginner questions.
>> 
>> I’ve decided to be more active on the mailing list now and to reply to 
>> different threads. I’ve saw this RFC 
>> [https://wiki.php.net/rfc/parse_str_alternative 
>> <https://wiki.php.net/rfc/parse_str_alternative>] which interest me and I 
>> would like to rely to to this message: 
>> https://news-web.php.net/php.internals/115081 
>> <https://news-web.php.net/php.internals/115081>
>> 
>> I was not subscribed at the time, so how would I properly reply to that 
>> thread in the mailing list?
>> 
>> // Tobias
> 
> I don't use the mailing list but I get the feeds on gmane. Perhaps you can 
> try this link:
> 
> <news://news.gmane.io/gmane.comp.php.devel>
> 
> You need a news reader such as Mozilla Thunderbird or something similar. This 
> allows you to down all the messages in a particular mail list and then you 
> can reply from it.
> 
> 
> -- 
> 
> With over 1.3 billion devices now running Windows 10, customer satisfaction 
> is higher than any previous version of windows.
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

[PHP-DEV] Reply to an old thread

[Tobias Nyholm]

Hey. 
Sorry for my beginner questions. 

I’ve decided to be more active on the mailing list now and to reply to 
different threads. I’ve saw this RFC 
[https://wiki.php.net/rfc/parse_str_alternative 
] which interest me and I would 
like to rely to to this message: https://news-web.php.net/php.internals/115081 


I was not subscribed at the time, so how would I properly reply to that thread 
in the mailing list?

// Tobias

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

[Tobias Nyholm]

Thank you all for your input.

I understand that I should be more active on the mailing list to get some
history. I think that is reasonable, but I don’t see why that is important.
I’m not applying based on my C skills, knowledge of processes or my
previous technical arguments. So, I can only assume that you want me to
have history because you want to get to know me better in this forum. Which
means that if I show a pattern to disagree with you (in the general sense),
that would decrease my chances to be granted voting rights.
I’m sure that is not what you mean, but that is what’s implied.

@Kalle, I’ve not been active on those RFCs simply because I either agree or
don’t care. I know it is a poor answer from me, but it is an honest answer.

---

I do find that some of you are making the argument that having voting
access is like being in the “elite” and there should not be too many people
in the elite. I guess it depends on your personality if you choose to see
it that way.

I also saw suggestions that one has to be a good core developer to be able
to influence PHP. I find it particularly strange if it would be a
requirement. Being a frequent and valuable contributor to PHP core would
bring one perspective to the votes. Spending 5.000/hours yearly on
programming PHP would bring you another perspective. The group of people
with voting access currently have both perspectives which I think is a good
thing.

--

This thread got way more answers and perspectives than I could imagine. I
do agree with @Andreas Heigl that it would be good with some clearer
processes on how to get and keep(!) voting karma.

I will be more public on the mailing lists and share my thoughts if I have
anything good to share. I’ll revisit this topic in 6-18 months and hope
that you all know me better then.

Regards,
Tobias

On Mon, 19 Jul 2021 at 01:37, Nikita Popov  wrote:

> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 
> wrote:
>
>> Hey.
>> I would like to get karma to be able to vote on RFCs. I understand that
>> voting karma isn’t usually given out to people who write their first
>> mailing list entry.
>>
>> But I do believe I qualify as “Lead developers of PHP based projects
>> (frameworks, cms, tools, etc.)”
>>
>> For those of you who don’t know me, I’ve been working with open source
>> PHP projects since 2015. I am part of Symfony core team, I wrote PSR-18 and
>> was part of the working group for PSR-17. I also maintain Guzzle,
>> webmozart/assert, Flysystem, HTTPlug and the php-http ecosystem and about
>> 50 other packages with more than 100.000 monthly downloads.
>>
>> I think I am the most downloaded PHP maintainer.
>>
>> I have been following the RFCs more closely the past 2 years and I’ve
>> finally gathered some courage to ask for karma. There has not been many
>> (maybe just one or two) RFCs where I wished the vote turned out the other
>> way. So, I don’t think I would have any radical opinions about future RFCs.
>>
>> If I’ve understad the process correctly, I do need someone with a php.net
>> VCS account to sponsor me.
>>
>> My username is: nyholm
>>
>> Regards
>> Tobias Nyholm
>>
>
> Hey Tobias,
>
> My response here is basically the same as the last time the topic came up:
> https://externals.io/message/110936#110937 Voting is just the very last
> step of the RFC process, at which point the proposal can no longer be
> influenced. If you have feedback about a proposal based on your extensive
> experience in PHP's open source ecosystem, then the discussion phase is the
> time to provide it, while it can still influence the proposal, as well as
> other people's view of the proposal.
>
> At least in my personal opinion, I think it's important that people
> granted voting rights as community representatives have at least some
> historical involvement in RFC discussions.
>
> Regards,
> Nikita
>

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

[Tobias Nyholm]

Thank you Kalle for the reply. 

I do admire and respect Ondřej and his work on PHPStan. He is really talented 
and from what I hear a really nice person. But please don’t confuse Ondřej’s 8 
packages with over 100.000 monthly downloads with my 50 packages plus another 
100 in the Symfony organization. 

I have tried to approach PHP internals once before by asking for permission to 
modify some outdated wiki entries. I got rejected by you and after that I 
didn’t feel motivated to work with PHP (source/internals) for a while. I’m sure 
it wasn’t your intention, don’t worry about it. I also know that I have 
modified the manual, or at least I’ve tried because that process is really 
painful. I’m honestly not sure if I managed to submit my changes and if I did, 
I don’t remember if they got accepted or not.

I know there are plenty of things that could be improved, be more inclusive and 
less complicated. For example, the manual pages for Sodium. They were released 
4 years ago and still lots of functions are missing examples, lots of 
parameters/return types are undocumented and it is impossible to understand how 
to use Sodium for someone without a CS degree. The reason why these pages are 
still not fully documented is not because lack of knowledge or lack of 
interest/energy.  

I think PHP’s biggest strength is its large and active community. But in my 
opinion, PHP (source/internals) often miss to benefit from our great community. 
I am happy to help making changes, but I feel like it is an impossible task for 
me… I mean, I cannot even update an outdated wiki entry.

I know I’m not a “project leader” for any of the handful large PHP projects. I 
also know that I am far from the “top 1000 best developers” list. But I know 
that there are not many people (if any) that have a larger impact of user-land 
PHP right now. 

(I do acknowledge that there are people with more impact over the Symfony 
community, the Laravel community, or the cool async community etc.)

The only thing I’m asking for is to be among those 1000+ people that can vote 
on the language’s future. 


// Tobias

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Tobias Nyholm]

Hey.
I would like to get karma to be able to vote on RFCs. I understand that voting 
karma isn’t usually given out to people who write their first mailing list 
entry. 

But I do believe I qualify as “Lead developers of PHP based projects 
(frameworks, cms, tools, etc.)”

For those of you who don’t know me, I’ve been working with open source PHP 
projects since 2015. I am part of Symfony core team, I wrote PSR-18 and was 
part of the working group for PSR-17. I also maintain Guzzle, webmozart/assert, 
Flysystem, HTTPlug and the php-http ecosystem and about 50 other packages with 
more than 100.000 monthly downloads. 

I think I am the most downloaded PHP maintainer. 

I have been following the RFCs more closely the past 2 years and I’ve finally 
gathered some courage to ask for karma. There has not been many (maybe just one 
or two) RFCs where I wished the vote turned out the other way. So, I don’t 
think I would have any radical opinions about future RFCs. 

If I’ve understad the process correctly, I do need someone with a php.net VCS 
account to sponsor me. 

My username is: nyholm

Regards
Tobias Nyholm

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Introduction

[Tobias Nyholm]

I would of course not plan a new summer of code. That is, as you say, a
huge project. I’ll just make sure the Wiki is up to date.

The heading "Current happenings (2010)” is quite sad to see.



Regards
Tobias Nyholm

From: Kalle Sommer Nielsen <ka...@php.net> <ka...@php.net>
Reply: Kalle Sommer Nielsen <ka...@php.net> <ka...@php.net>
Date: 19 november 2016 at 10:53:11
To: Tobias Nyholm <tobias.nyh...@gmail.com> <tobias.nyh...@gmail.com>
Cc: Internals <internals@lists.php.net> <internals@lists.php.net>
Subject:  Re: [PHP-DEV] Introduction

Hi Tobias

2016-11-18 15:04 GMT+01:00 Tobias Nyholm <tobias.nyh...@gmail.com>:
> Hey.
> I’m nyholm.
> I want to update the Google Summer of code page on the wiki to be more
> accurate.
> https://wiki.php.net/gsoc

Sadly we have not had anyone active to organize the GSoC for quite
some years now. You should do a full introduction on the webmasters
list (php-webmas...@lists.php.net)[1] and describe your plan and
intentions for future participation with the GSoC, remember it is a
heavy one man project to do, but hopefully you can build up some
momentum for once again making PHP participate.

[1] http://news.php.net/php.webmaster


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

[PHP-DEV] Introduction

[Tobias Nyholm]

Hey.
I’m nyholm.
I want to update the Google Summer of code page on the wiki to be more
accurate.
https://wiki.php.net/gsoc



Regards
Tobias Nyholm