Hi Nikita,
Nikita Popov wrote:
Hi internals,
I would like to propose allowing the use of "new" inside various
initializer expressions: https://wiki.php.net/rfc/new_in_initializers
In particular, this allows specifying object default values for properties
and parameters, and allows the use of
Hi,
Theodore Brown wrote:
Hi internals,
Since the #[] attribute syntax is currently winning the vote, [1]
it makes me wonder if the use of comments starting with # should be
deprecated.
Otherwise it seems like we could be setting ourselves up for long-term
confusion between attributes and
Hi Tyson,
tyson andre wrote:
What are your thoughts on making `123_456_000_000_000_000_000_000n` a shorthand
for `gmp_init('12345600')` (or a call with equivalent results)
(similar to existing backtick string syntax is a shorthand for `shell_exec()`)
We could do that, but
Hey,
Björn Larsson wrote:
Would it then make sense to have it as compile time error in 8.0 and
make it right-associativein in e.g. 8.1?
OTOH, when looking in RFC on top 1000 affected composer packages
it looks like having the change in 8.0 might be a way forward...
r//Björn L
I think 7.4
Hey everyone,
I assume others with php.net accounts also see these messages when
logged into wiki.php.net:
> New release candidate 3 available: 2020-06-09 "Hogfather". upgrade
now! [51.2] (what's this?)
>
> New release candidate 2 available: 2020-06-01 "Hogfather". upgrade
now! [51.1]
Hi,
Nikita Popov wrote:
Regarding the question of what to do with regard to LSP validation and
parameter names changing during inheritance: During internal discussion,
the following option has come up as a possible compromise:
1. When calling a method, also allow using parameter names from
Hi again,
A further and perhaps more important thought: I think the token names
are actually the least confusing part of parser errors, even for the
famous T_PAAMAYIM_NEKUDOTAYIM. Changing it to T_DOUBLE_COLON may not
help much, because the parser only tells you what the next token it
Hi,
G. P. B. wrote:
https://wiki.php.net/rfc/rename-double-colon-token
I have voted No to this, and I hope I can convince some others to do the
same.
T_PAAMAYIM_NEKUDOTAYIM is such a famous token that there is probably
nobody in internals who doesn't know what it means, and for new
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
Hi,
I share Dan's reasons for voting against. I don't think things should go
to a vote before the dust has settled.
Regards,
Andrea Faulds
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello again everyone,
Andrea Faulds wrote:
Hello again,
Andrea Faulds wrote:
Hi,
Matthew Brown wrote:
I imagine such a "list" type would be a subtype of "array" – everywhere
that array was accepted, a list would be also, and it would have the
same
copy-on-wri
Hello again,
Andrea Faulds wrote:
Hi,
Matthew Brown wrote:
I imagine such a "list" type would be a subtype of "array" – everywhere
that array was accepted, a list would be also, and it would have the same
copy-on-write behaviour.
IIRC with the modern implementation o
Hi,
Matthew Brown wrote:
I imagine such a "list" type would be a subtype of "array" – everywhere
that array was accepted, a list would be also, and it would have the same
copy-on-write behaviour.
IIRC with the modern implementation of arrays in the Zend Engine, you
can check that an array
Hi,
Benjamin Eberlei wrote:
Hello,
I have opened the vote on the Attributes v2 RFC. The voting will be open
until two weeks from now, May 4th 2020, noon UTC.
RFC: https://wiki.php.net/rfc/attributes_v2
Thank you everyone for taking part in the detailed discussion.
greetings
Benjamin
Hi,
Máté Kocsis wrote:
Hi Internals,
Together with George, I'd like to propose an RFC for a long-standing
problem PHP has:
casting floats to string depends on the locale settings. As this behaviour
is nonsense, and
because it can cause quite serious problems, we would like to get rid of
Hi,
Michał Brzuchalski wrote:
Hi Marcio,
śr., 15 kwi 2020 o 18:39 Marcio Almada napisał(a):
Even though I'm fond to the idea of languages having the official
stdlib contained
into a single space, there seems to be no practicality on a \PHP namespace
usage
at this point IMMO.
We would be in
Hi Mark,
Mark Randall wrote:
As internals "claims" the top level namespace, this effectively means
that all userland code must exist in its own namespace, which is
indeed how almost all modern userland code is written, which if
anything this proves the benefit of namespacing.
Yes, post-5.3
Hi Ilija,
Ilija Tovilo wrote:
I share others' concern that it is inconsistent with PHP's
existing statements
Can you elaborate on what exactly the concerns are?
Well, I don't think we have any other expressions that are also
statements with very slightly different syntax, and in this RFC
Hi Ilja,
Ilija Tovilo wrote:
Hi internals
I'd like to announce the match expression RFC that replaces the switch
expression RFC I announced a few weeks ago.
New: https://wiki.php.net/rfc/match_expression
I like this proposal in general, I've wanted something like Haskell and
Rust's
Hi,
AllenJB wrote:
I present for discussion an RFC to change the default PDO error mode:
https://wiki.php.net/rfc/pdo_default_errmode
A good thing about this RFC is that if you prefer the traditional error
mode and need to keep that behaviour working in whatever new PHP version
Hey Sara,
Sara Golemon wrote:
On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler wrote:
Just out of curiosity, is there any reason we couldn't add an optional
parameter called "$short_array" or whatever that defaults to false? Then
there shouldn't be any backwards compatibility issues.
None at
Hi Nikita,
Nikita Popov wrote:
Hi internals,
I would like to propose making the use of arithmetic/bitwise operators on
arrays, resources and (non-overloaded) objects a TypeError exception:
https://wiki.php.net/rfc/arithmetic_operator_type_checks
This is inspired by some of the recent
Hi Jakob,
Jakob Givoni wrote:
Heads up!
I've moved the RFC to the voting phase:
https://wiki.php.net/rfc/compact-object-property-assignment
Voting is open until the end of Monday, April 13 (your time zone :-).
Good night,
Jakob
Maybe it would be good to allow multiple-choice voting on
Hi again,
Andrea Faulds wrote:
Hi Sherif,
Sherif Ramadan wrote:
I'm proposing a new RFC to change var_export()'s array syntax to use the
short hand array syntax instead.
The RFC is available here
https://wiki.php.net/rfc/var-export-array-syntax
This is a forwards-compatible change
Hi Sherif,
Sherif Ramadan wrote:
I'm proposing a new RFC to change var_export()'s array syntax to use the
short hand array syntax instead.
The RFC is available here https://wiki.php.net/rfc/var-export-array-syntax
This is a forwards-compatible change proposed for and targeting PHP 8.0.
I'd
Hi Rowan,
Rowan Tommins wrote:
Hi Jakob,
It occurred to me thinking about alternative syntaxes that COPA could be
seen as a limited form of the "with" statement found in some languages,
e.g. JS [1], VisualBasic [2], Delphi [3], Groovy [4] (note that with
blocks in Python are something
Hi,
Christoph M. Becker wrote:
(frankly, I would not have not supported __concat() at all). Also,
overloaded operators should be programmed defensively, i.e. they should
not accept arbitrary arguments (how could that even work?), but only
those they can handle. If implementations adhere to
Hi everyone,
Johannes Schlüter wrote:
If we use two methods as well it is a saner design. I won't like it, but lot
better than the current one.
Just want to +1 this. Two methods, neither of which are static, seems
like a cleaner approach to me. I maybe like this better than my
suggested
Hi Johannes,
Johannes Schlüter wrote:
I believe the pre-requisit is having some form of function overloading,
where operator functions for specific argument types can be defined. In
https://news-web.php.net/php.internals/108425 Andrea created an idea,
which is probably "ugly" but has less usage
Hi,
Christoph M. Becker wrote:
On 28.03.2020 at 10:22, Arnold Daniels wrote:
This issues become even more apparent when sequencing operations like `$a +
$b + $c - $d`. Trying left, then trying right, will make it very difficult
to determine the outcome of such a statement.
The arguments
Hi,
Michał Brzuchalski wrote:
The first thing is for operator methods when the operation is not supported
I would see simply `return null;` as the right solution
instead of constant, which name no one will remember.
If we are to allow arbitrary use of operator overloading (rather than
Hi Ilija,
Ilija Tovilo wrote:
Looking through the language grammer I discovered that switch cases can also be
terminated with a `;` instead of a `:`.
```
switch ($i) {
case 1;
return 1;
default;
return 2;
}
```
https://3v4l.org/o7nD8
This is in fact documented:
Ilija Tovilo wrote:
Hi Andrea
but I am surprised you haven't mentioned the `and` and `or` operators
I did mention them in the RFC here:
https://wiki.php.net/rfc/throw_expression
If this RFC is accepted they will indeed be possible __
Regards
Oh, you are quite right! Sorry, I must not
Hi Dan,
Dan Ackroyd wrote:
Regarding the example:
$condition || throw new Exception('$condition must be truthy')
&& $condition2 || throw new Exception('$condition2 must be truthy');
The "Deprecate left-associative ternary operator"* RFC made it so that
parentheses are required when ternary
Hey Ilija,
Ilija Tovilo wrote:
Hi everybody! I hope you’re doing well.
Due to the modest feedback I’d like to move the throw expression RFC to “under
discussion”.
https://wiki.php.net/rfc/throw_expression
In short, the RFC proposes to convert the throw statement into an expression
Hi,
Jakob Givoni wrote:
Hello Internals,
I'm opening up my new RFC for discussion:
https://wiki.php.net/rfc/compact-object-property-assignment
- A pragmatic approach to object literals
Let me know what you think!
Best,
Jakob
I really don't like this `(new Foo)->[]` syntax for a few
(I already send the mesage after the “”, but unfortunately it showed
up as part of the “Capturing reasons for votes for historical sake?”
thread, so I'm re-posting it as a “new” message in the hopes it'll be
its own thread. Therefore, please reply to this message, not the
previous copy of
Hi everyone,
I want to break off this thing from the “Capturing reasons for votes for
historical sake?” thread.
Background and problem
==
Rowan Tommins wrote:
Hi Mike,
On 17/03/2020 03:01, Mike Schinkel wrote:
Currently it takes herculean effort to get almost anything
Hi Nikita!
Nikita Popov wrote:
I've update the message to say:
Deprecated: usort(): Returning bool from comparison function is
deprecated, return an integer less than, equal to, or larger than zero in
%s on line %d
The astute reader will notice that this is equivalent to "any integer", but
Benjamin Eberlei wrote:
I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list back
then and from talking to previous no voters.
The RFC is at https://wiki.php.net/rfc/attributes_v2
Hi,
I have concerns
Hi,
Nikita Popov wrote:
I've implemented this variant now. If the comparison function returns a
boolean, you get
Deprecated: usort(): Returning bool from comparison function is
deprecated, return one of -1, 0 or 1 instead in %s on line %d
once per usort() call, and we retry with swapped
Christoph M. Becker wrote:
Given that we have internal classes which deliberately have such
comparison behavior (i.e. returning 0 or 1, to signal that there is no
order defined), e.g. Closures[1], I tend to prefer raising a warning
instead of trying to recover.
Oof… I wonder if we should make
Hi,
Larry Garfield wrote:
If I'm understanding the definition of stable here, it means that if two values
evaluate to equal they will always end up in the same order in the output that
they were in the input, yes? So (trivial example):
$a = ["3", 2, 3, 5];
Sorts to:
[2, "3", 3, 5];
Hi Nikita,
Nikita Popov wrote:
I believe that it is important for us to provide a stable sorting option in
the standard library. We could introduce a separate stable function(s) for
this purpose, but I believe we can just as well make all our existing sorts
stable.
I agree with having a
,
but consider for example the Japanese encoding Shift_JIS, where the
second byte of a multi-byte character can be a valid first byte of a
single-byte character. str_contains() would have incorrect behaviour for
this case.
Regards,
Andrea Faulds
--
PHP Internals - PHP Runtime Development Mailing List
Hi Jan,
jan.h.boeh...@gmx.de wrote:
On 15/02/2020 22:05, jan.h.boeh...@gmx.de wrote:
How many of you would prefer a interface solution for operator overloading?
I wonder if the RFC voting should include the option to choose between
either the magic method approach (with the syntax proposed in
Hi again,
Andrea Faulds wrote:
I am not sure if I think this is a good idea… for one thing it may not
be necessary to add support in core for this, because you could easily
write a userland Iterator class that wraps a generator-returning closure
and (re-)invokes it for you. If you do
Hi,
Nikita Popov wrote:
There is a relatively simple (at least conceptually) way to make generators
rewindable: Remember the original arguments of the function, and basically
"re-invoke" it on rewind().
I'm wondering what people think about adding this functionality. I think
the main argument
Nikita Popov wrote:
Hi internals,
https://github.com/php/php-src/pull/5172 changes var_dump() to use
serialize_precision instead of precision to dump floating-point numbers.
Hi Nikita,
Thank you so much for doing this! I had wanted to do this for a long
time, and I actually implemented it
Hi Johannes,
Thank you for your points! I think you point out some overlooked issues.
Johannes Schlüter wrote:
Which one is being called? - Vector's or Matrix's. How will your
vector know about my Matrix?
The way C++ solves this is by allowing non-member functions as
operators.
Hi,
Nikita Popov wrote:
Hi internals,
Based on a suggestion by Nicolas Grekas,
https://github.com/php/php-src/pull/5153 changes the generated name for
anonymous classes to include the name of the parent class or first
interface. So instead of just class@anonymous, you'll see something like
Hi,
Nikita Popov wrote:
Yes, i don't think it makes sense to group these operations in interfaces,
the use-cases are just too diverse. It's possible to define one interface
per operator (e.g. what Rust does), though I don't think this is going to
be particularly useful in PHP. I would not want
Hi Nikita,
Nikita Popov wrote:
Since nullable types have been available since PHP 7.1, having a required
parameter after an optional one is increasingly likely a bug rather than an
intentional workaround, so I think it would be good to throw a warning for
this case.
Wouldn't it be trivial to
Hi Zeev,
As the person who initially proposed and implemented strict_types, I
think this is heading in the wrong direction. Perhaps that directive was
a mistake, if it will lead to so many attempts inspired by it to
fragment the language, including this one. Personally, I don't actually
want
Hi all,
Rasmus Schultz wrote:
What about libraries that need to support both PHP 7 and 8? Many libraries
will likely need to, potentially for a long time.
How will these libraries be able to detect whether the names have been
mangled or not? Libraries that "unmangle" run the risk of
Hi Dan,
Sorry, I think I should directly address your points.
Dan Ackroyd wrote:
Apparently there is an implementation detail in JSON_THROW_ON_ERROR
that differs in the RFC text, from the discussion on list
http://news.php.net/php.internals/100569:
I decided to reset it to no error because
Hi Dan,
Please see the discussion on the original pull request:
https://github.com/php/php-src/pull/2662
The existing behaviour is deliberate, was already discussed, and was
part of the RFC that was accepted. So there is a high standard to meet
for going back on that.
The idea was to keep
Hi Benjamin,
Benjamin Coutu wrote:
if (ZSTR_H(s1) && ZSTR_H(s1) != ZSTR_H(s2)) {
return 0;
}
Should that not be like this?:
if (ZSTR_H(s1) && ZSTR_H(s2) && ZSTR_H(s1) != ZSTR_H(s2)) {
It would be possible the other string also has no hash value.
Otherwise this sounds
Nikita Popov wrote:
I'm always a fan of making things stricter, but think that in this
particular case there are some additional considerations we should keep in
mind.
1. What is more important to me here than strictness is consistency. Either
both " 123" and "123 " are numeric, or neither
with this when PHP 8 wasn't on
the horizon.
Andrea
Andrea Faulds wrote:
Hej allihopa,
Here's an RFC that's been lying in my drafts for uh… 26 months:
https://wiki.php.net/rfc/trailing_whitespace_numerics
I expect this should be an uncontroversial proposal, but maybe I'm
jinxing it there. I hope
Hi,
Stanislav Malyshev wrote:
Finally, Python makes a distinction between list comprehensions using []
and generator expressions using (). This proposal effectively corresponds
to generator expressions, but uses the [] syntax. I'm wondering if that
will cause confusion.
Do we need this
Hej allihopa,
Here's an RFC that's been lying in my drafts for uh… 26 months:
https://wiki.php.net/rfc/trailing_whitespace_numerics
I expect this should be an uncontroversial proposal, but maybe I'm
jinxing it there. I hope you all like it. :)
Thanks to Nikita for reminding me it existed
Hi everyone.
I've rebased this patch again: https://github.com/php/php-src/pull/3838
I guess this can serve as a reminder this exists and can be discussed.
Thanks!
Andrea Faulds wrote:
Hi there,
Do you spend HOURS every day AGONISING over how long run-tests.php takes
to complete?
Have
Hi,
Dmitry Stogov wrote:
I've added info from Nikita: PHP-Parser became 1.5 times faster.
That is actually a very good real-world example from my perspective and
makes a better case for why JIT compilation to native code would be
beneficial. I would like to write a PHP compiler in PHP
Hi Nikita,
Nikita Popov wrote:
I'd like to bring forward the following proposal for PHP 8, which will make
(zpp) parameter parsing failures always result in a TypeError (rather than
generating a warning+null, depending on circumstances):
https://wiki.php.net/rfc/consistent_type_errors
I like
Hi Joe,
I like the idea of adding weak references to the PHP core (as opposed to
PECL), so I'm generally in favour of this RFC. This type of feature
which the engine must be aware of should be maintained as part of it —
and it not requiring a PECL extension means it can actually be used by
Dmitry Stogov wrote:
Hi Internals,
I'm glad to finally propose including JIT into PHP.
https://wiki.php.net/rfc/jit
In the current state it may be included both into PHP-8, where we are going to
continue active improvement, and into PHP-7.4, as an experimental feature.
Thanks. Dmitry.
Hello,
Joe Watkins wrote:
Already taken care of :)
On a side note, at what point do we remove stuff from the manual/pecl, the
weakref is extension is dead, can't work with current versions of PHP, and
there was never a stable release ?
I'm not even sure we have a mechanism to delete stuff
Dmitry Stogov wrote:
Hi internals,
The FFI RFC is turned into voting state.
https://wiki.php.net/rfc/ffi
There were very few minor changes since the initial proposal, e.g. renaming
FFI:array_type() into FFI::arrayType()
Thanks. Dmitry.
Hi Dmitry,
Reading Sara's concern about it
this. :)
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
rt all the
encoding name aliases or so? That wouldn't be difficult to implement and
wouldn't break anything.
Thanks!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker wrote:
On 14.03.2017 at 19:57, Andrea Faulds wrote:
Since stdClass has no __set_state method, var_export() produces unusable
output if given an object of that class. I wrote a patch that would make
var_export() produce a cast to object instead, which could be evaluated
. 2/3 already means there's twice as many agreeing
as disagreeing, having +1 doesn't serve the tie-breaking function there
that it does for 50%+1. But that was indeed a knife-edge RFC, it was
actually saved by someone chosing to vote Yes at the last minute.
--
Andrea Faulds
https://ajf.me
, but keep the vote for Yes for the key functions.
Someone who wants such behaviour could always do
($array[array_key_last($array)] ?? null), I guess.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to implement, so this is
not really a significant reason to vote against. To that end, I'll vote
in favour of this deprecation.
Thanks!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
Andrea Faulds wrote:
Hi David,
David Rodrigues wrote:
Hello. I saw that JS supports the x-notation (\x40) and u-notation
(\u0040), but PHP only supports u-notation. There some reason for that?
JSON.parse('"\x40"'); // => @
JSON.parse('"\u0040"'); // =>
upported by JS doesn't
matter, JSON isn't JS. In JS it is just a synonym for \u so there's not
really anything you're missing out on anyway.
Thanks.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
And the determined can prefix with an @ if they want similar to old
behaviour :)
Ivan Enderlin wrote:
Hello,
Yes, a thousand yes. Silently ignoring undefined variables is a source
of multiple bugs. Emiting a warning is a small BC break comparing to the
benefits.
Regards.
--
Andrea Faulds
ructed DateTime as a function? Be aware that
__invoke can be implemented by a class to make its objects callable.
Thanks!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
php -r 'var_dump("2-phpbundled" >= 2);'
bool(true)
The problem is that, well, some code out there might want an actual
integer. It's also a bit ugly…
Thanks.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
event potential monkeying with the scope of the caller by
the callee — if right now you do $f($this->data), you might forget that
$f could take that parameter by reference and gain the ability to modify
that variable indefinitely…
Thanks
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP
tended.
(Probably.)
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in my code,
but the manual insists on lowercase here.
I would argue we should simply make the manual deliberately break with
convention for this extention, and document in camelCase.
Thanks.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
Hi Mark,
Mark Randall wrote:
On 03/11/2017 02:27, Andrea Faulds wrote:
Your proposed objects would not be usable everywhere an array is,
because they're not arrays, and by converting to an array you lose the
type info, so we still have to iterate over the whole thing to type
check. This would
Hi,
Mark Randall wrote:
On 01/11/2017 01:36, Andrea Faulds wrote:
Thank you for bringing this up. The introduction of nullables means
that the type[] syntax is problematic and should probably be avoided
now. As you say, there is an issue of ambiguity as to whether it would
be interpreted
a cleaner solution, but it
introduces a new issue: does an array type declaration require an
array value, or will it implicitly cast from vanilla array?
Thanks.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in a strict_types
file. I also dislike the inconsistency of making dynamic calls work
differently.
Thanks.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/property/constant
names and throw warnings to that effect, with an obvious goal of
eventually merging those namespaces.
…hey, if we merged properties and constants together, you could do
Foo::bar = $baz; instead of having to use the annoyingly inconsistent
Foo::$bar syntax. I'd love that.
--
Andr
HP static property syntax is the bane of my existence.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Johannes,
Johannes Schlüter wrote:
On So, 2017-10-08 at 04:47 +0100, Andrea Faulds wrote:
Have you long since ABANDONED every test directory besides
Zend/tests?
... or ran only eext/foo/tests ;)
…*ahem*. Okay, enough terrible salesmanship. I felt like
parallelising
run-tests.php, so I
Hi!
Ferenc Kovacs wrote:
On Tue, Oct 10, 2017 at 9:01 AM, Michael Wallner <m...@php.net> wrote:
Hi!
On 08/10/17 05:47, Andrea Faulds wrote:> Hi there,
Then I've got just the trick for you!
Ha, welcome to the club! I'm glad someone else feels the need, too.
https://github.com/ph
effectively it tolerates errors. The child
processes will even happily kill themselves if the parent does.
The code is here:
https://github.com/php/php-src/pull/2822
Happy Halloween.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Hi again,
I'm happy to report JSON_THROW_ON_ERROR was unanimously accepted with 23
votes.
Hopefully it can be merged soon. Now would be a good time to review the
pull request if desired.
Thanks for discussing and voting!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime
that
relies on deterministic __destruct()” is what you mean by “a PHP
implementation”, then yes, it's necessary. If not, then no. :)
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
clarifying.
Thanks.
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
often
used with operations like array_map() which have a multiplicative effect
that can make their speed significant.
Please tell me your thoughts on this idea.
Thanks!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Jakub,
I already replied to you off-list, but for the benefit of people on-list…
Jakub Zelenka wrote:
On Sun, Sep 10, 2017 at 2:24 AM, Andrea Faulds <a...@ajf.me> wrote:
Hi everyone,
Craig Duncan previously sparked discussion here about JSON's
error-handling behaviour. Unfortunatel
/json_throw_on_error
The feature can be described in a single paragraph (in fact, the title
is pretty much enough, the patch is just detail) but it's better to go
through the proper RFC process.
Please tell me what you think.
Thanks!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime
might have been an omission.
Thanks!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
those files should still behave the same.
What I want to change is how it behaves in other circumstances, i.e.
templating.
Thanks.
--
Andrea Faulds
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
1 - 100 of 1301 matches
Mail list logo
