Re: [PHP-DEV] RFC Abolish Narrow Margins

Morning Dmitry, I've cleaned up the proposal section to refer to the normative text section, but it remains to make clear that we are applying these rules to all RFCs (including policy amendments). Cheers Joe On Wed, 6 Feb 2019 at 22:12, Dmitry Stogov wrote: > > > On 2/6/19 8:28 PM, Joe

Re: [PHP-DEV] Don't silence fatal errors

On Thu, Feb 7, 2019, 8:07 AM Girgias > The most common case which comes to mind is to suppress erros while file > reading. > Because even if you check a file exists it could be deleted inbetween the > check and the > read command. As you can see this is even written in the documentation [1] > >

Re: [PHP-DEV] Don't silence fatal errors

On Thu, Feb 7, 2019 at 10:07 AM Girgias wrote: > On Thu, 7 Feb 2019 at 02:03, Pierre Joye wrote: > > > Good morning Nikita, > > > > On Tue, Nov 27, 2018, 4:43 AM Nikita Popov > > > > Hi internals, > > > > > > When the silencing operator @ is used, the intention is generally to > > > silence

Re: [PHP-DEV] Don't silence fatal errors

On Thu, 7 Feb 2019 at 02:03, Pierre Joye wrote: > Good morning Nikita, > > On Tue, Nov 27, 2018, 4:43 AM Nikita Popov > > Hi internals, > > > > When the silencing operator @ is used, the intention is generally to > > silence expected warnings or notices. However, it currently also silences > >

Re: [PHP-DEV] Don't silence fatal errors

Good morning Nikita, On Tue, Nov 27, 2018, 4:43 AM Nikita Popov Hi internals, > > When the silencing operator @ is used, the intention is generally to > silence expected warnings or notices. However, it currently also silences > fatal errors. As fatal errors also abort request execution, the

[PHP-DEV] ?????? [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

Sir,I am a senior high student which comes from china.I don not know where you are.And Ifelt very hard to communicate with you in ENGLISH.-- -- ??: "Rowan Collins" : 2019??2??7??(??) 6:21 ??: "Benjamin Morel"; : "PHP

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

On 06/02/2019 22:10, Benjamin Morel wrote: But we digress, can we focus on whether to add another isset()-like construct, or a property_is_initialized() function, ideally with a companion opcode to speed it up? I apologise for the digression. However, there is some relevance, because asking

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

I agree that what you say conceptually makes sense; however, in a pragmatic world we usually deal with a single User class, and at some point we might want to optimize a script that was accepting a User object, but was only using, say its id and name. Doctrine already allows this, with a caveat:

Re: [PHP-DEV] Re: Don't silence fatal errors

On 06.02.2019 at 05:42, Zeev Suraski wrote: > As long as we have a prominent warning about this in our migration guide > alerting people to the associated risk in setups where display errors is on > - I can live with the change as-is. How do we ensure that it doesn't get > lost in the clutter

Re: [PHP-DEV] RFC Abolish Narrow Margins

On 2/6/19 8:28 PM, Joe Watkins wrote: > Afternoon Dmitry, Nikita, > > I've cleaned that up to read "changes to PHP" rather than talking about > merges, apologies for the confusion, just used the wrong words. > > To re-iterate what Nikita said, this is not about changing what requires > an

Re: [PHP-DEV] RFC Abolish Narrow Margins

Hi! > Thanks for the feedback. I have added a new section to the RFC with the > precise change that will be applied to the voting RFC: > https://wiki.php.net/rfc/abolish-narrow-margins#normative_text I think explaining the changes clearly is a good addition, but I wonder if we should be

Re: [PHP-DEV] RFC Abolish Narrow Margins

> I'll reiterate my main two issues with this RFC: > - I do think that we need 50%+1 votes for certain decisions. Naming the > next version of PHP, or even deciding to release it outside of the yearly > cycle should not require a 2/3 vote. It's not so much erring on the side > of being

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

On Wed, 6 Feb 2019 at 15:21, Benjamin Morel wrote: > You're right, in most of the cases properties SHOULD be set by the > constructor. I do find the current behaviour interesting, however, from a > data mapper point of view: you might want to retrieve a partial object from > the database, and

Re: [PHP-DEV] RFC Abolish Narrow Margins

Afternoon Dmitry, Nikita, I've cleaned that up to read "changes to PHP" rather than talking about merges, apologies for the confusion, just used the wrong words. To re-iterate what Nikita said, this is not about changing what requires an RFC, and not about forcing every change to require an RFC;

[PHP-DEV] VCS Account Request: bariseser

Translating the documentation -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Abolish Narrow Margins

On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov wrote: > > > On 2/6/19 11:50 AM, Nikita Popov wrote: > > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins wrote: > > > >> Afternoon internals, > >> > >> Some time ago I brought up for discussion: > >> https://wiki.php.net/rfc/abolish-narrow-margins > >> >

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Mon, 4 Feb 2019 at 23:46, Zeev Suraski wrote: > > I've been doing a horrible job at explaining myself if that's what you think > I'm trying to do. As I said before, I think the difficulty has been caused by presenting a complete set of solutions to multiple problems at once, without

Re: [PHP-DEV] RFC Abolish Narrow Margins

On 2/6/19 11:50 AM, Nikita Popov wrote: > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins wrote: > >> Afternoon internals, >> >> Some time ago I brought up for discussion: >> https://wiki.php.net/rfc/abolish-narrow-margins >> >> I intend to bring this up for vote in the next few days. >> >> Cheers

Re: [PHP-DEV] [VOTE] Making stdClass iterable

On Tue, Feb 5, 2019 at 1:46 PM Rowan Collins wrote: > On Tue, 5 Feb 2019 at 17:25, Craig Duncan wrote: > > > The *iterable* type accepts a plain array, but not an object that is used > > to represent a plain array, that's surprising to me. > > > > > I think this notion of stdClass as "an object

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

> > We already have a function property_exists(). I don't know if it covers > the case you want, though. property_exists() returns whether the property is defined (as opposed to initialized) in the given class / instance: class A { > private int $id; > } > $a = new A; >

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

On Wed, 6 Feb 2019 at 15:21, Benjamin Morel wrote: > Thanks for the pointer! I can see from this thread that another PR has > been merged just over a month ago, to implement a ZEND_ARRAY_KEY_EXISTS > opcode to overcome the performance penalty of array_key_exists(): >

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

> > Reflection is not slow: it is only slow if you instantiate it continuously. Even when pre-instantiating the ReflectionProperty objects, it's still 2.5x slower than a closure-based approach, according to my benchmarks (linked below), so if possible, I'd like to avoid using Reflection for this

Re: [PHP-DEV] 2016 TestFest, did the tests written then ever get merged?

> On Feb 6, 2019, at 01:22, Peter Kokot wrote: > I can help sort this mess. A separate fork out of the php/php-src was > not such a good idea. Sorry. I made many poor decisions around how I managed that entire event. It’s my own personal Fyre Festival. :-( I’m happy to help in any way I can to

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

On 6 February 2019 13:46:32 GMT+00:00, Rowan Collins wrote: >it could be in the form of a new function like >property_is_initialized($object, $propertyName); this would be an >extension >of property_exists, that handles the edge case of "declared with a type >and >then explicitly unset". PS: I

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

On Wed, 6 Feb 2019 at 12:38, Benjamin Morel wrote: > While playing with typed properties, something that annoys me a lot, in the > context of a data mapper, is not to be able to use isset() to check whether > an object's property is initialized. > This sounds like a reasonable problem to

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

On Wed, Feb 6, 2019 at 1:38 PM Benjamin Morel wrote: > Hi Nikita, > > While playing with typed properties, something that annoys me a lot, in > the context of a data mapper, is not to be able to use isset() to check > whether an object's property is initialized. The issue was already there >

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

Heya, Reflection is not slow: it is only slow if you instantiate it continuously. On Wed, 6 Feb 2019, 12:38 Benjamin Morel Hi Nikita, > > While playing with typed properties, something that annoys me a lot, in the > context of a data mapper, is not to be able to use isset() to check whether >

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

Hi Nikita, While playing with typed properties, something that annoys me a lot, in the context of a data mapper, is not to be able to use isset() to check whether an object's property is initialized. The issue was already there with properties that have been explicitly unset(), but will be

Re: [PHP-DEV] Wiki RFC karma request

Hi Adrian, Thanks for your interest in contributing to PHP, the necessary karma has been granted to you. I will just mention that I believe there's more than one person working on annotation proposals as well as declined proposals, it would be a good idea to liaise with current and past authors

[PHP-DEV] Wiki RFC karma request

I'd like to do some work on an Annotation 2.0 RFC. Could someone grant the wiki user amodliszewski the necessary karma? Thanks in advance. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

On 2/6/19 12:26 PM, Nikita Popov wrote: > On Mon, Feb 4, 2019 at 8:30 AM Dmitry Stogov > wrote: > > > > On 2/3/19 9:00 PM, Nikita Popov wrote: > > On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski > wrote: > > > >> >

Re: [PHP-DEV] Wiki RFC karma request

Hi Paul, Thanks for you interest in contributing to PHP, the necessary karma has been granted to you. Cheers Joe On Wed, 6 Feb 2019 at 11:26, Paul Crovella wrote: > I'd like to do some work on a Partial Function Application RFC. Could > someone grant the wiki user pcrov the necessary karma? >

[PHP-DEV] Wiki RFC karma request

I'd like to do some work on a Partial Function Application RFC. Could someone grant the wiki user pcrov the necessary karma? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Abolish Narrow Margins

On Fri, Feb 1, 2019 at 1:38 PM Nikita Popov wrote: > On Fri, Feb 1, 2019 at 6:16 AM Stanislav Malyshev > wrote: > >> Hi! >> >> > Let me reply to the last point first, because I think that's really the >> > crux here: The issue is not that this RFC is very urgent per se, it's >> that >> > it has

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

On Tue, 5 Feb 2019 at 22:25, azjezz wrote: > You are totally right. > > in my opinion the the community site should be targeted to all the PHP > Community ( PHP Developer / Core Developers ) to ask questions about PHP, > discuss the development of PHP and related topics. > > Moderation should be

Re: [PHP-DEV] RFC Abolish Narrow Margins

On Wed, Feb 6, 2019 at 10:50 AM Nikita Popov wrote: > More importantly, while our past RFCs in the area of "packaging" have not > been particularly major, that's isn't a property inherent to the category. > For example, a proposal to introduce regular LTS releases, or to make other > major

Re: [PHP-DEV] [RFC] JIT

On Mon, Feb 4, 2019 at 8:30 AM Dmitry Stogov wrote: > > > On 2/3/19 9:00 PM, Nikita Popov wrote: > > On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski wrote: > > > >> > >>> On 3 Feb 2019, at 16:43, Jan Ehrhardt wrote: > >>> > >>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +): >

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

On Wed, Feb 6, 2019 at 9:43 AM Nicolas Grekas wrote: > > https://wiki.php.net/rfc/consistent_type_errors >>> >>> >>> Would it make sense and be possible to trigger a deprecation notice in >>> PHP 7.4? >>> >>> That might help the ecosystem move forward in a smooth way instead of >>> experimenting

Re: [PHP-DEV] RFC Abolish Narrow Margins

On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins wrote: > Afternoon internals, > > Some time ago I brought up for discussion: > https://wiki.php.net/rfc/abolish-narrow-margins > > I intend to bring this up for vote in the next few days. > > Cheers > Joe > After one day of heated discussion this

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

> https://wiki.php.net/rfc/consistent_type_errors >> >> >> Would it make sense and be possible to trigger a deprecation notice in >> PHP 7.4? >> >> That might help the ecosystem move forward in a smooth way instead of >> experimenting the failure when actually moving to 8. >> > > We generally

Re: [PHP-DEV] [RFC] JIT

On Wed, Feb 6, 2019 at 3:17 PM Dmitry Stogov wrote: > On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote: > > Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller : > >> Shouldn't we introduce annotations instead of relying on doc comments? > > > > Yeah I'm not too happy with that approach either. I

Re: [PHP-DEV] Re: [RFC] Consistent type errors for internal functions

On Wed, Feb 6, 2019 at 12:40 AM Andrea Faulds wrote: > Hi Nikita, > > Nikita Popov wrote: > > I'd like to bring forward the following proposal for PHP 8, which will > make > > (zpp) parameter parsing failures always result in a TypeError (rather > than > > generating a warning+null, depending on

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

On Wed, Feb 6, 2019 at 7:30 AM Nicolas Grekas wrote: > Hi Nikita > > > https://wiki.php.net/rfc/consistent_type_errors > > > Would it make sense and be possible to trigger a deprecation notice in PHP > 7.4? > > That might help the ecosystem move forward in a smooth way instead of > experimenting

Re: [PHP-DEV] [RFC] JIT

On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote: > Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller : >> Shouldn't we introduce annotations instead of relying on doc comments? > > Yeah I'm not too happy with that approach either. I would rather see > another way to do this and like you said;