Hi internals,
I've opened the vote on
https://wiki.php.net/rfc/class_name_literal_on_object.Voting closes
2020-02-11.
Regards,
Nikita
VCS Account Approved: nicolasgrekas approved by pajoye \o/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi internals,
I've opened voting on the "static" return type RFC:
https://wiki.php.net/rfc/static_return_type
Voting closes on 2020-02-11.
Regards,
Nikita
On 28/01/2020 01:06, tyson andre wrote:
I don't plan to change the default name resolution behavior in PHP 9, though,
and if it does change, it might even be according to a different proposal,
so adding 'fallback' as a third option before we know what type of change is
planned
seems premature.
GMail fails to parse the URL correctly, so for users the link is:
https://wiki.php.net/rfc/class_name_literal_on_object
Peter
On Tue, 28 Jan 2020 at 09:15, Nikita Popov wrote:
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/class_name_literal_on_object.Voting closes
>
Le lun. 27 janv. 2020 à 16:10, tyson andre a
écrit :
> > can we please discuss this alternative? In another reply, you link to
> https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead
> >
> > But this new proposal derived from Nikita's idea is different
Hello everybody,
the last days I have experimented a bit with operator overloading in
userspace classes (redefing the meaning of arithmetic operations like +, -,
*, etc. for your own classes).
This could be useful for different libraries which implements custom
arithmetic objects (like money
> Thanks. It's a bit strange to read the objections to the proposal in the RFC.
> That makes it feel like "we" agreed on them - while it's "only" the author's
> opinion. From this part in the RFC:
It's included because https://wiki.php.net/rfc/howto mentions the following:
"Listen to the
On 1/26/2020 2:31 PM, Rowan Tommins wrote:
On 25/01/2020 22:03, Mike Schinkel wrote:
I'm not following the discussion 100% – more like 85% — but it seems
like what we might be saying is the need for a user-land
implementation of a long-running PHP request, one that does not timeout?
It's
On Tue, 28 Jan 2020 at 14:26, Thomas Hruska wrote:
> People tend to write WebSocket servers in NodeJS partly because they
> don't realize that PHP can already do the same. Example:
>
> https://github.com/cubiclesoft/php-drc
I didn't realize, so this is a great share. Thanks.
> WebSocket
> I still don't understand this logic. If my code is written so that it
> needs the current "same namespace fallback to global" behaviour, I don't
> care what the default mode is, or how many other modes there are, I want
> to make sure that file will continue to use that mode. The *only* way to
>
> Le 28 janv. 2020 à 10:50, Nicolas Grekas a
> écrit :
>
> BTW, should we use the word "root" instead of "global"? "global" might have
> a bad connotation, and "root" is the word used in the description of the
> current behavior of PHP:
“Global” is the term used in the manual:
Hi internals,
I'm encountering a SIGSEGV in PHP-FPM on PHP 7.4.2 in a Symfony app. The
bug seems to happen during the rendering of a Twig template; this makes it
hard for me to pinpoint the code that triggers the segfault.
Could you please tell me what the procedure to collect information is, so
On Tue, 28 Jan 2020 at 15:42, tyson andre wrote:
> > In other words, we don't need to know what the future modes are to know
> what modes we have *right now*, and give those modes names.
>
> If strict_types had a name instead of a number, we'd have a similar
> argument
> over whether there
> I'm encountering a SIGSEGV in PHP-FPM on PHP 7.4.2 in a Symfony app. The
> bug seems to happen during the rendering of a Twig template; this makes it
> hard for me to pinpoint the code that triggers the segfault.
>
> Could you please tell me what the procedure to collect information is, so
>
> What do you mean by "weaker"?
Any difference that might be expected by a user when for what differs
between leaving out the setting and setting it to 'fallback'/'default'.
E.g. in my example for `count`, a developer might expect `MyNs\count()`
to continue working as `MyNs\count()` when they
On Tue, 28 Jan 2020 at 15:59, Peter Bowyer
wrote:
> An approach that avoids rewriting, like some form of
> built-in support in the language would be good for this alone.
>
I'd just like to point out that those two things are orthogonal: the fact
that Swoole is distributed as an extension is
Hi internals,
As the last RFC for the day, I've opened voting on
https://wiki.php.net/rfc/variable_syntax_tweaks.
The vote will stay open until 2020-02-11.
Regards,
Nikita
On Tue, Jan 28, 2020, at 10:03 PM, Theodore Brown wrote:
> The RFC mentions two problems it hopes to solve: a minor performance
> decrease, and developers having to deal with ambiguity. However, a
> third problem that I think is just as important to fix is the lack of
> function autoloading
I think that the left operand is the "owner", the magic method handler,
while the right operand is the argument.
So for $object * 5, we will have:
// $object instance
public function __multiply($number): self {
return $this->multiply($number);
}
But for 5 * $object we will have an error.
> On Jan 28, 2020, at 17:14,
> wrote:
>
> Hello everybody,
>
>
>
> the last days I have experimented a bit with operator overloading in
> userspace classes (redefing the meaning of arithmetic operations like +, -,
> *, etc. for your own classes).
>
> This could be useful for different
> On Jan 28, 2020, at 17:55, Michael Cordover wrote:
>
> On Tue, Jan 28, 2020, at 18:47, Ben Ramsey wrote:
>> If you take mutation off the table, then things become easier, IMO. We
>> only need two magic methods:
>>
>> * __toInteger(): int
>> * __toFloat(): float
>>
>> Then, in any
> > That's more of an objection to 'global' than an argument about 'fallback'
> > or 'default'.
> > It isn't suggesting a name to use instead of 'global'.
> >
>
>
> No, it's saying that whatever name you use, the guarantees of behaviour are
> only as strong or weak as decisions we make in the
Hi internals,
I've opened the vote on https://wiki.php.net/rfc/use_global_elements
after weighing the pros and cons of discussed alternative approaches.
Yesterday, I've finished the last set of updates I announced I would do based
on RFC feedback.
(that update was to require the statement 'use
On Tue, Jan 28, 2020 at 8:22 PM tyson andre wrote:
> Hi internals,
>
> I've opened the vote on https://wiki.php.net/rfc/use_global_elements
Thank you for working to address the issue of ambiguous function references.
However, I really don't think this is the right approach.
The RFC mentions
On Tue, Jan 28, 2020, at 18:47, Ben Ramsey wrote:
> If you take mutation off the table, then things become easier, IMO. We
> only need two magic methods:
>
> * __toInteger(): int
> * __toFloat(): float
>
> Then, in any mathematical context, PHP could call the appropriate
> method and use the
On Tue, 28 Jan 2020 at 18:13, tyson andre wrote:
> That's more of an objection to 'global' than an argument about 'fallback'
> or 'default'.
> It isn't suggesting a name to use instead of 'global'.
>
No, it's saying that whatever name you use, the guarantees of behaviour are
only as strong or
> Thank you for working to address the issue of ambiguous function references.
> However, I really don't think this is the right approach.
>
> The RFC mentions two problems it hopes to solve: a minor performance
> decrease, and developers having to deal with ambiguity.
> However, a third problem
28 matches
Mail list logo
