On 09/08/2020 18:14, Chris Riley wrote:
Hi all,
RFC link: https://wiki.php.net/rfc/renamed_parameters
I have spent the weekend working on a final revision for this RFC to
address several of the points brought up.
My opinion on this RFC remains unchanged:
- It would have been a reasonable al
After sending out the email, I found out that I replied to the wrong email,
nevermind... Sorry about that!
Best regards,
Benas
On Sun, Aug 9, 2020, 8:25 PM Benas IML wrote:
> Hey Chris,
>
> thanks for the RFC but I'd like to remind you that we are already past the
> feature freeze. Moreover, it
Hey Chris,
thanks for the RFC but I'd like to remind you that we are already past the
feature freeze. Moreover, it seems that you don't have an actual
implementation as well.
Best regards,
Benas
On Sun, Aug 9, 2020, 8:15 PM Chris Riley wrote:
> Hi all,
>
> RFC link: https://wiki.php.net/rfc/r
Hi internals,
Continuing on my response in https://externals.io/message/61#92 , and
considering ways to enhance named arguments without a BC break
(while minimizing the impact on application/library authors that wish for their
libraries not to be used with named parameters)
I was consid
Hi Chris,
On 26/07/2020 14:52, Chris Riley wrote:
Thanks for the feedback so far. In light of the feedback received both here
and privately, I've made 3 changes to the RFC document
Firstly, a reminder of the guideline in the RFC howto that the link to
the RFC should be included in replies,
On Sun, Jul 26, 2020 at 3:52 PM Chris Riley wrote:
> Hi all,
>
> Thanks for the feedback so far. In light of the feedback received both here
> and privately, I've made 3 changes to the RFC document:
>
> 1. The original option 1, allowing renaming parameters but not requiring an
> explicit opt in
Hi Chris Riley,
I agree with Rowan Tommin's arguments in
https://externals.io/message/61#79 - I wanted named parameters by
default.
Miscellaneous comments:
1. https://wiki.php.net/rfc/renamed_parameters should be moved to "In
Discussion" on https://wiki.php.net/rfc/
2. I think that th
On Fri, Jul 24, 2020 at 4:00 PM Chris Riley wrote:
> Hi all,
>
> Following up from this I've created a draft RFC:
> https://wiki.php.net/rfc/renamed_parameters will move to in discussion
> once
> I've ensured everything important has been captured.
>
> Regards,
> Chris
>
You added PHP 8.0 as a p
I'd be fine with throwing exceptions in PHP 7.4, but maybe a warning
in PHP 7.4 and an exception in 8.0 then?
Things like that can be a pretty stupid error that doesn't get
noticed, and there are probably not many use cases checking the return
to be false and then not throwing an exception.
Regar
Maybe even more sugar? :)
getValueFromDB();
// Methode getValueFromDB() called, if $value not transmitted or null value
public function __construct($value ??= $this->getValueFromDB())
{
//...
}
public function getFromCache()
{
// Methode getValueFromDB() called, once upon init static $
Thank you! I just thought it might have been possible to change
the text between the tags on the RFC page. Good luck
with the voting!
Regards //Björn
Den 2016-03-30 kl. 22:25, skrev Midori Kocak:
Thank you, I removed ‘equal’, you were right.
I could not find a way to change url. Also voting i
Thank you, I removed ‘equal’, you were right.
I could not find a way to change url. Also voting is already started.
Midori
> On 30 Mar 2016, at 22:22, Björn Larsson wrote:
>
> Hi,
>
> Think the word equal should be removed from RFC name so
> it becomes "Null Coalescing Assignment Operator" or
Hi Midori,
Midori Kocak wrote:
Hi,
I changed the name but I really don’ know how to change the url :)
Midori
I don't think you can change the URL. In the past I've seen people
create a new page in the /rfc/ namespace, copy the content there, and
edit the old page to point to the new one.
Hi,
I changed the name but I really don’ know how to change the url :)
Midori
> On 24 Mar 2016, at 21:35, Andrea Faulds wrote:
>
> Hi,
>
> Sara Golemon wrote:
>> Changing "equal" to "assignment" seems to have been the suggestion.
>> I've taken that into the short-ternary version. And as a mi
Hi,
Sara Golemon wrote:
Changing "equal" to "assignment" seems to have been the suggestion.
I've taken that into the short-ternary version. And as a minor edit
(not worth closing/reopening vote) would recommend the same for null
coallesce.
-Sara
The other suggestion was to change "coalesce"
Changing "equal" to "assignment" seems to have been the suggestion.
I've taken that into the short-ternary version. And as a minor edit
(not worth closing/reopening vote) would recommend the same for null
coallesce.
-Sara
On Thu, Mar 24, 2016 at 8:46 AM, Midori Kocak wrote:
> there were no sugg
there were no suggestions. Do you have one?
> On 24 Mar 2016, at 16:36, Björn Larsson wrote:
>
> Den 2016-03-13 kl. 02:59, skrev Andrea Faulds:
>> Hi Midori,
>>
>> Midori Kocak wrote:
>>> Forgive my rookieness and let me introduce my first RFC here:
>>> https://wiki.php.net/rfc/null_coalesce_e
Couldn't agree more :)
//Björn
Den 2016-03-24 kl. 16:49, skrev Sara Golemon:
Changing "equal" to "assignment" seems to have been the suggestion.
I've taken that into the short-ternary version. And as a minor edit
(not worth closing/reopening vote) would recommend the same for null
coallesce.
On 3/22/16 1:34 PM, Stephen Coakley wrote:
On 03/21/2016 11:09 PM, Levi Morrison wrote:
This requires you to query state with `isSome()`. This is hardly any
different from a null case, just more code. We can already accurately
distinguish between `null` and another value.
If we want an option f
On 03/21/2016 11:09 PM, Levi Morrison wrote:
This requires you to query state with `isSome()`. This is hardly any
different from a null case, just more code. We can already accurately
distinguish between `null` and another value.
If we want an option for safer PHP code I think we need a safer
co
On Mon, Mar 21, 2016 at 5:03 PM, Stephen Coakley
wrote:
> On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote:
>>
>> So I want to "return a NULL". I want to express uncertainty, a
>> nonexistence. But I want to express that I will return something. And I
>> want to have this NULL checking at in
On Fri, Feb 19, 2016 at 7:59 AM, Zeev Suraski wrote:
>> On 18 בפבר׳ 2016, at 23:23, Yasuo Ohgaki wrote:
>>
>> Hi all,
>>
>>> On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote:
>>>
>>> Colin O'Dell wrote:
I'd like to propose an RFC to deprecate and eventually remove the "var"
ke
>
> By the time of 8.0 nothing would be different from today. 8.0 is not
> some magic number by which old code ceases to exist.
>
The usage of "var" may continue to decline as folks increasingly adopt the
newer visibility keywords. Perhaps it's too early to make this decision
and this discussion
>
> It would have to be done in 8.0, since removing it would constitute a BC
> break.
>
Thanks for clarifying that Tom! Makes sense to me.
> It's worth noting that there were better reasons for deprecating PHP
> 4-style constructors over the simple redundancy argument. Specifically,
> there was
Hi!
> But is there a strong reason to keep it forever, especially considering its
Yes. It's the same reason - "no reason to remove". When we have action
which on one hand has no tangible benefit and on the other hand has
tangible harm, we should not do it.
> decline in usage? Perhaps by targeti
>
> I think it's a drop in the bucket compare to new features we're adding
> plenty of on every version. These make the language a lot more complex
> than var being an alias to public (not even different syntax).
>
Very true. I'm not proposing this because it's a great new feature. But has
this l
Hi!
> I do have a general question about these types of changes: if the
> deprecation were to land in 7.1, when would the actual removal take place -
> 7.2 or 8.0? Or would that be a voting option?
It would have to be done in 8.0, since removing it would constitute a BC break.
It's worth noting
> On 18 בפבר׳ 2016, at 23:23, Yasuo Ohgaki wrote:
>
> Hi all,
>
>> On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote:
>>
>> Colin O'Dell wrote:
>>>
>>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>>> keyword.
>>
>>
>> I don't have a strong opinion on that, I
> Though if we do get rid of the var syntax, I'd like it if we kept the
> reserved word, because it still might be useful in future for typed
> variables or different variable scoping.
Good idea Andrea! Thanks for that suggestion.
I do have a general question about these types of changes: if the
Hi all,
On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote:
>
> Colin O'Dell wrote:
>>
>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>> keyword.
>
>
> I don't have a strong opinion on that, I guess I'm in favour. It seems like
> a fairly harmless deprecation.
>
> Th
30 matches
Mail list logo
