śr., 18 mar 2020, 03:36 użytkownik Jakob Givoni napisał:
> Thank you, Michał, for chiming in :-)
>
> On Tue, Mar 17, 2020 at 10:52 AM Michał Brzuchalski
> wrote:
> > For object initializer, I was hoping to introduce a feature which with
> the benefits of typed properties
> > could reduce the
On Mon, Mar 16, 2020 at 9:07 PM Jakob Givoni wrote:
> Thank you for your feedback so far!
I've rewritten parts of the RFC substantially
(https://wiki.php.net/rfc/compact-object-property-assignment)
so take another look if you too have ever wanted to
create, populate and send an object inside a
On Tue, Mar 17, 2020 at 9:31 AM Rowan Tommins wrote:
> Hm, I see, that does reduce the boilerplate somewhat, although it's still
> split across two classes, and probably therefore two files, which is not
> great.
As an alternative to passive associative arrays, it's a small price to pay for
On Tue, Mar 17, 2020 at 4:33 PM Matthew Brown wrote:
> I don't think it's conflicting _if you insist on brackets_ after the new
> expression. PHP Parser grammar for "new" expressions is
>
> T_NEW class_name_reference ctor_arguments
>
> If you allowed the shorter syntax, ctor_arguments would
Thank you, Michał, for chiming in :-)
On Tue, Mar 17, 2020 at 10:52 AM Michał Brzuchalski
wrote:
> For object initializer, I was hoping to introduce a feature which with the
> benefits of typed properties
> could reduce the boilerplate on initializing object and setting their
> properties in
Hi Levi,
Thank you very much for your feedback! I'll try to answer some of your
concerns.
Chiming in to express my disappointment that `final` wasn't a voting choice.
>
When I started to draft the RFC, I realized that a final property modifier
that I wanted
to propose would be pretty much
Chiming in to express my disappointment that `final` wasn't a voting choice.
1. It's already reserved, so we don't have to worry about a new keyword.
2. Another very popular language that is similar to PHP already uses it (Java).
I voted no for a variety of reasons, which includes:
- It
I don't think it's conflicting _if you insist on brackets_ after the new
expression. PHP Parser grammar for "new" expressions is
T_NEW class_name_reference ctor_arguments
If you allowed the shorter syntax, ctor_arguments would allow an
object_properties entry.
I'm sure Nikita could clarify,
Hi Mike & Rowan & all,
> On Mar 16, 2020, at 13:35, Mike Schinkel wrote:
>
>> Does anyone besides Rowan long for a different property name here? What are
>> your suggestions, if any?
>
> I don't think this is important anymore if we call it Sapi or CGI. It was
> only an issue IMO if if we
Hi!
> Would it be possible to add a feature when voting were people either
> need to type in a one to two sentence reason why they voted "no" on a
> proposal OR select from the reasons that others have already given
> when voting down the specific RFC?
As an optional feature, it might be
> On Mar 17, 2020, at 9:11 AM, Paul M. Jones wrote:
>
>
>
>> On Mar 16, 2020, at 13:29, Mike Schinkel wrote:
>>
>> Hi all,
>>
>> It is a real shame that the PHP voting process has no way to capture a
>> concise description of why people voted against an RFC.
> ...
>> Would it be possible
> On Mar 17, 2020, at 4:44 AM, Christoph M. Becker wrote:
>
> On 17.03.2020 at 09:26, Nikita Popov wrote:
>
>> On Mon, Mar 16, 2020 at 8:09 PM Jakob Givoni wrote:
>>
>>> On Mon, Mar 16, 2020 at 1:29 PM Mike Schinkel wrote:
If we had that we could list the reasons and the number of votes
> On Mar 17, 2020, at 4:26 AM, Nikita Popov wrote:
>
> On Mon, Mar 16, 2020 at 8:09 PM Jakob Givoni wrote:
> On Mon, Mar 16, 2020 at 1:29 PM Mike Schinkel wrote:
> > If we had that we could list the reasons and the number of votes that
> > choose those reasons on the RFC for historical
>
> Both proposals relate a lot to each other: it's one or another, both cannot
> coexist: there is only one meaning for the "readonly" keyword once it's
> bound to some interpretation.
You are right in the sense that the two proposals can't use the same
keyword.
However, I believe we both agree
Nicolas Grekas wrote:
(from the other thread)
> there must be a way to work around the keyword -
> either via reflection or another means.
Can you expand on why there 'must' be a way to work around this? Can
you provide some example code where not being able to change the value
is going to cause
> I'd like to reiterate my answer then: I think your idea and my proposal
> doesn't try to solve the same problem.
>
Like you write in the RFC:
> Although actually “write-once” properties and property accessors are
orthogonal to each other, it's arguable whether we still needed
“write-once”
Hi Jakob,
wt., 17 mar 2020 o 03:08 Jakob Givoni napisał(a):
> On Mon, Mar 16, 2020 at 6:48 AM Jakob Givoni wrote:
> > Let me know what you think!
>
> Thank you for your feedback so far!
>
> I'd be really curios to know what authors of the referenced RFCs think
> about this, f.ex.
> Michał
On Tue, 17 Mar 2020 at 01:47, Jakob Givoni wrote:
> Remember that the RFC explicitly says it's not an object initializer,
> nor does it solve "named parameters" which you mention.
>
I wasn't expecting COPA to "solve" named parameters, just thinking that if
we already had named parameters, we
> I don't think these issues can nor should be figured out later on: they
> are low-level conceptual issues IMHO.
I don't agree. Initialization would for example 100% work, I only removed
it from the proposal at the end because
we'll have more freedom to add new language behaviour until we find
> On Mar 16, 2020, at 13:29, Mike Schinkel wrote:
>
> Hi all,
>
> It is a real shame that the PHP voting process has no way to capture a
> concise description of why people voted against an RFC.
...
> Would it be possible to add a feature when voting were people either need to
> type in a
> I believe we had a long enough and fruitful discussion period,
> so I have just opened the vote at
> https://wiki.php.net/rfc/write_once_properties
> since I didn't want to add any significant change to the proposal
> any more.
>
> The vote will run for 2 weeks and it will be closed on
Sorry, for noise, sent to bad list.
Remi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
Le 17/03/2020 à 11:48, Christoph M. Becker a écrit :
> the tarballs are available at the distributions git repo; or use the
> php-7.3.16 tag.
Usual local QA builds done
Fedora 30 to 31, RHEL 6 to 8
i386, x86_64, NTS, ZTS
Fedora 31 official build
Hi Aleksander,
Thank you for the comment!
You are right, the is missing from there.
I believe we can correct small typos/grammatical errors
as far as the contents of the RFC stays the same. That's
why I've just fixed the issue.
Cheers,
Máté
On 17.03.2020 11:12, Máté Kocsis wrote:
> I believe we had a long enough and fruitful discussion period,
> so I have just opened the vote at
> https://wiki.php.net/rfc/write_once_properties
> since I didn't want to add any significant change to the proposal
> any more.
I'm not sure the RFC can be
Dear Internals,
I believe we had a long enough and fruitful discussion period,
so I have just opened the vote at
https://wiki.php.net/rfc/write_once_properties
since I didn't want to add any significant change to the proposal
any more.
The vote will run for 2 weeks and it will be closed on
On 17.03.2020 at 09:26, Nikita Popov wrote:
> On Mon, Mar 16, 2020 at 8:09 PM Jakob Givoni wrote:
>
>> On Mon, Mar 16, 2020 at 1:29 PM Mike Schinkel wrote:
>>> If we had that we could list the reasons and the number of votes that
>> choose those reasons on the RFC for historical purposes.
>>
>>
On Mon, Mar 16, 2020 at 8:09 PM Jakob Givoni wrote:
> On Mon, Mar 16, 2020 at 1:29 PM Mike Schinkel wrote:
> > If we had that we could list the reasons and the number of votes that
> choose those reasons on the RFC for historical purposes.
>
> Thanks Mike, exactly what I was thinking when I
28 matches
Mail list logo
