Hello Kalle, Sara
On Wed, 6 May 2020 at 17:52, Kalle Sommer Nielsen wrote:
> Den tir. 5. maj 2020 kl. 21.05 skrev Sara Golemon :
> > I assume you're already familiar with
> > https://github.com/php/php-src/blob/master/docs/release-process.md as
> our
> > official process documentation.
> >
> >
Hi Nikita,
Nikita Popov wrote:
On Thu, Mar 26, 2020 at 2:30 PM Nikita Popov wrote:
> I think the best answer to this question may be to forbid the use of
attributes on promoted properties entirely, because there is no unambiguous
interpretation for them. I also think that using attributes
> On May 6, 2020, at 4:14 PM, Rowan Tommins wrote:
>
> Hi Mike,
>
> On 06/05/2020 20:48, Mike Schinkel wrote:
>> Consider simply what we might call "Parameter Blocks." Since PHP always
>> expects a parentheses to follow the function or method name it should be
>> possible to opt-in replace
Hi Mike,
On 06/05/2020 20:48, Mike Schinkel wrote:
Consider simply what we might call "Parameter Blocks." Since PHP always
expects a parentheses to follow the function or method name it should be possible to
opt-in replace it with a brace-enclosed block of parameters instead since it would
Hi John,
On 6 May 2020 19:18:41 BST, John Bafford wrote:
You're not wrong here, but, I think that's an (critical) implementation
detail of Objective-C and Smalltalk that is not relevant here. Also,
Swift does not use selectors or message passing, unless either
interoperating with ObjC classes,
> On Mar 26, 2020, at 9:30 AM, Nikita Popov wrote:
>
> Hi internals,
>
> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion
>
> This is based on one off the suggestions made in
> https://externals.io/message/109220, and some
Hi Rowan,
> On May 5, 2020, at 16:47, Rowan Tommins wrote:
>
> Hi John,
>
> On 05/05/2020 18:27, John Bafford wrote:
>> I very much do like the idea of named parameters, but I do not like the
>> specific proposal in the linked RFC at all. I think that treating named
>> parameters simply as
Den tir. 5. maj 2020 kl. 21.05 skrev Sara Golemon :
> I assume you're already familiar with
> https://github.com/php/php-src/blob/master/docs/release-process.md as our
> official process documentation.
>
> I'd also like to point you at https://github.com/sgolemon/php-release
> (prebuilt
> on
Hi all,
the POSIX standard doesn't mandate that IPC_PRIVATE has any particular
value; in practise it is often (maybe always) zero, but I think the
constant is important enough to deserve its own PHP userland constant.
It would be useful for shmop_open(), shm_attach() and sem_get(), but
these
On Wed, May 6, 2020, at 3:31 AM, Nikita Popov wrote:
> On Tue, May 5, 2020 at 10:27 PM Larry Garfield
> wrote:
>
> > On Tue, May 5, 2020, at 7:35 AM, Nikita Popov wrote:
> >
> >
> > > Performing validation when the getAttributes() call is performed does
> > sound
> > > reasonable to me. We can
On 06.05.2020 14:44, Nikita Popov wrote:
> A possible candidate for this would be ULID (https://github.com/ulid/spec),
> which is basically timestamp + random + base32 encoding. The timestamp part
> makes ULIDs approximately lexicographically orderable, the random part
> makes sure things are
On Wed, May 6, 2020 at 2:34 PM Rowan Tommins
wrote:
> On 5 May 2020 09:42:19 BST, Arvids Godjuks
> wrote:
> >So in my opinion, a better replacement for uniqid is needed - have it
> >generate a bigger string with more entropy and better underline algorithm,
> >but it being time-based should be a
On Tue, May 5, 2020 at 8:38 PM Lynn wrote:
>
>
> On Tue, May 5, 2020 at 8:22 PM Nikita Popov wrote:
>
>> Anyway. Your point that named arguments expand the API surface has been
>> acknowledged. I don't think this issue is really avoidable, it's a rather
>> fundamental trade-off of named
On Wed, 6 May 2020 at 13:34, Rowan Tommins wrote:
>
> On 5 May 2020 09:42:19 BST, Arvids Godjuks wrote:
> >So in my opinion, a better replacement for uniqid is needed -
>
> You're right that the requirements for "random" and "unique" are distinct.
> Perhaps what we need is a unique_string
On 5 May 2020 09:42:19 BST, Arvids Godjuks wrote:
>So in my opinion, a better replacement for uniqid is needed - have it
>generate a bigger string with more entropy and better underline algorithm,
>but it being time-based should be a thing stiff. And do not call it a
>"random_string" or
On 06.05.2020 at 12:52, G. P. B. wrote:
> On Wed, 6 May 2020 at 12:20, Xinchen Hui wrote:
>
>> mixing declarations and codes sometimes brings unexpected
>> varaibles overriden and hard to debugging.
>
> In a perfect world we would be able to enable the -Wshadow GCC
> compiler warning which would
Benas IML wrote:
> Is there any update on the RFC? Given that there isn't much discussion and 2
> weeks have passed, ...
The "two weeks" thing is a minimum.
I personally would prefer if most discussions were longer than that
whenever possible.
It's entirely possible for someone to not have
On Wed, 6 May 2020 at 12:20, Xinchen Hui wrote:
> mixing declarations and codes sometimes brings unexpected
> varaibles overriden and hard to debugging.
>
> thanks
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
In a perfect world we would be able to enable the -Wshadow GCC
On Wed, May 6, 2020 at 6:20 PM Xinchen Hui wrote:
>
> Hey:
>
> On Wed, May 6, 2020 at 3:32 PM Christoph M. Becker
> wrote:
>
>> Hi all,
>>
>> since master requires (mostly) C99 compliant compilers anyway, I wonder
>> if we like to update our coding standards[1], to reflect:
>>
>> * that we
Hey:
On Wed, May 6, 2020 at 3:32 PM Christoph M. Becker
wrote:
> Hi all,
>
> since master requires (mostly) C99 compliant compilers anyway, I wonder
> if we like to update our coding standards[1], to reflect:
>
> * that we require (mostly) C99 compliant compilers (instead of ANSI-C
> compliant
On Tue, May 5, 2020 at 10:27 PM Larry Garfield
wrote:
> On Tue, May 5, 2020, at 7:35 AM, Nikita Popov wrote:
>
>
> > Performing validation when the getAttributes() call is performed does
> sound
> > reasonable to me. We can also add a class flag to perform this validation
> > only once (if it is
On Wed, May 6, 2020 at 9:32 AM Christoph M. Becker
wrote:
> Hi all,
>
> since master requires (mostly) C99 compliant compilers anyway, I wonder
> if we like to update our coding standards[1], to reflect:
>
> * that we require (mostly) C99 compliant compilers (instead of ANSI-C
> compliant
W dniu 06.05.2020 o 09:43, Christoph M. Becker pisze:
On 06.05.2020 at 08:25, Maciej Sobaczewski wrote:
I'm on the fence when it comes to the feature itself so I will skip that
part entirerly but I'd like to draw attention to one more problem. Many
PHP Manual translations translate the
On Wed, May 6, 2020 at 8:25 AM Maciej Sobaczewski wrote:
> Hi Nikita!
>
> W dniu 05.05.2020 o 15:51, Nikita Popov pisze:
> > Hi internals,
> >
> > I've recently started a thread on resurrecting the named arguments
> proposal
> > (https://externals.io/message/109549), as this has come up
On 06.05.2020 at 08:25, Maciej Sobaczewski wrote:
> I'm on the fence when it comes to the feature itself so I will skip that
> part entirerly but I'd like to draw attention to one more problem. Many
> PHP Manual translations translate the parameter names, too - both in
> text, as well as in the
Hi all,
since master requires (mostly) C99 compliant compilers anyway, I wonder
if we like to update our coding standards[1], to reflect:
* that we require (mostly) C99 compliant compilers (instead of ANSI-C
compliant compilers)
* that mixing of declarations and statements is fine
* that
Hi Nikita!
W dniu 05.05.2020 o 15:51, Nikita Popov pisze:
Hi internals,
I've recently started a thread on resurrecting the named arguments proposal
(https://externals.io/message/109549), as this has come up tangentially in
some recent discussions around attributes and around object ergonomics.
27 matches
Mail list logo
