I don't think there is a valid way to define "fundamental BC breaks" or
"mere BC breaks", all votes will always be a reasonable vote as much as
there are people to vote on it.
Whats special or different about BC break that would require slim margin or
consensus votes on where this is dealing with
On Mon, Sep 16, 2019 at 10:01 AM Peter Bowyer
wrote:
> Hi Benjamin,
>
> I like the proposal.
>
> On Mon, 16 Sep 2019 at 01:40, Benjamin Eberlei
> wrote:
>
>> I am asking about feedback especially on the section "Implementation
>> Details", that explains some key differences to "PHPify" the DOM
Thank you Zeev,
I would say it's something to start a more productive discussion.
Maybe not everybody would agree from the start with what you mentioned but
after resonable talks, it would get to some common conclusions.
If I were to summarize, there needs to be defined the voting process for:
On Tue, 17 Sep 2019, 09:43 Christian Schneider,
wrote:
> Just because there are now policy and process RFCs does not mean we could
> take a step back and limit RFCs again.
>
I don't recall seeing anybody suggesting we can't do this. However the
established process to limit RFCs would be to
I agree with pretty much everything Zeev has said. I've added a few
additional thoughts
On Tue, Sep 17, 2019 at 11:42 AM Zeev Suraski wrote:
> On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield
> wrote:
>
> > Simple question for those that keep arguing that the RFC process is only
> > applicable
On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield
wrote:
> Simple question for those that keep arguing that the RFC process is only
> applicable to a certain subset of issues:
>
> OK, so what's the alternative?
>
> If we wanted to make a structural or governance change to PHP, what is the
>
Hi,
I just noticed that the hash extension has a default-disabled --with-mhash
option, that enables a couple of additional mhash_* functions. From what I
was able to gather, mhash was an old extension that was superseded by hash,
and hash provides a compatibility layer for mhash.
Should these
On Mon, Sep 16, 2019, at 7:10 PM, Mike Schinkel wrote:
> > On Sep 16, 2019, at 6:20 PM, Larry Garfield wrote:
> >
> > I think everyone's in agreement about:
> >
> > 1) Making objects easier to work with.
> > 2) Devs should use objects more.
>
> I am glad we are reaching some common ground. :-)
On Mon, Sep 16, 2019, at 6:56 PM, Stanislav Malyshev wrote:
> Hi!
>
> > For there to be a veto, of the kind that anyone can actually use, it must
> > be established somewhere.
>
> And that's what I am concerned about. Once we start assuming the RFC
> process is not for solving technical
чт, 12 сент. 2019 г. в 16:00, Michał Brzuchalski <
michal.brzuchal...@gmail.com>:
> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without required
On Tue, 17 Sep 2019 at 00:21, Larry Garfield wrote:
> [..]
> I think everyone's in agreement about:
>
> 1) Making objects easier to work with.
> 2) Devs should use objects more.
>
> (Side note: I have an article submitted to php[architect] entitled "Never*
> use arrays" that goes into this topic
Hi,
One of the IT futur, is Container (docker like and kubernetes like) and Single
Page Application...
On the other language the tendancy is to simplify the start time and single
start of the application (only one process start the application runc) and
simplify configuration; and simplify
On Tue, 17 Sep 2019 at 01:10, Mike Schinkel wrote:
> But as I said before, naming is hard — except for abstract examples where
> you can just name it "Something" :-) — and developers often don't know what
> object schema they will need until they have written much of the code. So
> the ability
Am 16.09.2019 um 21:32 schrieb Nikita Popov :
> Thanks for chiming in Rasmus. A few brief thoughts on recent discussions:
>
> * The RFC process encompasses language changes (breaking or non-breaking),
> as well as policy and process decisions. We have a very wide selection of
> precedent cases
14 matches
Mail list logo
