On Tue, Jul 30, 2019 at 6:15 PM Johannes Schlüter
wrote:
> On Tue, 2019-07-30 at 13:28 -0400, Bishop Bettini wrote:
> > On the other, I've found it refreshing working in a
> > slender repo that doesn't have all the history and process rules.
> > This is good for external (non-core and non-extensi
On Tue, 2019-07-30 at 13:28 -0400, Bishop Bettini wrote:
> On the other, I've found it refreshing working in a
> slender repo that doesn't have all the history and process rules.
> This is good for external (non-core and non-extension) collaborators,
> particularly allowing write access to those wh
Hi!
> This is good for external (non-core and non-extension) collaborators,
particularly allowing write access to those who wouldn't want or need
write access to engine code.
Yes, in theory. In practice I don't see too many of those flocking to
it, unfortunately. As for process, I think we have e
Hi!
> I strongly doubt that there is anything that people could say that
> would alleviate your concern.
There's a lot of things people could say - for example, a proposal that
does not have the same flaws. If you are fixed on having this proposal
unmodified, then yes, my concerns are not address
On Sun, 28 Jul 2019 at 20:21, Stanislav Malyshev wrote:
>
> Did you actually try to read my argument, of just
> decided to strawman it from the start?
I strongly doubt that there is anything that people could say that
would alleviate your concern.
I could say how nicely my IDE gives me a warning
On Tue, 30 Jul 2019 at 20:09, Zeev Suraski wrote:
>
> If you propose, be ready to discuss it in good faith, including
> with folks with opposing views who take their time to write detailed feedback.
Some of the points raised during discussions are not technical
arguments that can be addressed, so
On Tue, Jul 30, 2019 at 9:09 PM Zeev Suraski wrote:
> On Tue, Jul 30, 2019 at 9:30 PM Bob Weinand wrote:
>
> > > Am 30.07.2019 um 17:14 schrieb Zeev Suraski :
> >
> > > Zeev
> >
>
> Before I answer on point - I'd like to thank you that despite the fact you
> clearly disagree with me - you wrote
Hi!
> If we want to evolve the language without breaking backwards compatibility,
> we need to provide a way for gradual migration of the ecosystem: A library
> should be able to opt-in to breaking changes, while remaining usable by
> downstream consumers. Conversely, an application should be able
On Tue, Jul 30, 2019 at 9:30 PM Bob Weinand wrote:
> > Am 30.07.2019 um 17:14 schrieb Zeev Suraski :
>
> > Zeev
>
Before I answer on point - I'd like to thank you that despite the fact you
clearly disagree with me - you wrote your message in a courteous,
respectful tone.
And now, on point:
>
Hi!
> You can either silently ignore somebody or announce it. You may
> consider it a courtesy to have it announced so that they don't wonder
> why they are not being replied to. For me it's perfectly fine. Sure I
> wouldn't be happy if anyone said that about me, but I would have to
> accept it. E
> Am 30.07.2019 um 17:14 schrieb Zeev Suraski :
>
> On Tue, Jul 30, 2019 at 6:10 PM Levi Morrison
> wrote:
>
>> On Mon, Jul 29, 2019, 10:55 PM Zeev Suraski wrote:
>>
>>
> I think ignoring people is totally acceptable behaviour on this list. May I
>> remind you that in the not distant past thi
On Sun, Jul 28, 2019 at 8:48 PM Stanislav Malyshev
wrote:
>
> As you probably know, we've been running PHP fuzzing under Google's
> OSS-Fuzz[1] project for a while now (and found and fixed some bugs due
> to it).
>
> This has been enabled by the PHP fuzzing API SAPI[2] which currently
> lives in
On Tue, 30 Jul 2019 at 17:27, Mark Randall wrote:
> At the point we're talking about composer integrating callbacks,
> preloading lists etc, isn't it about time that an spl_autoload_list was
> added that accepted the standard composer classmap [class_id => path]
> and forewent most autoload callb
On 30/07/2019 15:55, Rowan Collins wrote:
Yes, I was thinking of something more like Composer packages, rather than
like JS modules: code would mostly work as presently, but with some notion
of being "owned" by a particular package. This doesn't mean all the
functions of Composer would be integra
On Tue, Jul 30, 2019 at 6:10 PM Levi Morrison
wrote:
> On Mon, Jul 29, 2019, 10:55 PM Zeev Suraski wrote:
>
>
I think ignoring people is totally acceptable behaviour on this list. May I
> remind you that in the not distant past this list was called a toxic
> kindergarten and other similar names
On Mon, Jul 29, 2019, 10:55 PM Zeev Suraski wrote:
>
>
> > I'm sorry Stas, but I will not be reading your mails in the future. I
> think you mean
> > well and do raise legitimate points, but I have noticed over a long
> period of time
> > that I find arguing with you to be extremely mentally exha
On Tue, 30 Jul 2019 at 15:08, Nikita Popov wrote:
> 5. Introduce a first-class module/package concept and support per-package
> declares. This is arguably the closest fit for what is needed, but also the
> most complex solution. This is a fairly big problem space and I personally
> do not want to
Thanks everyone for your responses!
I think the discussion resolves around two primary concerns, so let me
address them in turn.
The first is the general approach of using declares as a language-evolution
mechanism. The concern here is that each additional declare fragments the
language and incre
On Tue, 30 Jul 2019 at 11:28, Nikita Popov wrote:
> With that in mind, I don't see an issue with reusing the previous
> call-time pass-by-ref syntax here. The & at the call-site still means that
> the value is going to be passed by refrence (or error), so it's not like
> someone who was around du
On Tue, Jul 30, 2019 at 11:01 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Le mar. 30 juil. 2019 à 10:34, Rowan Collins a
> écrit :
>
> > On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas
> > wrote:
> >
> > > I think enough time has passed since php4's call-by-ref for the syntax
> to
>
Hi Rowan,
wt., 30 lip 2019 o 10:48 Rowan Collins napisał(a):
> I think there's some confusion here, because establishing the concept of a
> package as separate from a namespace is exactly what I proposed.
>
> Here's a previous message (technically in the same thread, but from 18
> months ago) wh
On Mon, Jul 29, 2019 at 5:35 PM Rowan Collins
wrote:
> On Mon, 29 Jul 2019 at 15:41, Nikita Popov wrote:
>
> > This proposal (at least combined with a declare that enforces use of
> > call-site annotations) addresses that concern. out/inout parameters do
> not
> > address this concern, because t
On Tue, 30 Jul 2019 at 10:00, Nicolas Grekas
wrote:
> Call-time pass-by-reference is deprecated since PHP 4.3.0 and triggers a
> deprecation warning since then:
> https://3v4l.org/MFXsJ
>
> That's since Dec 2002.
>
It looks like the history is more complicated than either of us are
remembering.
Le mar. 30 juil. 2019 à 10:34, Rowan Collins a
écrit :
> On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas
> wrote:
>
> > I think enough time has passed since php4's call-by-ref for the syntax to
> > be
> > reused now. I think it's unfair to call the RFC a reminiscent of
> > call-by-ref BTW.
> >
>
>
On Tue, 30 Jul 2019 at 09:12, Michał Brzuchalski
wrote:
> 1) Packages should be non-hierarchical. Perhaps most simply a package name
>> could have exactly two parts, like in composer, so it's clear that there is
>> no implied relationship between two packages.
>>
>
> IMO this would create a lot
On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas
wrote:
> I think enough time has passed since php4's call-by-ref for the syntax to
> be
> reused now. I think it's unfair to call the RFC a reminiscent of
> call-by-ref BTW.
>
Firstly, please let's stop calling this a "PHP 4" feature. It was fully
su
On Tue, Jul 30, 2019 at 10:12 AM Michał Brzuchalski
wrote:
> IMO this would create a lot of problems cause name in Composer Package
> doesn't reflect used namespace declared in autoload, for eg.
>
> Composer package name => used namespace
> ---
> ocramius/package-version => PackageVersions\
> doc
Hi Rowan,
niedz., 28 lip 2019 o 12:15 Rowan Collins
napisał(a):
> 1) Packages should be non-hierarchical. Perhaps most simply a package name
> could have exactly two parts, like in composer, so it's clear that there is
> no implied relationship between two packages.
>
IMO this would create a lo
28 matches
Mail list logo
