If you implement scalar objects:
https://github.com/nikic/scalar_objects
Then 80% of global functions (array_*, str_*) will be localized using
scalar object methods ($array->split(), $string->join()) and the PHP
developer's response will be positive.
Thanks.
--
PHP Internals - PHP Runtime Devel
On Mo, 2018-02-12 at 14:36 -0600, Michael Morris wrote:
> Any particular reason why "`unicode string `" wouldn't work?
Because this would be a BC break which is really hard to detect. People
might do this (i.e. while generating Markdown output or something about
shell scripting or ...) and this mi
Aren't those different AST nodes?
On 13 Feb 2018 15:34, "Johannes Schlüter" wrote:
> On Mo, 2018-02-12 at 14:36 -0600, Michael Morris wrote:
> > Any particular reason why "`unicode string `" wouldn't work?
>
> Because this would be a BC break which is really hard to detect. People
> might do thi
On Mon, Feb 12, 2018 at 3:35 PM, David Rodrigues wrote:
> It too could causes confusion with single-quote in some fonts, sizes and
> styles.
>
> Is more easy to identify shell_exec() than backtick usage, anyway.
>
> It have exactly the same behaviour than shell_exec(). Do not need adapt
> usage be
Hi internals,
I want to bring up this RFC once again given that now seems to be the right
timing for it. I have previously canceled the vote when I initially
proposed this to land on 7.2 which was seen as too big of a BC for a minor
version. On a second attempt targeting 8.0 I have also canceled t
Consider that people dislike writing \strlen(), they will for sure dislike
writing u"string". Hence reassigning backticks to unicode strings seemed to
me like a possibility.
On 13 February 2018 22:41:54 GMT+00:00, Wes wrote:
>Consider that people dislike writing \strlen(), they will for sure
>dislike
>writing u"string". Hence reassigning backticks to unicode strings
>seemed to
>me like a possibility.
I think a lot of people would dislike writing all their strings in
On 13.02.2018 at 23:41, Wes wrote:
> Consider that people dislike writing \strlen(), they will for sure dislike
> writing u"string". Hence reassigning backticks to unicode strings seemed to
> me like a possibility.
Okay. However, in my opinion, it is a bad idea to suggest a deprecation
of a feat
Hi!
> Actually, for me the only valid argument to deprecate the backtick
> operator is "because it is a shady way to execute a rare and dangerous
> operation". I, personally, would make that the main reason for the
> deprecation proposal, and would move the other arguments to the "future
> scope"
On 2018-02-11 20:41, Wes wrote:
Hello PHPeople, I present to you... the shortest RFC ever.
https://wiki.php.net/rfc/deprecate-backtick-operator
Let me know what you think!
I don't have much of an opinion yet on the issue (observing the
arguments in the discussion so far), but one thing whic
Hi developers,
Trying to resolve the bug #75950 (that after long hours I found that I
couldn't reproduce), I observed that if `zend.assertions >= 0` the
generated code inside `assert()` was indeed executed even if `assert.active
= off`. Naturally the function arguments were evaluated before enteri
11 matches
Mail list logo
