On Wed, 28 Apr 2021 at 15:31, Nikita Popov wrote:
> On Wed, Mar 24, 2021 at 5:20 PM Larry Garfield
> wrote:
>
> > Greetings, Internalians.
> >
> > Some months back I proposed an RFC for short functions.
> >
> > https://wiki.php.net/rfc/short-functions
> >
> > After some discussion, I put it on
On Wed, 28 Apr 2021 at 14:30, Guilliam Xavier wrote:
>
> Forwarding to the list, and answering:
>
Please don't do that.
He was blocked from the list for repeatedly derailing conversations.
After someone has been banned from the mailing list, forwarding their
emails to the list is not a good
Re-forwarding to the list (please stop replying to me in private, thanks).
Also re-answering but I will stop there because that's too much digression
for a partial quote of my initial message.
On Wed, Apr 28, 2021 at 5:30 PM Tony Marston
wrote:
> On 28/04/2021 14:30, Guilliam Xavier wrote:
> >
On 28/04/2021 15:31, Nikita Popov wrote:
My suggestion would be to allow use(&$count) on fn(), which allows capturing
certain variables by reference rather than by value.
It might be rather confusing for the use block to sometimes mean
"capture exactly these variables", and sometimes mean
On 28.04.2021 at 16:47, Nikita Popov wrote:
> On Wed, Apr 28, 2021 at 4:18 PM Joe Watkins wrote:
>
>> That's a good point.
>>
>> I suppose the most we can do is prevent accidental committing of such
>> things.
>>
>> Appears to be two "solutions" ...
>>
>> We could distribute a pre-commit hook,
On Wed, Apr 28, 2021 at 4:18 PM Joe Watkins wrote:
> That's a good point.
>
> I suppose the most we can do is prevent accidental committing of such
> things.
>
> Appears to be two "solutions" ...
>
> We could distribute a pre-commit hook, which is somewhere between "not
> bad", and "pretty
On Wed, Mar 24, 2021 at 5:20 PM Larry Garfield
wrote:
> Greetings, Internalians.
>
> Some months back I proposed an RFC for short functions.
>
> https://wiki.php.net/rfc/short-functions
>
> After some discussion, I put it on hold to ensure that it was compatible
> with the other discussion
Actually the detached signatures are not part of the normal commit process
(doesn't look like they'll be in logs either), but the tag that you need to
make the release archive is ...
So we'd really want restriction on creating tags, somehow ...
Possibly we could also emulate some of the
That's a good point.
I suppose the most we can do is prevent accidental committing of such
things.
Appears to be two "solutions" ...
We could distribute a pre-commit hook, which is somewhere between "not
bad", and "pretty awkward" if your git installation is old.
We could setup one of the
On Tue, Apr 27, 2021 at 4:41 PM Christoph M. Becker
wrote:
> Hi all,
>
> the distributions repo[1] is huge (current ~ 26GiB), and it will grow
> further over time; that causes issues when trying to check it out[2],
> and frankly, I don't see why were having the tarballs in a VCS at all.
>
>
On Wed, Apr 28, 2021, at 7:06 AM, Christian Schneider wrote:
> Am 28.04.2021 um 01:00 schrieb Larry Garfield :
> > However! Classic OOP design patterns are not all that PHP supports, and
> > that's a good thing. The "class" construct, for better or worse, is the
> > syntax for logic objects,
Forwarding to the list, and answering:
On Wed, Apr 28, 2021 at 9:51 AM Tony Marston
wrote:
> On 27/04/2021 17:22, Guilliam Xavier wrote:
> > On Sat, Apr 24, 2021 at 12:55 PM Saif Eddin Gmati >
> > wrote:
> >
> >
> > To me the first sentence of the RFC is debatable:
> >
> >> The purpose of
On Wed, Apr 14, 2021 at 10:31 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened voting on https://wiki.php.net/rfc/static_variable_inheritance.
> Voting closes 2021-04-28.
>
> Please see https://externals.io/message/113219 and
> https://externals.io/message/113594 for related discussion.
>
Am 28.04.2021 um 01:00 schrieb Larry Garfield :
> However! Classic OOP design patterns are not all that PHP supports, and
> that's a good thing. The "class" construct, for better or worse, is the
> syntax for logic objects, value objects, data objects, and control flow
> objects (such as
Ah I see, thanks for the clarification! I only did it this way because when
I did my RFC for fsync, I recall one or two people mentioned they weren't
keen on the bit where it could raise a warning rather than a TypeError -
but I appreciate that one was a completely new function and not a change to
On Wed, 28 Apr 2021 at 12:12, David Gebler wrote:
> Hi internals,
> I've opened a PR to cause compact() to throw a TypeError if its parameters
> are not valid, which I consider to be a fix for what is effectively a bug
> whereby logical errors in user code can be silently swallowed.
>
> GPB has
Hi internals,
I've opened a PR to cause compact() to throw a TypeError if its parameters
are not valid, which I consider to be a fix for what is effectively a bug
whereby logical errors in user code can be silently swallowed.
GPB has done an initial review and left a comment
On Wed, Apr 14, 2021 at 10:22 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened voting on https://wiki.php.net/rfc/phase_out_serializable.
> The vote closes 2021-04-28.
>
> See https://externals.io/message/112454 and
> https://externals.io/message/113736 for discussions of this RFC.
>
This
On 28.04.2021 at 07:33, Joe Watkins wrote:
> RE vendor lock-in: Any provider we may move to in the future is going to
> have to be based on git,
> and are going to have similar features to github with regard to providing
> signatures.
Vendor lock-in is a good point, but I see no real issues with
Le 28/04/2021 à 00:25, Christian Schneider a écrit :
The same - "it is more liberty" - could be said about operator overloading,
multiple inheritance and many other language features which lead to people using them in
ways / places I consider harmful. So I'd rather not have them in my language
20 matches
Mail list logo
