Re: [PHP-DEV] Weak Closures
> On Jan 21, 2022, at 4:31 AM, Dominic Grostate
> wrote:
>
> Hi Internals,
>
> I'd like to express my interest in a possible feature concerning weak
> references. Currently closures created within a class appear to
> contain a reference to the object that created it. This is of course
> necessary in order for the closure to retain the necessary scope.
> However I would like to suggest we have the option for closure to
> weakly reference this object so that when the object is garbage
> collected, the closure too may be rendered null or invalid
> (inspectable).
>
> Consider the following example:
> https://gist.github.com/orolyn/7651e4127759aad1736547490baa1394
>
> The idea here is that without unset($sample) the loop would run
> forever, because there is a reference to the callback from the object,
> and in turn there is a reference to the object from the main stack.
> With the unset($sample), the idea is that before the callback is even
> called, the reference to the object is destroyed thusly so is the
> reference to callback, and since the callback is only referenced now
> in a WeakMap, the callback will finally be gone.
>
> In reality it appears there is a circular reference between the object
> and the callback. I don't know if this is a bug or not, because from
> what I can find PHP was fixed a long time ago to resolve circular
> references.
>
> However if this is intentional, I would like the option to make the
> closure weak for example:
>
> $c = WeakClosure::fromCallable(function () {});
> $c = Closure::fromCallable(function () {}, true);
>
> Please let me know your thoughts, because maybe there is a way of
> achieving this with PHP as is.
>
> Kind regards,
> Dominic
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi Dominic,
Implementing a weak closure is possible in user code. We've done so in Amp v3:
https://github.com/amphp/amp/blob/379177aba93518e2df6d626677cbbdc48cc0d8ae/src/functions.php#L119-L171
I would be in favor of having this functionality available directly in PHP. Amp
often uses references to object properties in static closures to avoid circular
references to $this. There are other ways to accomplish this, such as a ref
object like
https://github.com/azjezz/psl/blob/21bf0cd3d6d6055fc88541e9b24f3140bd179b2d/src/Psl/Ref.php,
but a weak-ref to $this would certainly be more convenient.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Add ReflectionFunctionAbstract::isAnonymous()
> On Oct 20, 2021, at 6:12 PM, Dylan K. Taylor wrote:
>
> Hi all,
>
> Given the addition of Closure::fromCallable() and the upcoming first-class
> callable syntax in 8.1, it seems slightly problematic that there's no simple
> way to tell by reflection if a Closure refers to an anonymous function or
> not. ReflectionFunctionAbstract::isClosure() (perhaps somewhat misleadingly)
> returns whether the closure is literally a \Closure instance, so it's not
> useful for this purpose.
>
> The only way to do this currently (that I know about) is to check if the name
> of the function contains "{closure}", which is a bit unpleasant and depends
> on undocumented behaviour.
>
> I'm proposing the addition of ReflectionFunctionAbstract::isAnonymous(),
> which would fill this use case, and may be able to offer an implementation.
>
> Thanks,
> Dylan Taylor.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi Dylan,
I recently wrote some code checking for “{closure}”:
https://github.com/amphp/amp/blob/27219ddbc0bbc3fd0db4d7380eaed6489c7291ed/lib/functions.php#L135
<https://github.com/amphp/amp/blob/27219ddbc0bbc3fd0db4d7380eaed6489c7291ed/lib/functions.php#L135>
I agree, it is a bit unpleasant and looks like a hack. I would welcome an
isAnonymous() method.
Cheers,
Aaron Piotrowski
[PHP-DEV] Rename Fiber::this() to Fiber::getCurrent()
Hi all, During the Fiber RFC vote, several people noted that they objected to the name Fiber::this() for the method returning the currently executing Fiber object. I'd like to propose renaming this method to Fiber::getCurrent(). A simple PR for the rename: https://github.com/php/php-src/pull/7155 Nothing has functionally changed about the method, only the name. Fiber::current() is another possibility, but was not chosen because it may be conflated with Iterator::current(). Does anyone object to this rename? Shall we have a vote or is that not necessary? Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
On May 14, 2021, at 7:36 PM, Larry Garfield wrote: > > On Fri, May 14, 2021, at 7:20 PM, Aaron Piotrowski wrote: >> >>> On May 14, 2021, at 7:00 PM, Larry Garfield wrote: >>> >>> Is that actually going to come up? Given that PHP functions (at least >>> user-space ones) accept extra trailing arguments and just let them fall >>> off, I would *expect* a closure that way to do the same. Named arguments >>> continue that, I believe, by just ignoring any variadic arguments that do >>> not match a parameter in the function. It seems odd to go back on that >>> behavior now. >> >> I don't consider forwarding extra arguments an issue. I briefly was >> thinking it might be nice to be explicit about the number of arguments >> a partial would accept, but you convinced me otherwise in R11, so I >> think we're on the same page here. >> >>> >>> I can't speak for the others, but I could tolerate making "more than one >>> extra ? beyond the end of the parameter list is an error", potentially, as >>> at that point they're redundant. But if a function has, say, 4 params, >>> then fourParams(1, 3, ?) is a convenient way to say "and placeholder >>> everything else". Especially in dynamic cases like Nicolas pointed out, >>> you may not necessarily know how many arguments there are. >> >> With what I proposed in my last email, `fourParams(1, 3, ?)` is >> acceptable, there's nothing superfluous there. At least one ? is needed >> to declare a partial. Similarly, a partial for a no parameter function: >> `$partial = functionTakingNoParams(?)`. Or even a partial with args >> bound to all four params: `fourParams(1, 2, 3, 4, ?)`. >> >> What would error is `fourParams(1, 3, ?, ?)`, as the second ? is meaningless. >> >> I think you've convinced me that one-for-one matching on ? is >> burdensome, but the above is a happy medium perhaps? > > I'd be OK with "no more than one trailing ? in excess of what the underlying > callable has." (Which means if you don't know, just stick one ? at the end > and you know it will work.) I think multiple trailing ? should be an error, otherwise how am I suppose to know at a glance if a partial declaration will error? Plus it’s adding multiple ways to declare the same thing, which I was hoping to avoid. fourParams(1, 2, ?); // OK fourParams(1, 2, ?, ?); // OK for you, should error to me fourParams(1, 2, ?, ?, ?); // Again OK for you, should error to me fourParams(1, 2, ?, ?, ?, ?); // Error for both What value is gained in allowing any of those but the first? I’d also be fine allowing a trailing ? in any declaration. It’s unnecessary, but one could argue that it’s consistent to allow a trailing ? in any partial, since it’s required for some. fourParams(?, 2, ?); // Could error, but probably fine for consistency Aaron Piotrowski
Re: [PHP-DEV] [RFC] Partial function application
> On May 14, 2021, at 7:00 PM, Larry Garfield wrote: > > Is that actually going to come up? Given that PHP functions (at least > user-space ones) accept extra trailing arguments and just let them fall off, > I would *expect* a closure that way to do the same. Named arguments continue > that, I believe, by just ignoring any variadic arguments that do not match a > parameter in the function. It seems odd to go back on that behavior now. I don't consider forwarding extra arguments an issue. I briefly was thinking it might be nice to be explicit about the number of arguments a partial would accept, but you convinced me otherwise in R11, so I think we're on the same page here. > > I can't speak for the others, but I could tolerate making "more than one > extra ? beyond the end of the parameter list is an error", potentially, as at > that point they're redundant. But if a function has, say, 4 params, then > fourParams(1, 3, ?) is a convenient way to say "and placeholder everything > else". Especially in dynamic cases like Nicolas pointed out, you may not > necessarily know how many arguments there are. With what I proposed in my last email, `fourParams(1, 3, ?)` is acceptable, there's nothing superfluous there. At least one ? is needed to declare a partial. Similarly, a partial for a no parameter function: `$partial = functionTakingNoParams(?)`. Or even a partial with args bound to all four params: `fourParams(1, 2, 3, 4, ?)`. What would error is `fourParams(1, 3, ?, ?)`, as the second ? is meaningless. I think you've convinced me that one-for-one matching on ? is burdensome, but the above is a happy medium perhaps? Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
> On May 14, 2021, at 6:09 PM, Paul Crovella wrote:
>
> On Fri, May 14, 2021 at 2:49 PM Aaron Piotrowski wrote:
>>
>> Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as
>> `$partial = foo(?, 42)`.
>>
>> If the partial is called as `$partial(73, 8)`, should 8 be forwarded to `$z`
>> or should the call error as providing too few arguments?
>
> The 8 passes along to $z. There is no error, all required arguments
> have been provided.
In the current proposal, yes. In a hypothetical implementation where ?
represented a single argument, I was asking what made sense. In that situation,
I think 8 passing along still makes sense.
>
>> Or perhaps should the partial declaration should error, as it should have
>> been `foo(?, 42, ?)` or `foo(?, 42, ...?) so the partial provided all
>> required arguments to foo.
>
> I think this highlights where the misunderstanding of this feature is.
> Partial application is about binding arguments. ? isn't an argument,
> it's an argument placeholder. It does two things: signals to create a
> closure wrapping the function rather than calling it immediately, and
> holds a position in the argument list so that an argument further to
> the right can be fixed (bound) at that time. Arguments are bound;
> argument placeholders are not, they exist only for convenience. The
> syntax `foo(?, 42)` doesn't call foo, let alone provide any arguments
> to it, it simply creates a closure that'll pass along 42 at the
> appropriate argument position along with whatever else it's provided
> with.
>
> Requiring additional trailing argument placeholders or adding an
> additional token `...?` unnecessarily complicates things, burdens the
> user, and only serves to further promote misunderstanding.
>
My issue is the dual-meaning of ? in the current proposal. In `foo(?, 42)`, the
? represents a single argument, but adding a trailing ? (such as in `foo(?, 42,
?)`) represents any number of arguments. Would it perhaps make sense to make
superfluous ? markers an error?
foo(?); // Fine, needed to define a partial with no bound args.
foo(?, 42); // Ok, binds second arg.
foo(?, ?, 42); // Ok, binds third arg.
foo(?, 42, ?); // Error, unnecessary placeholder.
foo(?, ?); // Error, unnecessary placeholder.
The intention here is to keep the syntax unambiguous.
foo(?) == foo(?, ?) == foo(?, ?, ?) and so forth is not going to be obvious to
everyone, so why allow meaningless and misleading syntax.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
> On May 14, 2021, at 4:18 PM, Mark Randall wrote:
>
>
> Passing more arguments than the partial defines would result in an argument
> count error.
>
I think it’s reasonable to allow passing more arguments to a partial since
user-defined functions and closures allow this without error.
Whether or not the extra arguments are automatically forwarded to the function
wrapped by the partial is debatable.
Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as
`$partial = foo(?, 42)`.
If the partial is called as `$partial(73, 8)`, should 8 be forwarded to `$z` or
should the call error as providing too few arguments? Or perhaps should the
partial declaration should error, as it should have been `foo(?, 42, ?)` or
`foo(?, 42, ...?) so the partial provided all required arguments to foo.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Disable interactive mode (-a) if readline not available
> On May 12, 2021, at 3:12 AM, Nikita Popov wrote: > > Hi internals, > > If the readline extension is enabled, PHP provides an interactive shell > under -a. If it is not enabled, it falls back to an "interactive mode" > (yes, the difference between "interactive shell" and "interactive mode" is > important here). The interactive mode is simply an stdin input, which needs > to be terminated using Ctrl+D. You can only run one script that way. > > I think the current behavior is quite confusing, because it's really not > obvious that you ended up in this fallback mode (you need to know the > difference between "shell" and "mode" in the output) and most people > wouldn't know what to do with it. The latest instance of this is > https://bugs.php.net/bug.php?id=81033. > > I think we would be better off disabling -a completely if readline is not > available, and exit with a helpful error message. I've opened > https://github.com/php/php-src/pull/6976 to that effect. Does that sound > reasonable? > > Regards, > Nikita This would have been helpful several years ago when I started compiling PHP myself and was confused why `php -a` broke. An error message would have saved me some time. So yes, please, merge it. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Object scoped RNG implementation
> On Apr 2, 2021, at 5:49 PM, Larry Garfield wrote: > > On Fri, Apr 2, 2021, at 4:56 PM, Kamil Tekiela wrote: >> Hi Go Kudo, >> >> First, let me say that I believe we need such implementation in PHP and I >> would like to see object scoped RNG as part of the standard. However, I >> have voted no for a number of reasons. Let me list them from the >> perspective of a noob PHP user. >> >> - I really do not understand why we are introducing new functions. Can't >> the classes implement the necessary methods to get integers, doubles, and >> string of bytes? As a new user I would be completely overwhelmed by all >> these functions: rand(), mt_rand(), rng_int(), rng_next(), rng_next64(). >> Which one should I use? What is the difference between rng_next() >> and rng_next64? >> - As soon as I left the RFC page I forgot what the new classes were called. >> I still can't tell from memory what's their name. I understand what they >> mean, but they are definitely not friendly names. >> - What's the difference between MT19937 and XorShift128Plus? They are >> different algorithms but which one should I pick? I tested the >> implementation locally and I see no difference in performance. >> - I am not a fan of adding a new optional parameter to shuffle() and >> friends. I'd prefer to have a method in the class that I can pass an array >> to. >> - What is the default seed? Do I have to provide a seed each time? Why >> can't the seed be done automatically? >> - Signed? Unsigned? As far as I know, PHP doesn't have unsigned integers. >> What's the real-life purpose of this flag? >> - I don't see any use in supporting userland implementations. Why can't >> they create separate libraries? I don't know about performance, but if >> someone wants to have custom RNG then I don't think they worry about >> performance. >> - When using the functions the performance was 50% worse than when calling >> ->next() directly. Is this right or is the implementation going to be >> optimized further? The fastest way to get a random number seems to be >> mt_rand() based on my tests. >> >> I would rather like to see a single class called RNG/Random that implements >> RNG/RandomInterface. The constructor of the class would take 2 arguments. >> The first is the algorithm with a default either MT or XORShift. The second >> is an optional seed. If no seed is provided then the seed is generated >> automatically like in mt_srand(). The class would then implement methods >> like: nextInt(), nextDouble(), nextBytes(), arrayShuffle(), >> stringShuffle(), randomArrayKeys(). I would keep the standard functions as >> they are. Let them use MT by default. We could even deprecate them in >> future if this takes off. >> >> This would make it painfully obvious what the class does and how to use it. >> No more procedural code. I would also make the class final so that you >> can't inherit from it, but that is highly opinion-based. >> Now that I have written this, I read previous conversations and it looks to >> me like what I would like is what you had previously. >> >> I'm sorry if I complain too much, but I would like to see something like >> this implemented, just not like you are proposing right now. It is too >> messy for me and I know I wouldn't like it if I had to use it. >> >> Regards, >> Kamil > > I also didn't pay close attention to the previous discussion, but reading the > RFC I agree with all of this. The functionality proposed is good and needed, > but the API is a mess. What Kamil suggests is far better, and fully commits > to being OOPy. Given that the use case is for situations where you need a > predictable and repeatable random sequence, such as Fibers or threads or > such, going all-in on an object seems like the correct approach. > > One thing I'm not 100% clear on from the RFC, does this also deprecate > random_int()/random_bytes()? Those are (AFAIK) unseeded, so they seem like > they'd continue to serve their current purpose, but it's not clear from the > RFC. > > Voting no for now, but I would welcome a resubmission with a cleaner API, > even in this cycle. > > --Larry Garfield > I too voted no for similar reasons as Larry, Marco, Levi, and others. The API needs improvement and using a new namespace without precedent or a plan is problematic. Overall I’m in favor of an object-based approach and encourage you to rework the API and bring it to a vote for PHP 8.1. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] noreturn type
> On Apr 1, 2021, at 2:03 PM, Levi Morrison via internals > wrote: > > I do not care which name is chosen, but if we are going to have this > sort of thing in the language, it ought to be a bottom type, not an > attribute. > You make an excellent point Levi. I initially chose `noreturn` simply because I was familiar with the name from C and didn't have a strong opinion. However, I agree that `noreturn` is a poor choice for reuse as a bottom type, so I changed my vote to `never`. Cheers, Aaron Piotrowski
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 19, 2021, at 5:47 PM, Levi Morrison > wrote: > > On Fri, Mar 19, 2021 at 3:54 PM Niklas Keller <mailto:m...@kelunik.com>> wrote: >> >> Hey Levi, >> >>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski wrote: >>>> >>>> Greetings everyone! >>>> >>>> The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers >>>> <https://wiki.php.net/rfc/fibers> >>>> >>>> Voting will run through March 22nd. >>>> >>>> Cheers, >>>> Aaron Piotrowski >>> >>> This is selfish, but I would like to kindly request lengthening the >>> voting window to allow me more time to play with it. I feel like I >>> can't vote "yes" on something like this without more experience with >>> it (which is why I currently have voted "no"). I hope others would >>> play with it more as well if we had more time. Any objections? >> >> >> How much time do you think you need? > > Another week seems reasonable; enough time to evaluate it more > thoroughly but not delay things seriously. This is fine with me. Let's extend voting for about another week, ending on 3/28 at about 11 PM EDT. Thanks! Aaron Piotrowski
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 12, 2021, at 4:36 PM, Christoph M. Becker wrote: > > On 12.03.2021 at 23:04, Michael Wallner wrote: > >> Thank you, and everyone involved, for your effort. >> >> On 08/03/2021 20.40, Aaron Piotrowski wrote: >>> Greetings everyone! >>> >>> The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers >>> <https://wiki.php.net/rfc/fibers> >>> >>> Voting will run through March 22nd. >> >> I voted /no/, because of the dependency on Boost. >> If my assumptions are wrong, I may reconsider my vote. > > Only asm files are used[1], and these can be bundled, so there is no > dependency on boost or C++ in general. > > [1] <https://github.com/amphp/ext-fiber/tree/master/boost> > > -- > Christoph M. Becker > Hi Mike, Christoph, and Derick, To add a bit more information: These asm files are part of the low-level boost.context lib, found here: https://github.com/boostorg/context This library has infrequent releases. Some of the files for old architectures have not changed in several years. Keeping these files up-to-date will not be a burden (and I plan to assume this responsibility). The Boost license is extremely permissive and approved by the OSI, so there is no problem bundling with PHP. Hopefully that provides some clarification and you’ll reconsider your vote Mike. Cheers! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 12, 2021, at 3:00 AM, twosee wrote: > > Now, Swow's working principle is a bit like Opcache. Opcache will optimize > and replace the CPU instructions, which executed by the code, and Swow will > replace the blocking system calls with the corresponding coroutine operation. > They hardly change the behavior of the code. Opcache makes The program runs > faster, and Swow can make the program's IO concurrency better. > > Therefore, all PHP programs will benefit from it. We can directly use the > synchronous-blocking guzzle. Any network IO will only block one coroutine > instead of the entire process. You just need to open more coroutines to get > better concurrency performance. For amphp and reactphp, after that, > `stream_select()` and `curl_multi_select()` will become the coroutine > version, and even they will no longer block the entire program. > > Generally, the solution provided by Swow is completely a superset of Fiber. > Hi Twosee, I wanted to address the point above from your email. I do not think auto-magically altering the behavior of existing functions to use async I/O is a good idea. Existing code that relies on a constant state during an I/O operation that previously was blocking may no longer work as expected. Changing behavior is a major BC break. It would be better to introduce new async versions of functions, e.g., asio_fwrite(), instead of altering the existing fwrite() function. This way libraries which have interfaces requiring blocking I/O, such as libraries implementing PSR-7/15, can create versions that are designed with async I/O in mind, while keeping existing implementations working as expected. Changing the behavior of existing functions reminds me of the `mbstring.func_overload` feature that is now deprecated because of the compatibility problems it caused. I took a look at Swow this morning. Again, I would compare Swow to Swoole – it is another large, opinionated framework for asynchronous PHP apps. Swow is not a lightweight, standalone feature that can be merged into PHP at one time. The Fiber API is small in scope and does not alter existing behaviors. Looking at the fiber implementation in Swow, I see it uses the same boost library and the same asymmetric coroutine model as ext-fiber. It seems Swow could use an internal API provided by PHP for fibers, allowing it to drop the boost dependency. This leads me to believe my proposal would be mutually beneficial to both your extension and the wider PHP community that could use fibers outside of your framework or Swoole. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] noreturn type
> On Mar 10, 2021, at 12:06 PM, Matthew Brown wrote:
>
> Hey,
>
> Ondřej Mirtes and I present an RFC for the noreturn type:
> https://wiki.php.net/rfc/noreturn_type
>
> The feature already exists in Hack (the primary inspiration) and is
> currently supported by our static analysis tools inside docblocks, and we
> feel there's a good argument for it to be supported by PHP itself.
>
> Thanks,
>
> Matt & Ondřej
Hi Matt & Ondřej,
I wanted to give my +1 to this proposal.
I was curious to see how fibers might interact with this declaration, since it
is possible to create a fiber that can not return. So, I compiled your branch
and gave it a try.
```
$fiber = new Fiber(function (): noreturn {
while (true) {
Fiber::suspend(\random_int(0, 100));
}
});
$result = $fiber->start();
for ($i = 0; $result; ++$i) {
echo $result, "\n";
$result = $fiber->resume();
}
echo "Generated ", $i, " numbers before generating zero.\n";
```
This short script works just as expected, cool! :-D
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 11, 2021, at 10:41 AM, Ben Ramsey wrote: > >> On Mar 11, 2021, at 10:29, Aaron Piotrowski wrote: >> >> There is not an internal API to create fibers at this time. However, I >> planned to collaborate with other internals developers to add this API (and >> of course with feedback from swoole developers), so this will be a feature >> available to PHP extensions. >> > > > I know voting is currently on-going, but would it be out of order to add a > section to the RFC that states what you’ve said here? > > Cheers, > Ben > Hi Ben, I think this is appropriate, as it is merely adding information to the RFC to answer a question that was raised on the list. I added a “Future Scope” section with the following text: The current implementation does not provide an internal API for fibers for PHP extensions. This RFC focuses on the user space fiber API. An internal fiber APIwill be added, collaborating with other internal developers and using feedback from PHP extension developers, including Swoole, so fibers can be created and controlled from PHP extensions. An extension may still optionally provide their own custom fiber implementation, but an internal API would allow the extension to use the fiber implementation provided by PHP. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 11, 2021, at 7:56 AM, 韩天峰 wrote: > > The RFC does not mention how an extension uses fiber. > Hi, I forgot to address your point that the RFC does not mention how an extension uses fibers. I did omit this from the RFC as I focused on the user API, as that is typically what PHP RFCs focus on, but this is an important question. There is not an internal API to create fibers at this time. However, I planned to collaborate with other internals developers to add this API (and of course with feedback from swoole developers), so this will be a feature available to PHP extensions. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> Hi all! > > A concern was raised off list that due to the complexity of the way this > feature interacts with the engine, it may be best to mark the feature as > experimental. This would allow some changes to be made to certain edge-case > behaviors and, while I don't think it would be necessary, the public API. > > We (Niklas and I) agree with this and propose that if this feature is > accepted, it is marked as experimental through the 8.x release cycle or until > we're comfortable removing that label, whichever comes first. > > Experimental in this context would mean fibers would be compiled and > available in all releases, but the documentation would denote that behavioral > and API changes may be made in future minor releases – use at your own risk. > > As this feature is targeted at library authors and not average PHP users, we > believe there would be little effect to the community to take this step. > > Cheers, > Aaron Piotrowski > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hi everyone! I’m concerned my email above may have had the opposite effect from which I had hoped. I think the Fiber implementation is sound and the API, mirroring that of Ruby, is proven and unlikely to require change. There are certain edge case behaviors that I’m concerned may need to changed, such as the error reporting level that is active when a fiber is switched. If the @ operator is active, should it remain active after a fiber switch? Right now, it does not, the @ operator is on a per-fiber basis, restoring error reporting when switching fibers. Perhaps though this was the wrong decision. What I was hoping to accomplish with marking the feature as experimental was to get feedback on such behaviors and make sure we make the right choices. Recent changes to the JIT also make fibers as an extension incompatible due to defining a user opcode handler. This is unfortunate, as cli apps including amphp and ReactPHP greatly benefited from the JIT: https://www.php.net/releases/8.0/en.php (see Relative JIT contribution to PHP 8 performance). Integrating fibers in core will allow the opcode handler to be predefined. Hopefully that provides some clarity to our intensions. Cheers! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 11, 2021, at 7:56 AM, 韩天峰 wrote: > > Hi, > I am come from Chinese, we may have some cultural differences, and there may > be some difficulties in communication. I try to express my opinion. > To be precise, the fiber can only be used for amphp and reactphp or other > event-driven asynchronous IO frameworks developed using php. The RFC does not > mention how an extension uses fiber. > Fiber is not like threads or processes of operating system. It is not > parallel, nor is it concurrent. This requires an event-driven scheduler to > have practical value. Currently php does not have event-driven support. So > normal web developers don’t know how to use fiber. It is for developers of > asynchronous io programming. > I just suggest first to provide a PECL extension like ext-event/ext-libevent, > no need to be integrated into php now. Swoole is also provided to users as a > PECL extension. > Hello, I agree that this feature is targeted at libraries wishing to provide better async I/O. What I disagree with is that this means it should not be a part of PHP. Whether many developers realize it or not, several commonly used libraries already contain some async I/O features, often implemented with promises, which have some API trade-offs to attempt to integrate async into typical synchronous code. Guzzle, Symfony, and Psalm are three commonly used libraries that have asynchronous APIs available. Having fibers available in core will allow these libraries to offer async code with an improved, more intuitive API as well as expand their use of async I/O beyond what it typically has been used for, HTTP requests, to include databases, redis, file access, etc. An event scheduler is needed for async I/O to work, but several implementations already exist in user space and work very well with fibers, as I and ReactPHP team can attest. Fibers are the key to integrating these event schedulers into the greater PHP community. Swoole provides an entire large, opinionated framework for async coding. That’s fantastic! However, it is not a flexible tool that any library can use for a variety of purposes. It is more akin to choosing a framework such as Laravel or Yii to write your PHP app. Event-driven programming is desperately needed in the PHP community. Right now PHP contains nearly all the tools for fantastic, clear, intuitive user space async code. This is the one missing piece. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 10, 2021, at 12:21 PM, Dan Ackroyd wrote: > > Hi internals, > > Well, technically this is addressed more to people who read internals. > > Please don't contact people off list putting pressure on them to vote > in a particular way. > > It _really_ is not appreciated, no matter how well intentioned the > sender thinks it is. > > I maintain some notes on RFC etiquette here: > https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md#dont-pressure-people-by-private-communication-to-vote > (which not even is going to fully agree with), but getting unsolicited > pressure to vote in a particular way makes people uncomfortable, and > less likely to take part in the project in the future. > > cheers > Dan > Ack > Hi everyone, While I appreciate the support from the individual that sent the email, I do not condone sending emails to people privately off list asking them to vote in a particular way. For clarification to those that may have not received the email in question, I did not send the email nor did I request that it be sent. Thanks, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 10, 2021, at 2:15 AM, 韩天峰 wrote: > > Hi ereryone, My name is Tianfeng.Han, I am founder of swoole project. We have > done a lot of exploration in cli server side programming of php > > I think, ext-fiber is more suitable as a pecl project. > > Coroutine and asynchronous IO is a new concurrency model, This is very > different from blocking io. > > I am afraid that fiber can only be used in the amphp framework and is of no > value to other php projects. > > If the PHP language wants to support CSP programming like golang, > asynchronous io and coroutine system can be designed in the next major > version (PHP9), this requires a lot of work. > > > Tianfeng.Han > Hi Tianfeng.Han, Fibers will immediately benefit projects that use async I/O. This is not limited to amphp, but also includes ReactPHP, Guzzle, Symfony, and Psalm, to name that I am aware of that could use it in conjunction with I/O and multi-processing. One of the ReactPHP maintainers and I collaborated on a proof-of-concept for ReactPHP, which is mentioned in the RFC: https://github.com/trowski/react-fiber This fiber API was meant to be a lightweight implementation to enable user space green-threads/coroutines. I would love to see more async tools in PHP, but that will require much more work. This is meant to be a first step toward that eventual goal, without conflicting with or restricting future additions. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 10, 2021, at 4:56 AM, Peter Stalman wrote: > > On Tue, Mar 9, 2021 at 6:03 PM twosee wrote: > > 5. Not compatible with Swoole > > In my opinion, Swoole is an important part of the PHP ecosystem. But now, > Fiber cannot work with Swoole. And based on the above reasons, Swoole will > not consider compatible fiber. > > We would expect some ZendAPI rather than Fiber extensions to provide support > for coroutine switching. > > > Hi Twosee, > > Are you saying that by adding this Fiber code to core it will prevent Swoole > from functioning? If so, that is concerning. Or are you simply saying that > Swoole doesn't like this implementation and will not use it with their own > code? > > One thing to consider when comparing the Fiber implementation is that the > vast majority of PHP applications are still run behind a web server in > short-lived requests. Unlike Swoole, Swow, and Parallel, it isn't limited to > ZTS or CLI. It might not be the ideal solution, but IMO it is a step in the > right direction for PHP to allow for better async support. > > And I think you are right that "Fiber is just an enhancement of Generator'', > but so what? The Generator addition in 5.5 opened up PHP to a hacky way of > doing async, but it worked everywhere. Fiber allows that to be much more > convenient in switching contexts deep inside a call stack. I don't think it > needs to be the end-all-be-all coroutine solution to rival Goroutines, and > I'm pretty sure it's not trying to be. > > Thanks, > Peter > Hello, This Fiber implementation does not conflict with Swoole. Both could coexist. However, Swoole's implementation does provide some other features that this does not, so I believe Twosee was simply saying that Swoole cannot directly use this fiber implementation. My focus was to provide a minimalistic implementation in core so user space code can make other API decisions as they saw fit. Regarding some of the other concerns raised: - Switch notification: The observer notification is triggered before switching to a fiber and after suspending from a fiber. The timing here was an open question I've discussed with others and we planned to examine it later. Moving the second notification before suspending the second fiber was already being considered. As this was an internal API I felt it was not needed directly in the RFC. - Fiber is final, as is Generator. I believe it is better to compose classes rather than extend them. Of course it is always possible to remove final. - Using Fiber::resume() and Fiber::suspend() models fibers as a stack and simplifies logic of resuming/suspending fibers. Ruby fibers share this exact API, though their API uses the term yield instead of suspend. - State functions: Separate methods (i.e., isRunning, isTerminated) returning a boolean are preferable IMO to comparing integer constants to a value returned by a status method. This is really a matter of opinion than one being strictly better than the other. - Pure C coroutine: The extension code provides user space fibers. Adding functions to create fiber C-only fibers can certainly be done if the need arises. - Being marked experimental: I was hoping this would be a good compromise between allowing people to experiment with fibers and providing the ability to make minor BC breaks if the need arose. I realize this is generally not the PHP way, however this is, IMO, not entirely without precedent. JIT and FFI were not widely used before being added to PHP. Thanks for the feedback! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
> On Mar 8, 2021, at 1:40 PM, Aaron Piotrowski wrote: > > Greetings everyone! > > The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers > <https://wiki.php.net/rfc/fibers> > > Voting will run through March 22nd. > > Cheers, > Aaron Piotrowski Hi all! A concern was raised off list that due to the complexity of the way this feature interacts with the engine, it may be best to mark the feature as experimental. This would allow some changes to be made to certain edge-case behaviors and, while I don't think it would be necessary, the public API. We (Niklas and I) agree with this and propose that if this feature is accepted, it is marked as experimental through the 8.x release cycle or until we're comfortable removing that label, whichever comes first. Experimental in this context would mean fibers would be compiled and available in all releases, but the documentation would denote that behavioral and API changes may be made in future minor releases – use at your own risk. As this feature is targeted at library authors and not average PHP users, we believe there would be little effect to the community to take this step. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] Fibers
Greetings everyone! The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers <https://wiki.php.net/rfc/fibers> Voting will run through March 22nd. Cheers, Aaron Piotrowski
Re: [PHP-DEV] [RFC] Fibers
> Hello again everyone! > > Based upon feedback both on this list and elsewhere, I’ve decided to remove > the FiberScheduler API from the fiber proposal. > > The FiberScheduler API greatly increased the complexity of the implementation > and the potential for edge cases that would need to be handled and > maintained. The intent of including the FiberScheduler API as part of the > proposed implementation was to require usage of fibers to be interoperable > between various libraries. However, this was perhaps over-reaching, and the > core should only provide the most fundamental tools for fibers. > > The Fiber API proposed now resembles that of Ruby and other languages > providing a fiber API. The revised RFC now proposes only a minimal API > required for fibers – no more, no less. I believe this minimal, simplified > API should resolve any concerns raised about adding the fiber API to core. > > I would like to open voting for this RFC around the beginning of March, so > please review the minimal API and provide any feedback soon. > > As before, amphp v3 (https://github.com/amphp/amp/tree/v3) and > trowski/react-fiber (https://github.com/trowski/react-fiber) provide > real-world examples of how fibers can be used in addition to the examples in > the RFC. > Hi all! Since there has not been much feedback lately on the Fiber RFC, I wanted to notify everyone that I intend to start voting on the RFC next week Monday. If you have any questions or concerns, please do raise them now, as it’s always more difficult to address these once voting has started. I feel this feature deserves a lot of time to merge and test if it is to be included in 8.1, so I’d like to move forward soon. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
> On Feb 3, 2021, at 11:32 AM, Aaron Piotrowski wrote:
>
>
>> On Jan 31, 2021, at 11:29 AM, Levi Morrison via internals
>> wrote:
>>
>> I think it would probably be advantageous to have an observer that
>> alerts interested parties when the fiber switches. This way we can
>> avoid querying the current fiber on every fcall.
>>
>
> Hi Levi,
>
> Yes, I agree and will look at implementing an observer API.
>
> Cheers,
> Aaron Piotrowski
>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>> <https://www.php.net/unsub.php>
Hi Levi,
I implemented an observer that notifies registered handlers whenever the
current fiber context is switched.
typedef void (*zend_observer_fiber_switch_handler)(zend_fiber *from, zend_fiber
*to);
PHP_FIBER_API void
zend_observer_fiber_switch_register(zend_observer_fiber_switch_handler handler);
This works similar to the error observer API.
zend_fiber provides access to a unique ID, zend_execute_data, etc. that should
be sufficient for code profilers, debuggers, etc. One pointer is NULL if {main}
is the from or to fiber. The handlers are invoked before switching to the fiber
and after suspending from a fiber.
Let me know if there’s something missing or improvements that could be made.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
> On Feb 12, 2021, at 4:05 PM, Aaron Piotrowski wrote: > > The Fiber API would conflict or prevent async / await from being added to PHP > in the future. The two APIs can coexist and serve different purposes. > While probably obvious from the rest of the context of the email, for clarity, I meant to state that the Fiber API would *not* conflict or prevent async / await from being added to PHP in the future. Sorry for the noise! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
> On Feb 12, 2021, at 3:47 PM, Mark Randall wrote: > > On 12/02/2021 21:40, Aaron Piotrowski wrote: >> I would like to open voting for this RFC around the beginning of March, so >> please review the minimal API and provide any feedback soon. > > Removing the scheduler was likely a good plan, but pretty please reconsider > your future scope. > > It's going to be a really big pain to push people to use this functionality, > only to have to re-write it 1 or 2 year later because a vastly superior > syntax mechanism was introduced. > > If you can add async / await / delay / defer, even if it takes another month > or so, that would likely make this RFC have a significantly bigger and more > beneficial impact on userland. > > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hi Mark, The Fiber API is only tangentially related to async / await, etc. Adding such a feature is a much larger proposal and would not be small undertaking. The future scope proposes using fibers in an async / await implementation, but async / await would not replace fibers. The Fiber API would conflict or prevent async / await from being added to PHP in the future. The two APIs can coexist and serve different purposes. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
> On Dec 17, 2020, at 10:30 AM, Aaron Piotrowski wrote: > > Hello everyone! > > I would like to introduce an RFC for adding full-stack fibers to PHP: > https://wiki.php.net/rfc/fibers > > Fibers are primarily used to implement green-threads or coroutines for > asynchronous I/O. Fibers are similar to threads, except fibers exist within a > single thread and require cooperative scheduling of the fibers by the > process. Since fibers do not require a full CPU context switch, they are > lightweight and more performant than multi-processing or threading for > awaiting I/O. > > An implementation as an extension is at https://github.com/amphp/ext-fiber > > Fibers are a complex feature. The RFC contains many examples and links to > code using fibers to help explain and demonstrate what is possible, however > I’m certain many more questions and concerns will arise. Looking forward to > feedback and discussion. > > Aaron Piotrowski > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hello again everyone! Based upon feedback both on this list and elsewhere, I’ve decided to remove the FiberScheduler API from the fiber proposal. The FiberScheduler API greatly increased the complexity of the implementation and the potential for edge cases that would need to be handled and maintained. The intent of including the FiberScheduler API as part of the proposed implementation was to require usage of fibers to be interoperable between various libraries. However, this was perhaps over-reaching, and the core should only provide the most fundamental tools for fibers. The Fiber API proposed now resembles that of Ruby and other languages providing a fiber API. The revised RFC now proposes only a minimal API required for fibers – no more, no less. I believe this minimal, simplified API should resolve any concerns raised about adding the fiber API to core. I would like to open voting for this RFC around the beginning of March, so please review the minimal API and provide any feedback soon. As before, amphp v3 (https://github.com/amphp/amp/tree/v3) and trowski/react-fiber (https://github.com/trowski/react-fiber) provide real-world examples of how fibers can be used in addition to the examples in the RFC. Cheers! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
> On Feb 3, 2021, at 8:27 AM, Nikita Popov wrote:
>
> If you stick to the FiberScheduler concept, then you might want to consider
> inverting the API. Right now you're basically using a standard Fiber API,
> with the difference that suspend() accepts a FiberScheduler, which is
> unintuitive to me. If Fibers require a scheduler anyway, why are the
> suspend and resume methods not on the scheduler?
>
> class FiberScheduler {
>function suspend(Fiber $fiber);
>function start(Fiber $fiber);
>function resume(Fiber $fiber);
> }
>
> Both methods are bound to the scheduler in that "suspend" suspends back to
> a certain scheduler, while "resume" resumes a fiber such that it will
> return back to this scheduler on termination. This also makes it more
> obvious that, for example, it's not possible to just do a "$fiber->start()"
> without having created a scheduler first (though it does not make it
> obvious that the call has to be from within the scheduler).
>
> Regards,
> Nikita
>
Hi Nikita,
I considered adding start, resume, and throw methods on FiberScheduler as you
suggested, however I’m not sure it would serve to make the API clearer. The
callback (function, method, etc.) that is used to create the instance of
FiberScheduler does not immediately have a reference to the created
FiberScheduler object, so using the object within that callback would be
awkward. One solution would be a `FiberScheduler::this()` method, but I think
that adds complexity for not much gain. `FiberScheduler::this()->resume($fiber,
$value)` is, in my opinion, less intuitive than `$fiber->resume($value)`.
Either would have to be called within the callback provided to the
FiberScheduler constructor.
Niklas otherwise outlined the reasons to have FiberScheduler a unique fiber –
suspending {main}, interoperability between libraries using differing
schedulers, and running schedulers to completion upon script termination.
>>>
>>> What's not clear to me is why the scheduling fiber needs to be
>>> distinguished from other fibers. If we want to stick with the general
>>> approach, why is Fiber::suspend($scheduler) not Fiber::transferTo($fiber),
>>> where $fiber would be the fiber serving as scheduler (but otherwise a
>>> normal Fiber)? I would expect that context-switching between arbitrary
>>> fibers would be both most expressive, and make for the smallest interface.
When starting or resuming a fiber, the current execution point in the current
fiber is stored as the point to jump to when the starting/resuming fiber
suspends or terminates. Fibers must therefore be only pushed or popped from a
stack, you cannot switch to an already running fiber, as another fiber higher
in the stack would no longer return to the correct execution point when
suspended or terminated.
Since FiberScheduler internally is just another fiber, there’s nothing really
special done to switch to a fiber scheduler. Requiring suspending to a
scheduler rather than an arbitrary fiber prevents users from attempting to
switch to an already running fiber.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
> On Jan 31, 2021, at 11:29 AM, Levi Morrison via internals > wrote: > > I think it would probably be advantageous to have an observer that > alerts interested parties when the fiber switches. This way we can > avoid querying the current fiber on every fcall. > Hi Levi, Yes, I agree and will look at implementing an observer API. Cheers, Aaron Piotrowski > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > <https://www.php.net/unsub.php>
Re: [PHP-DEV] [RFC] Fibers
> On Jan 18, 2021, at 8:59 AM, Benjamin Eberlei wrote: > > Hi Aaron, > > this is a very interesting and welcome piece of functionality. I have gone > through the RFC a few times now, it have never thought about or worked with > fibers before, additional feedback will be forthcoming once I grasp the > details more. > > From my POV the effects on other extensions are the most important factor, > you already have a section with that for Xdebug, Parallel, and pcov. But > how does this affect Profilers that manage their own stack of frames, > either all function calls or specifically selected ones. I.e. xhprof, > tideways, datadog, newrelic and so on. Hi Benjamin, Sorry for the bit of a delay in replying. I’ve been busy the last few days. Profilers that manage their own stack of frames will have to be modified to account for fibers. The extension currently provides an API to access the current fiber and uniquely identify each different fiber. The internal API for this will need further discussion amongst the rest of the internals contributors and hopefully the authors of those extensions. I omitted any API for this from the RFC as it does not affect user code. > > At the moment any PHP Profiler only has to manage a single stack of "open > frames". With Fibers for each fiber a new stack must be opened. > > Does an extension know what the "active" fiber is so that from a > zend_execute_data I know on which stack of open frames I need to push a new > frame? Four functions are currently provided for determining the current executing fiber. ``` zend_fiber *zend_get_root_fiber() zend_fiber *zend_get_current_fiber() zend_long zend_fiber_get_id(zend_fiber *fiber) zend_long zend_fiber_get_current_id() ``` These allow you to get the root and current fiber as well as the ID associated with the fiber. The fiber ID is unique to the process and is never reused, so it can be used to determine which open stack frame to push a frame. > > Could you add a section to the RFC explaining how a switch between fibers > works in terms of "the next" and "previous" zend_execute_data that is run? > This would also be interesting to understand how stack traces work, for > example debug_print_backtrace. > I added a brief section under FAQs entitled "How are execution stacks swapped?”, https://wiki.php.net/rfc/fibers#how_are_execution_stacks_swapped Backtraces are currently limited to including only the currently executing fiber. It may be possible to include backtraces of fibers further down the execution stack, but I had issues when trying to implement this in the extension during shutdown due to stacks being freed. Something I think can be addressed if adding to core with the help of someone more familiar with how references to these stacks are kept and what should be modified in the functions generating backtraces. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
Hi Peter, > On Jan 8, 2021, at 3:03 AM, Peter Stalman wrote: > > I've been playing around with this for a bit, and I have some more questions. > I see you recently changed how the `FiberScheduler` works, making it `final` > and adding some "is" functions to match it more to a regular fiber. > > Since the `FiberScheduler` is itself also a fiber, why does it need to be a > separate class? Why did you choose to go this way and make it "special" > instead of not just making a regular fiber into a scheduler in userland. `FiberScheduler` is “special” because user code is not in control of suspending/resuming the underlying fiber, so `FiberScheduler` is a different class from `Fiber` without those methods. Internally a user fiber and scheduler fiber are similar, but I wanted to differentiate them in user code. `FiberScheduler` recently changed from an interface to a class because we discovered that automatically creating a scheduler fiber internally would make it difficult for adaptors or wrappers of a `FiberScheduler` to not create multiple internal scheduler fibers when there should only be a single scheduler fiber. The API largely works the same, but now the creation of the scheduler fiber is explicit in user code instead of done internally. This way adaptors or wrappers can return a single `FiberScheduler` instance. More code is required in user libraries, but offers greater flexibility. > Could you have two or more schedulers? You can have two or more schedulers in a single script. Only one can ever be running at a single time. > Could you get by without a scheduler and call a fiber inside a fiber > recursively? This design requires a scheduler fiber to be entered between suspending one user fiber and resume another user fiber. User fibers are designed to be independent. If two users fibers need to communicate, they should use something similar to Go’s channels to exchange data. > > Related to that, I noticed it was not possible to call `Fiber::this()` from > within the scheduler, why is that? Is it not just another fiber? Or is this > to prevent it from being passed to another scheduler? A scheduler fiber cannot be suspended or resumed by user code so it is not useful to get a reference to that fiber. > > Alternatively, going the other way, instead of making the scheduler a unique > class that needs to be passed around, why not go the more "traditional" PHP > route and pattern it after `register_shutdown_function(callable $callback, > mixed ...$args) : void`, `spl_autoload_register(callable $autoload_function = > ?, bool $throw = true, bool $prepend = false) : bool`, and those type of > functions? After all, isn't it just a callback too? Something like > `register_fiber_scheduler(callable $callback) : void`? > > This would remove the need for a special scheduler class and the need for > passing the scheduler back to the `Fiber::suspend()`. Each `suspend()` call > would bubble up through the registered scheduler callbacks. This would allow > competing schedulers to work nicer together, instead of one scheduler having > to finish before the higher up scheduler can run it's next loop. The scheduler to be entered is specific to the code calling `Fiber::suspend()`. Registering a global scheduler would require only a single scheduler to be used in a script. Only a single scheduler is entered on a call to `Fiber::suspend()`, not multiple schedulers. Registering schedulers or wrapping application code in boilerplate depending on the library being used is something this API is attempting to avoid. > > Either way, doesn't the fiber already know which scheduler it is in when it > suspends? No, a fiber can potentially use different schedulers at different suspend points. The scheduler that starts a fiber does not necessarily need to be the only scheduler that suspends the fiber. Hopefully that helps in understanding how the API works. Please take a look at how amphp v3 uses fibers in these examples https://github.com/amphp/amp/tree/v3/examples/pipeline or in react-fiber https://github.com/trowski/react-fiber/tree/master/examples where the Fiber API is handled by the library rather than “application” code. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
Hi Mike, > On Dec 21, 2020, at 7:38 PM, Mike Schinkel wrote: > > Would it be appropriate of me to ask for a section that discusses how that > might be done in user space in the RFC, at least with some simple > pseudo-code, or if is it non-trivial than a link to where it is discussed in > depth? Absolutely! I added a short example implementation of a mutex to the RFC under https://wiki.php.net/rfc/fibers#how_do_various_fibers_access_the_same_memory. The code uses a simple queue of fibers waiting to access the mutex to acquire and release the lock. A channel might be implemented with a queue of messages where the receiving fiber suspends if the queue is empty. Sending a message on the channel would resume a suspended fiber that was waiting to receive a message. Hopefully that helps. If something is still unclear or an additional example would help, don't hesitate to ask. Cheers! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
> On Dec 21, 2020, at 4:33 PM, Mike Schinkel wrote: > >> On Dec 17, 2020, at 11:30 AM, Aaron Piotrowski wrote: >> >> Hello everyone! >> >> I would like to introduce an RFC for adding full-stack fibers to PHP: >> https://wiki.php.net/rfc/fibers >> >> Fibers are primarily used to implement green-threads or coroutines for >> asynchronous I/O. Fibers are similar to threads, except fibers exist within >> a single thread and require cooperative scheduling of the fibers by the >> process. Since fibers do not require a full CPU context switch, they are >> lightweight and more performant than multi-processing or threading for >> awaiting I/O. >> >> An implementation as an extension is at https://github.com/amphp/ext-fiber >> >> Fibers are a complex feature. The RFC contains many examples and links to >> code using fibers to help explain and demonstrate what is possible, however >> I’m certain many more questions and concerns will arise. Looking forward to >> feedback and discussion. >> > > This is interesting, and potentially very useful. > > I am curious about how you propose access to shared memory across fibers? > What will happen if two fibers try to update a $GLOBALS variable at the same > time? Or a property of the same object? How will developers manage that? > > -Mike > > P.S. Have you considered concurrency functionality like in GoLang[1] e.g. > channels, where the mantra is "Do not communicate by sharing memory; instead, > share memory by communicating?" > > [1] > https://medium.com/@thejasbabu/concurrency-in-go-e4a61ec96491#:~:text=Do%20not%20communicate%20by%20sharing,race%20conditions%2C%20memory%20management%20etc > > <https://medium.com/@thejasbabu/concurrency-in-go-e4a61ec96491#:~:text=Do%20not%20communicate%20by%20sharing,race%20conditions%2C%20memory%20management%20etc>. Hi Mike, Fibers do not change the single-threaded nature of PHP. Only a single fiber can be running at one time, so memory cannot be modified simultaneously. There are synchronization issues when writing asynchronous code using either stackless or stackful coroutines, as anyone who has worked with AMPHP or ReactPHP can tell you. Multiple fibers (coroutines, green-threads, whatever you want to call them) will interleave execution. Multiple interleaved fibers can change object state between pausing and resuming, which I'm guessing is more to what you were concerned about, rather than literal simultaneous modification that can occur with threads. The RFC does not provide tools to synchronize memory access, as these can be implemented in user space. Fibers don't provide the entire API, just the "bare-metal" API needed to implement various styles of concurrency in user space code. AMPHP provides synchronization tools such as mutexes, semaphores, parcels, and channels in https://github.com/amphp/sync <https://github.com/amphp/sync> and https://github.com/amphp/parallel <https://github.com/amphp/parallel>. Other libraries could provide similar tools, though perhaps with a different approach. We too like the Go-style of concurrency and look to emulate it in AMPHP v3. Cheers, Aaron Piotrowski
Re: [PHP-DEV] [RFC] Fibers
> On Dec 17, 2020, at 4:11 PM, Saif Eddin Gmati wrote:
>
> Hello Aaron,
>
> First, I want to say that I love this proposal and would love to see it land
> in the next PHP release, but I have one question regarding this:
>
>
>> Promises result in the “What color is your function” problem as described in
>> the introduction of the RFC. Returning promises from functions means that
>> functions calling those functions must also return promises, resulting in
>> the entire call stack needing to return promises.
>
> Hack-Lang provides `HH\Asio\join` function which allows awaiting Awaitables
> in sync code, so you are capable of running multiple async tasks concurrently
> without having to declare the entire call stack as "async" or with an
> "Awaitable" return type, isn't this possible?
>
> ```
> use namespace HH\Asio;
>
> async function async_task(): Awaitable {
> await Asio\usleep(100);
> }
>
> <<__EntryPoint>>
> function main(): void {
> $start = microtime(true);
>
> $async = async {
>concurrent {
> await async_task();
> await async_task();
>};
>
>return 'hello';
> };
>
> $result = Asio\join($async);
>
> printf('Result: %s ( %f )', $result, microtime(true) - $start); // output
> "Result: hello ( 1.010382 )"
> }
>
> ```
>
> Regards,
>
> Saif.
>
Hi Saif,
`HH\Asio\join()` implements a synchronous await (I don't know the details of
how its implemented, possibly involving entering and exiting the built-in event
loop), but it does not solve the problem that functions using `await` need to
be declared using `async` and return an Awaitable. Your example declares
`async_task()` as async, while a similar function using the proposed fiber API
would not need to change the function declaration to use `Fiber::suspend()`.
There's an example in the RFC using `Amp\delay()` that is very similar to your
code sample.
Fibers allow existing interfaces to be implemented using either sync or async
I/O because the interface does not need to change to return promises/awaitables.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
Hi Peter, > On Dec 17, 2020, at 1:23 PM, Peter Stalman wrote: > > Hi Aaron, this is very interesting to me. Can I ask why this approach as > opposed to other paradigms like promises, coroutines, etc? You mentioned > async/await in the future scope, and I assume most of these patterns can be > implemented once there is an underlying functionality. Basically, why > fibers instead of x? Promises result in the “What color is your function” problem as described in the introduction of the RFC. Returning promises from functions means that functions calling those functions must also return promises, resulting in the entire call stack needing to return promises. Fibers are a method of implementing coroutines or interruptible functions. Promises likely would still be used as placeholders in libraries using fibers, but coroutines written using fibers do not have to return another placeholder. Fibers allow async code to be indistinguishable from sync code, as opposed to an approach where async functions must return a promise. > > You also mentioned this isn't really intended to be used directly, but with > a library such as AMPHP. IS the expectation that non-blocking I/O > functionality like database drivers and file operation be provided by > libraries as well? > Since most code written for PHP is blocking, yes, such libraries/frameworks would need to provide functionality such as database drivers. Both AMPHP and ReactPHP already have existing async drivers available for several different popular database systems. AMPHP’s postgres, mysql, and redis drivers already have a version using fibers. > I hope I don't come off as critical, I am merely curious. Thank you for > pushing this forward, as async is something PHP has been lacking and should > have IMO to compare favourably to other alternatives that do. > You didn’t com off as critical at all! These were good questions to ask. I too think if PHP is to add support for async code it should compare favorably to other languages. I think fibers offer a distinct advantage to using promise for async code. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Fibers
Hello everyone! I would like to introduce an RFC for adding full-stack fibers to PHP: https://wiki.php.net/rfc/fibers Fibers are primarily used to implement green-threads or coroutines for asynchronous I/O. Fibers are similar to threads, except fibers exist within a single thread and require cooperative scheduling of the fibers by the process. Since fibers do not require a full CPU context switch, they are lightweight and more performant than multi-processing or threading for awaiting I/O. An implementation as an extension is at https://github.com/amphp/ext-fiber Fibers are a complex feature. The RFC contains many examples and links to code using fibers to help explain and demonstrate what is possible, however I’m certain many more questions and concerns will arise. Looking forward to feedback and discussion. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Renaming PhpAttribute to Attribute
> On Apr 28, 2020, at 10:37 AM, Benas IML wrote:
>
> Hey internals,
>
> Since it's safe to say that the Attributes v2 RFC has passed, I wanted to
> make a separate thread based on the comment by Rowan Tommins in the PHP
> namespace policy thread. This is a quote from his comment:
>
>> One prefix doesn't make a trend. "PhpToken" is a different case - it's a
>> token of PHP source code, so the prefix isn't anything to do with
>> avoiding name collisions, it's a natural clarification.
>>
>> To be honest, I'd be perfectly happy with the attributes RFC using the
>> class name "Attribute", just as we use "Iterator", "Closure",
>> "Exception", etc, etc. At which point the whole thing's a non-issue.
>
> I do strongly agree with him and I believe we should rename `\PhpAttribute`
> to simply `\Attribute` before the PHP 8 release in order to improve
> consistency with other classes and interfaces e. g. Iterator, ArrayAccess,
> Countable. It would also make the attribute class definition look more
> aesthetically pleasing:
>
> ```
> <>
> class Test {}
> ```
>
> I am ready to make an RFC for this if the replies are mostly positive, so
> please, express your opinions!
>
> Best regards,
> Benas Seliuginas
> P.S: this is my second email account so hopefully it won't get marked as
> spam.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
I too strongly agree that attributes should use `Attribute` over `PhpAttribute`
or even `PHP\Attribute`.
Namespaces for bundled classes probably should be used in the future, but for
logically grouped classes (such as DOM), extensions, etc.
Attributes are a basic language feature, and therefore should live in the
global namespace the same way as Throwable, Iterator, Countable, etc.
I did not want naming to be a blocker on the attributes RFC, but it certainly
bothered me that it was not `<>`.
Please put together an RFC for this name change, I would definitely vote yes.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exit() via exception
> On Oct 11, 2019, at 10:21 AM, Nikita Popov <mailto:nikita@gmail.com>> wrote:
>
>> Hi!
>>
>> So maybe it narrows down to:
>>
>> Is there an essencial attempt to improve `exit()` handling from the
>> userland perspective or should the focus be solely on solving the
>> memory management issue pointed out in the beginning of the thread?
>>
>> If the scope is to also improve userland, option 3 could be the way to
>> go indeed but I confess to do not be a fan of another callback
>> registering thing... it feels hard to predict when you consider:
>>
>> ```
>> catch_exit(function(){
>>exit(); // what happens here? We still have to guarantee `exit` to
>> halt at some point.
>> });
>> ```
>>
>> And what are the interactions with `register_shutdown_function`? I
>> suppose the `catch_exit` stack has to be run before the
>> `register_shutdown_function` stack? Considering the behavior in the
>> docs.
>>
>
> I think I was a bit unclear in how the catch_exit() function is intended to
> work: It's not an atexit handler, it's basically a try/catch block for
> exits.
>
> $exitExceptionOrNull = catch_exit(function() {
>// Run code that may contain exit() here
> });
>
> or possibly even more explicitly as:
>
> catch_exit(function() {
>// Run code that may contain exit() here
> }, function($exitCode, $exitMessage) {
>// This is called if an exit() occurred
> });
The second option seems better, as it's a lot more obvious what code will be
executed if exit() is called and what will not be.
Would a set_exit_handler function be possible, similar to set_exception_handler?
>
> I like option 4 much more for now. It allows tackling the root issue
>> and still leaves possibilities open regarding how the exception
>> hierarchy could be and how the handling of `exit` could happen
>> (through a catch at userspace or callback registering).
>>
>
> I guess we should do that as the first step in any case ... everything else
> would be extensions on top of that, but this would be the main technical
> groundwork.
>
> Nikita
Option 4 of course would be fine for now. Once that's done, we can decide how
exits could be "caught" in the future.
> On Fri, Oct 11, 2019 at 5:13 PM Marcio Almada <mailto:marcio.w...@gmail.com>> wrote:
>
>>>
>>> EngineShutdown could be a special exception to the engine, being handled
>> like an exception internally, but not implement Throwable and therefore not
>> an exception from user-land's point-of-view.
>>>
>>> EngineShutdown could be added to the list of "throwables", but forbid
>> instigation in user-land.
>>>
>> https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
>>
>> <https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916>
>>>
>>> No catch block would catch it, because it wouldn't implement Throwable
>> nor extend Exception or Error.
>>>
>>
>> Very elegant solution!
>>
>> PS: Naming things is hard, but `Throwable` could not have been a
>> better choice in retrospect. Ty ;)
Thanks! Every once-in-a-while I manage to name something correctly!
>>
>>> Aaron Piotrowski
>>>
>>
>> Márcio
Aaron Piotrowski
Re: [PHP-DEV] exit() via exception
quot; implement the interface, which is rather odd. It still allows
> explicitly catching the exit.
>
> 3. Introducing a function like catch_exit(function() { ... }). This would
> still allow catching exits (for phpunit + daemon use cases), but the fact
> that this is actually implemented based on an exception would be hidden and
> the only way to catch the exit is through this function.
>
> 4. Don't allow catching exits at all. In this case the exception is just an
> implementation detail.
>
> Nikita
+1 for option 3.
EngineShutdown could be a special exception to the engine, being handled like
an exception internally, but not implement Throwable and therefore not an
exception from user-land's point-of-view.
EngineShutdown could be added to the list of "throwables", but forbid
instigation in user-land.
https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
No catch block would catch it, because it wouldn't implement Throwable nor
extend Exception or Error.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 2^3
> On Jun 27, 2018, at 1:48 AM, Dmitry Stogov wrote: > > Hi Niklas, > > Fibers are the major feature we're looking forward to, because it > allows async I/O in places that do not account for async, e.g. also > re-using interfaces designed for sync applications. Apart from that, > we want to avoid the boilerplate we currently have to write, i.e. > Amp\call wrapping a generator function. > > We already have ext/fiber proposal and additioal branch implementing > stack-full fibers. > I think, we'll build fibers in the PHP core reusing this work, keeping the > proposed API and behavior. > I concur with Niklas - Fibers are the major feature needed, the stack-full branch in particular. Being able to reuse so much existing PHP code is particularly exciting. Most modern, testable PHP code performing IO should allow for async IO implementations, since IO should be mockable to be properly tested. > > We think that a methodless "Promise" / "Awaitable" type + fibers > implemented with keywords are the preferred way over the current Fiber > draft in the long run. > > This is too abstract. > What keywords do you like for fibers and why do we need them? > Why do we need Promise/Awaitable in the core? > If you have concrete solution (just API), lets discuss it in separate email > thread. Niklas and/or I will put something together and start a new thread. Regards, Aaron Piotrowski
Re: [PHP-DEV] PHP 2^3
> On Jun 25, 2018, at 7:30 AM, Zeev Suraski wrote: > > > 2. Better support long-running, async-based, microservices-focused execution > model. It's probably no secret that one of the key reasons Node is gaining > popularity is because it can handle a huge number of concurrent connections > issuing relatively lightweight requests very efficiently - which is a good > match for modern microservices based architectures. There are already > several projects available for PHP that aim to provide similar functionality > - most notably ReactPHP and more recently Swoole. > The main thing that is missing is that most of PHP's IO doesn't support async > execution. What I think we should do is add as much support for async IO as > possible across the various extensions and streams - so that using something > like Swoole would become practical for more use cases. More specifically - > the goal would be to provide extension authors with mechanisms that they can > use to make their extensions/functions optionally asynchronous, without > having to tackle the job entirely on their own. While we've done some > research into this area, it requires a lot more research - but I'm cautiously > optimistic that it can be done. We would potentially want to use libuv for > this task, and potentially rewrite or otherwise refactor parts of the PHP > streams system. > Regarding async, are you referring to the Fiber extension? In my opinion, fibers would be the best approach for async in PHP. After using async/await in other languages, it doesn't offer a significant gain over what's already possible in PHP with generator-based coroutines in Amp. Using the fiber extension and a green-thread library that resumes fibers based on promise resolution [1], we've been able to write async code without the need for yield or await [2], with async functions having proper return types (i.e. not promise, but the type the promise would resolve to). Joel Wurtz has also put together a PoC of using Doctrine asynchronously using the fiber extension and Amp [3]. A new major may not be strictly necessary to introduce this feature, but it would ease introducing new keywords for awaiting IO and "promisifying" a function using fibers to allow simultaneous IO. These keywords could be async and await, though they would be used differently than JavaScript or other languages. See an example in the green-thread library [4], where the await() function uses Fiber::yield() to wait for promise resolution, and async() creates a promise from a function using await(). I would propose using keywords in place of these two functions. I successfully am using Amp's http-server library with several other Amp libraries to run a website using long-running processes under PHP 7.2. I've seen no issues with memory leaks, crashing processes, or other unexpected behaviors. I think PHP is absolutely ready to shine in environments outside of per-request SAPIs. Core support for async is one of the few ingredients missing. Aaron Piotrowski [1] https://github.com/amphp/green-thread [2] https://github.com/amphp/byte-stream/tree/ext-fiber [3] https://github.com/joelwurtz/doctrine-async [4] https://github.com/amphp/green-thread/blob/e13327a84be67d289aec87984f9d5c8e1fddd471/examples/simultaneous-async.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fiber support (again)
> On Feb 7, 2018, at 7:05 PM, Haitao Lv <i...@lvht.net> wrote: > > Hi internals, > > I propose to introduce the Fiber feature AGAIN. > > The main purpose of the RFC is to introducing a lightweight stackful > coroutine support for PHP and make it possible to write non-blocking code in > the blocking style. > > In this RFC, no new keyword is needed. So it will not break the PHP 7.3 > release. > > Please see the RFC https://wiki.php.net/rfc/fiber > > Dmitry and I are working on the implementation at > https://github.com/fiberphp/fiber-ext > And a series of usage demo can be found at > https://github.com/fiberphp/fiber-demo > > Please offer you comments. > > Thank you. > > --- > Haitao Lv > Hi Haitao, I'm very excited to see this sort of feature coming to PHP. A couple of questions and thoughts: - How do you determine when a fiber has returned? Looking at the source, it appears Fiber::status() must be used, comparing against constants. Separate methods similar to Generator would be better IMO. e.g.: Fiber::alive(), Fiber::suspended(), Fiber::running() - What about throwing exceptions into a fiber? - Using Fiber::resume() to initialize the fiber and resume feels awkward. Separate methods again would be better here, perhaps Fiber::init(...$args) and Fiber::resume($send). - What happens if the sub1() function in the RFC is invoked outside of a fiber? - I think a keyword here would be beneficial, even if it has a minor BC impact. Fibers could then be written like generators. `await` or `emit` as a keyword perhaps? This would be a less verbose API, feel less magical (a static method call that actually pauses execution feels out of place), and would allow Fibers to be returned from methods, named functions, etc with less boilerplate. Thanks to you and Dmitry for working on this! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
> On Feb 3, 2018, at 11:04 AM, Sara Golemon <poll...@php.net> wrote: >> > I like the three phase approach. Gives frameworks/libraries/users > ridiculous amounts of time to clean up their code, the route to clean > code is clear and the updates are scriptable (I'll bet PHPCS can do > this already), and at the end, we'll be able to have a better engine > and make certain assumptions in the optimizer. Yep, PHP-CS-Fixer can do this, see the native_function_invocation option. I also like the three phase approach and would be excited to see the possibility for function autoloading and further optimizations. +1 Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mailing list moderation
> On Jan 3, 2018, at 12:59 PM, Joe Watkins <pthre...@pthreads.org> wrote: > > The precedent has been set already: One of these users was already kicked > off the list and decided to resubscribe and continue to conduct themselves > in an unacceptable manner. > > This is a forum for technical discussion regarding the development of PHP: > We must be able to keep conversation focused and one of the tools we have > to do that is restricting who is able to post. It seems perfectly > reasonable to exercise that power in order to improve the quality of > conversation and keep it focused. > > Banning or suspending these users, and anyone else incapable of conducting > themselves reasonably, will serve that purpose. > > Let's remember that there are a large number of people on the sidelines > that are not subscribed to the list directly, but choose to use news > readers, or the excellent externals.io; They may not able to filter > messages from any individuals, so they are in effect forced to navigate > through these "contributions" from problematic posters. That's not fair to > them, at all. All of the conversations here are a matter of public record, > not only existing in your mail client, or inbox, or whatever ... We can and > should be eliminating noise from that public record. > > Cheers > Joe Exactly. There needs to be consequences when someone cannot conduct themselves in a manner that's fitting to a technical discussion. It's infuriating when people on this list make personal attacks and then act as though nothing wrong has been done. Clearly either they don't understand or do not care. Either way they need to know there are consequences for such actions. This is not at all about silencing those whose opinions differ from the majority. Those viewpoints are important and must be heard. However relentlessly pushing a particular viewpoint and resorting to personal attacks becomes a problem. At some point it is no longer constructive and is just spam. I and many others avoid participating on the list unless absolutely necessary. There is no time or energy to wade through the noise to find the actual discussion of the topic at hand. > > On Wed, Jan 3, 2018 at 7:45 PM, Paul Jones <pmjone...@gmail.com> wrote: > >> >>> On Jan 3, 2018, at 12:35, Joe Watkins <pthre...@pthreads.org> wrote: >>> >>> You don't get to conduct yourself however you want without consequence. >> >> Sure. The question then, is, what is the proper consequence? I hold that >> it is not "banning" or "suspension" (which may or may not actually be >> within the delegated powers of anyone on this list). Instead, it is "to be >> ignored, by those who choose to ignore you." >> Trying to filter out all messages from certain users is untenable. Either too much is filtered because a banned person is CC'ed on a constructive comment, or too little is filtered and there's still noise from those replying to the filtered user. Banning or suspension should not be used lightly, but I think we've reached a point where it is warranted. I think a simple PHP CoC similar to the JS Foundation [1] would be helpful by providing a basis for what is deemed acceptable. Aaron Piotrowski [1] https://js.foundation/community/code-of-conduct -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index
> On Jun 7, 2017, at 6:31 AM, Derick Rethans <der...@php.net> wrote: > > I voted no because of the BC break. > Changed my vote to no for the same reason. The subtly of the BC would make bugs potentially difficult to discern. Would happily vote yes again for an RFC targeting 8. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
Hi Stephen, > On Feb 3, 2017, at 10:38 PM, Stephen Reay <php-li...@koalephant.com> wrote: > > >> >> I absolutely agree that it's terrible… the point is that types (even >> potential future union types) can be used with short closures, but it >> certainly doesn't mean they should be. I don't think confusion with a >> non-existent and non-recommended way of coding should be a reason against a >> particular syntax. > > Using type hints is a part of the language. It even has benefits that I can > absolutely see being used here: > > array_map(function(Foo $x) => $x->bar()); > > If Foo is a class/interface with a method of bar, your IDE can know that it's > a valid method to call. > > That of course is in addition to the benefit of getting useful type errors > from PHP itself. You raise a good point about IDEs, types might have a place with short closures. Still, I don't see union types, if they ever exist, being common here. Taking your example with the other proposed syntax: array_map(|Foo $x| => $x->bar()); Honestly I'm not sure which is better… personal preference at this point, each has their merits. >> >>> As has been said before, PHP is relatively verbose compared to other >>> languages. That makes it slightly more characters to type, but it also >>> makes it absolutely clear what is happening. >> >> Using `function` IMO makes it more likely to confuse a short closure with a >> regular closure. Reusing the `function` keyword with different semantics may >> result in some confusion. >> > > So we should instead use syntax already used for bit wise OR, and further > confuse the situation when the function has no parameters and reusing the > logical OR operator. Brilliant. This is certainly a downside, though expressions cannot start with a logical or bitwise OR, so that will help differentiate them. However, it is hard to argue that `function` could be confusing when something like `|| => $x ** 2` may be more confusing, so point taken. Regardless, I still prefer the visual difference since the auto-capture behavior is so different from other functions. Cheers! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
> On Feb 3, 2017, at 9:06 PM, Stephen Reay <php-li...@koalephant.com> wrote: > > >> On 4 Feb 2017, at 07:25, Aaron Piotrowski <aa...@trowski.com> wrote: >> >> $callback = |int|float $x| => $x ** 2; > > Forget the parser, you're giving my eyes diabetes trying to read that. I absolutely agree that it's terrible… the point is that types (even potential future union types) can be used with short closures, but it certainly doesn't mean they should be. I don't think confusion with a non-existent and non-recommended way of coding should be a reason against a particular syntax. > As has been said before, PHP is relatively verbose compared to other > languages. That makes it slightly more characters to type, but it also makes > it absolutely clear what is happening. Using `function` IMO makes it more likely to confuse a short closure with a regular closure. Reusing the `function` keyword with different semantics may result in some confusion. > As Niklas said, all ambiguity/clarity issues are solved by using "function", > at the cost of 6 characters. > > Suggesting that a search for arrow functions will be easier with random character here> and then using grep (which could also easily match > arrow functions using "function") as your example search seems odd to me. I never suggested this, Björn Larsson did. Any of the possibilities mentioned in this thread could easily be searched. Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
> On Feb 3, 2017, at 2:34 PM, ilija.tov...@me.com wrote: > > I like the suggested syntax. The only drawback I see is that it inhibits the > future addition of union types for closures: > > |int | float $x| => $x > > Adding parentheses of course resolves the issue but looks a bit awkward: > > |(int | float) $x| => $x > > Apart from that I have nothing to complain about. I'd be happy either way. > While it may be ugly, I do not believe that this has any ambiguity. $callback = |int|float $x| => $x ** 2; When the second | is not followed by =>, the parser should be able to discern that a union type is being used. Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
> On Feb 3, 2017, at 11:53 AM, Levi Morrison <le...@php.net> wrote: > > One more thing: I'd like to re-emphasize that the syntax that > JavaScript uses and the one that HHVM/Hack uses are ambiguous in the > current class of our grammar. The following will not work unless we > move to a more powerful grammar and parser class: > >(params) => expr >(params) ==> expr > > This is why an un-ambiguous prefix is necessary: the prefix breaks the > ambiguities. The syntax I have suggested in the RFC and the one I > suggested just now are not ambiguous because distinct prefixes: > >fn(params) => expr >|params| => expr > > I look forward to more discussion! > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > <http://www.php.net/unsub.php> I personally prefer the `|params| => expr` syntax. I like the visual separation the syntax provides between auto-capturing, short closures and regular closures. It gives the impression that it should behave differently, rather than just being a shorter way of declaring a closure. Below are a couple of real-world single line closures using the proposed syntax: [1] Loop::defer(|| => ($this->when)($exception, $value)); [2] $this->watcher = Loop::delay($time, || => $this->resolve($value)); IMHO, the reduced boilerplate required makes it easier to discern what is happening. Regards, Aaron Piotrowski [1] https://github.com/amphp/amp/blob/master/lib/Coroutine.php#L45-L47 [2] https://github.com/amphp/amp/blob/master/lib/Pause.php#L21-L23
Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names
Hi Marco,
> On Aug 19, 2016, at 1:31 PM, Marco Pivetta <ocram...@gmail.com> wrote:
>
> Hi Aaron et all,
>
> I tried to implement support for 7.1 in zend-code as a start:
>
> https://github.com/zendframework/zend-code/pull/87
>
> A few issues arise:
>
> * `ReflectionType#__toString()` is too volatile, especially if we want to
> support multiple versions of PHP, therefore it's a good idea to not think
> too much about it, and instead deprecate it. Most issues I had while
> working with the feature were related with string formatting, and that's
> simply gotta die: just using a more specific API should cut it (getName,
> getClass, isNullable, etc. As few strings as possible, please!).
> * A page where we can see the current state of the `ReflectionType` API
> (and its subtypes) would be golden.
> * `ReflectionType#__toString()` seems to crash in very interesting ways
> when `?string` is reflected (see issue above - couldn't isolate precisely)
>
I've reverted the changes so that `ReflectionType::__toString()` is now
identical to 7.0, including *not* prepending a ? for nullable types. The method
is now just an alias of `ReflectionNamedType::getName()`.
`ReflectionType::__toString()` should be discouraged for code generation going
forward, as it seems there's just not a way to add type features in a BC way.
My attempt to incorporate nullable types in a way that would allow for even
more complex types such as `callable(?\Type\Name, ?bool)` just caused too many
problems.
> I am currently going through the changes, and just figured that 7.1
> implements https://wiki.php.net/rfc/reflectiontypeimprovements, even though
> the RFC was declined:
>
> ./sapi/cli/php -r 'class Foo { public function bar() : ?Foo {} }
> var_dump((new ReflectionMethod("Foo", "bar"))->getReturnType());'
> object(ReflectionNamedType)#2 (0) {
> }
Only `ReflectionNamedType` was added so the object returned from parameter and
return types could have a `getName()` method. The rest of the RFC was not
implemented. This should be completely BC while allowing future types like
unions or callables. See some discussion here:
https://github.com/php/php-src/pull/2068
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names
> On Aug 17, 2016, at 12:02 PM, Marco Pivetta <ocram...@gmail.com> wrote: > > That would have been a headache anyway. We saw it coming, and it will be > fixed on our end, but please don't try to outsmart it. > I know that there is good intention on your side, but this is really going to > just make it an issue. Looks like this problem is more complicated than I thought. I thought prepending the \ would mean little work on your end, but it appears I was wrong. I'm still confused as to what's going on and what the best solution is... Currently Doctrine is manually prepending \ to class names. Obviously your logic would have to change between 7.0 and 7.1, but then going forward you could rely on ReflectionType::__toString() to return a syntax-valid type name, rather than modifying it. Or perhaps rather than relying on casting to a string and examining the string, Doctrine should be using ReflectionNamedType::getName() and ReflectionType::allowsNull() for 7.1 and beyond. (Just a suggestion, I'd have to dig into the code to really understand what's going on, and I don't have a ton of time to do so at the moment.) > From the codegen-side (I do write a lot of code generators), having `\` > prepended in front of stuff makes things just more complex to deal with, > since I have to strip it and re-introduce it anyway in multiple locations in > the code, while it should just be attached in the final output-logic bit. > Instead, please keep the reflector on-spot: reflecting things, telling us > what they are. What the code generator does with the definitions is up to the > code generator after that. > > We have to adjust the code for `void` and `?` anyway, so this is just more > changes to keep track of, and it would break existing code. It sounds like you'd prefer the ? was not prepended to the string as well, is that correct? Again it sounds like it would be better to use methods other than __toString(). I understand __toString() was the only way to get the type name before, but now that this has been fixed perhaps it should be avoided in your use-cases. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names
> On Aug 17, 2016, at 11:45 AM, Marco Pivetta <ocram...@gmail.com> wrote: > > Since scalar types are invalid anyway if prepended with `\`, I see no point > in producing a string with the `\` in it. > > The current consumers of `Type` assume no `\` is prepended, and we spent an > age and a half dealing with `\` being in front of class names in doctrine > (and finally got rid of it). > > This is not being really helpful, as it is. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > Scalar types do not have a \ prepended. Only class, interface, and trait names. Can you show me some of the code in Doctrine that handles this? This issue came up because of Doctrine prepending a \ in front of nullable class names [1], resulting in `\?Type`, which of course is invalid. Unfortunately I think no matter what is done, nullable types just created another headache for you. :-( Aaron Piotrowski [1] https://github.com/php/php-src/pull/2068#issuecomment-239983716 (Forgot to CC internals again... ugh) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names
Marco, > On Aug 17, 2016, at 11:22 AM, Marco Pivetta <ocram...@gmail.com > <mailto:ocram...@gmail.com>> wrote: > > Sorry, I have to object here: this is quite a BC break for Zend\Code, > specifically. We will have to re-adjust the code generators to adapt to the > newly introduced prepended `\`. > > In addition to that, there is no need for `\` to be prepended to a type > string, since inside string scope, we are always dealing with the base > namespace. > > Seems unnecessary and causes a lot of headaches, instead of actually > simplifying things. > > Marco Pivetta > > http://twitter.com/Ocramius <http://twitter.com/Ocramius> > > http://ocramius.github.com/ <http://ocramius.github.com/> > Adjustments will be necessary in Zend\Code no matter what because of nullable types. If a type is nullable, ReflectionType::__toString() will return "?\Type\Name" or without the changes I committed it would return "?Type\Name". If you need the type name without the leading ? or \, use ReflectionNamedType::getName(). It would be nice to have no BC breaks, but right now I'm not seeing a way of handling nullable types in ReflectionType::__toString() without some sort of BC break. Aaron Piotrowski
[PHP-DEV] ReflectionType::__toString() prepending \ to class names
Hi all, I recently made some changes [1] to ReflectionType::__toString() that prepends a leading \ to class names. These changes follow from the discussion on ReflectionType improvements [2, 3] and the discussion on my PR to implement some of the RFC [4]. A \ should be prepended to class names returned from ReflectionType::__toString() so the output of this method can be used when generating code within a namespace. Currently, several libs such as Doctrine manually prepend a \ when generating code. Nullable types will complicate this, since a ? is prepended to the type name, requiring a \ to instead be inserted as the second character. The changes I made will alleviate the need for libs to manipulate the string returned from ReflectionType::__toString() when generating code. This will become more important if more complex types are introduced, such as callable prototypes. If anyone has objections to these changes, please let me know. Thanks! Aaron Piotrowski [1] http://git.php.net/?p=php-src.git;a=commitdiff;h=20fdd47921f423728b409fd0ae0106dab9c34573 [2] http://news.php.net/php.internals/94452 [3] https://wiki.php.net/rfc/reflectiontypeimprovements [4] https://github.com/php/php-src/pull/2068#issuecomment-240071841 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements
Hi Levi, > On Jul 9, 2016, at 10:12 AM, Levi Morrison <le...@php.net> wrote: > > On Sat, Jul 9, 2016 at 8:16 AM, Aaron Piotrowski <aa...@trowski.com > <mailto:aa...@trowski.com>> wrote: >> >> >> Additionally, I propose adding a getName() method to ReflectionType that >> returns only the name of the type, regardless of nullability. Casting should >> not be required to get information from an object, but currently this is the >> only way to get the type name from ReflectionType. Most other reflection >> classes include a getName() method, this seems to have been an oversight. > > This wasn't an oversight. If we add union or intersection types then > not all types are named (for instance `ArrayAccess & Countable & > Traversable` is not a named type). This is why it doesn't exist on the > base ReflectionType. Good point, then I agree getName() should be in an extending class as in the RFC. > > I have surveyed some of the people who have voted no. Their reasons > vary but based on these conversations it seems to me that by dropping > ReflectionClassType and the associated autoloading mechanism that > overall we'd be happier. I do agree with Aaron that at least *some* > changes really need to go into 7.1. How do people feel about my > proposal to just drop autoloading and `ReflectionClassType`? This sounds reasonable to me. Aaron Piotrowski
Re: [PHP-DEV] Re: [RFC][Vote] ReflectionType Improvements
> > On Jul 9, 2016, at 8:17 AM, Levi Morrison <le...@php.net> wrote: >> > > The final vote was 5 in favor and 8 against. This RFC has been rejected. > While this RFC was rejected, ReflectionType::__toString() should still be updated to include a ? for nullable types. This is a consequence of the nullable types RFC. As mentioned in this RFC [1], the string representation of ReflectionType should be a syntax-valid representation of the type. Without adding ?, this will no longer be true. I do not view this as a BC break. In fact, it is a BC break for PHPUnit, PHPSpec, and Mockery to not make this change, as they currently depend on the string representation of ReflectionType to generate code compatible with the parent class or interface. Additionally, I propose adding a getName() method to ReflectionType that returns only the name of the type, regardless of nullability. Casting should not be required to get information from an object, but currently this is the only way to get the type name from ReflectionType. Most other reflection classes include a getName() method, this seems to have been an oversight. Joe and Davey, what are your thoughts on this? Aaron Piotrowski [1] https://wiki.php.net/rfc/reflectiontypeimprovements#backward_incompatible_changes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Iterable
Hi Stas,
> On Jul 2, 2016, at 7:00 PM, Stanislav Malyshev <smalys...@gmail.com> wrote:
>
> Do you mean that this code:
>
> $a = json_decode('{"a": 1, "b": 2, "c": 3}');
> foreach($a as $b) {
>var_dump($b);
> }
>
> will no longer work, or that it will still work, but stdClass would not
> be instanceof Iterable?
That code will continue to work just as it always has. stdClass will not be
accepted by the iterable type.
Aaron Piotrowski
Re: [PHP-DEV] [RFC] Iterable
Hi Jeremy, > On Jun 30, 2016, at 3:01 PM, Jeremy Mikola <jmik...@gmail.com> wrote: > > Was there any discussion about a special allowance being made for stdClass? > > I've noted the is_iterable(new stdClass) example and ensuing "Object > Iteration" section: > > PHP allows any object to be used with foreach. However, iterable does not > accept any object, only those implementing Traversable. Values accepted by > iterable should be designed for iteration, not any set of values (such as the > public properties of an object or a string). > > I'm on the fence if that second sentence applies to stdClass. Based on how > users typically end up with stdClass instances (e.g. casting arrays to an > object, json_decode()), I tend to think of them as logically equivalent to > associative arrays. To that end, I'd consider stdClass to be as "designed for > iteration" as any associative array -- if we can even say a stdClass was > designed at all :) > > As-is, the RFC requires users to either cast stdClass instances to an array > or decorate them with an Iterator (e.g. ArrayObject). I find this a bit > irksome, but it's certainly easy to work around. > > That said, I realize that voting is in progress and it's not my intention to > interrupt anything. I just wanted to relay a viewpoint that might not have > come up. > Generally when I've seen an object that did not implement Traversable used with foreach it has been an error. The exception of course is stdClass, particularly because of json_decode(). There was no discussion on the list of allowing stdClass, but I did discuss it with some people in chat. Our consensus was that a casting to an array was a reasonable and simple requirement to allow an instance of stdClass to be iterable. I do not think stdClass was designed for iteration, but rather is just used this way because of the behavior of foreach. I'd prefer json_decode() to return an iterable object... maybe an RFC for another day. Aaron Piotrowski
Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions
Hi Chris, > On Jun 30, 2016, at 6:15 AM, Christopher Jones <christopher.jo...@oracle.com> > wrote: > > Hi Aaron, > > I was someone who spent time on the RFC template to try and get better > quality and to capture more information about each RFC. I think your > RFC needs a lot more content before going to the vote. > > Chris > It was unclear if these changes even needed a formal RFC, but the RMs felt it would be better to have an RFC to ensure extension maintainers and others were aware of and agreed with the changes to be made. The RFC was short because I felt there wasn't much to say. However, I have added to the RFC a list of extensions and under what conditions an instance of Error will be thrown instead of a fatal or recoverable fatal error. Hopefully this is along the lines of what you were looking for. If possible, I would still like each extension maintainer to take a look at the changes made to ensure I have not missed cleaning up cases where bail-out behavior was being relied upon. Cheers! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions
Hi Dan, > On Jun 29, 2016, at 3:41 PM, Dan Ackroyd <dan...@basereality.com> wrote: > > For the record, I'm beginning to think the RFC process should probably > be slightly more orchestrated, and RFCs should have a "pre-vote" > announcement at least one week before the vote actually opens, when > the RFC author thinks the discussion of the RFC is complete. > > This point would be the time for the implementations full impact on > the PHP engine to be analyzed, and also when the final voting choice > can be discussed/challenged before the voting is actually open. > Sorry if this RFC was a little rushed. I originally hoped to make these changes for 7, then the original PR got pushed off to 7.1 and forgotten about until it was almost too late even for 7.1. I agree that a pre-vote phase could be useful, as it may help bring more attention to an RFC before voting actually opens. There seems to be a pattern of issues with RFCs not being discussed until voting has begun. The pre-vote phase could replace one week of the discussion period, so an RFC would still only need a minimum of two weeks between announcement and voting. Cheers! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions
Hi Jakub, > On Jun 28, 2016, at 12:28 PM, Jakub Zelenka <bu...@php.net> wrote: > > Hi, >> >> > Just noticed the openssl case in X509_digest and it's obviously oversight > by whoever added that bit because it should be warning as it's for all > other similar fails. I'm going to change it to warning to make it > consistent. I noticed most others were warnings in openssl, but I did not want to make assumptions about what level an error should be. If an error was E_ERROR, I assumed there was a reason it was fatal. If you change it to a warning I'll be sure not to overwrite this when merging the patch. > In general I agree with the idea but the patch should be a bit more > sensible and considers consistency with other errors in the extension. It > should be also reviewed by all active maintainers or regular contributors > to the changed extensions before it gets merged so it might be a bit late > for 7.1 I agree, either the maintainers or someone very familiar with each extension should examine the changes before merging. Note that this patch is only meant to allow catching and handling of otherwise fatal errors, not to modify overall error handling in each extension. I would rather individual extension maintainers make decisions on error levels. Thanks! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC][Vote] Throw Error in Extensions
Hello, Voting has opened on the RFC to change most conditions in extensions that raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead. RFC: https://wiki.php.net/rfc/throw_error_in_extensions <https://wiki.php.net/rfc/throw_error_in_extensions> PR: https://github.com/php/php-src/pull/1942 <https://github.com/php/php-src/pull/1942> Aaron Piotrowski
[PHP-DEV] [RFC][Vote] Iterable
Hello, Voting on the Iterable RFC has opened and will remain open until 7/2/16 at 11:59 GMT. https://wiki.php.net/rfc/iterable Thanks! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Iterable
> On Jun 18, 2016, at 6:11 PM, Dan Ackroyd <dan...@basereality.com> wrote: > > Hi Aaron, > >> does anyone have any further feedback on this proposal? > > What is the performance impact of the RFC on the standard performance > benchmarks? > > And can you comment on the performance of using iterable as a type for > parameters/return types, compared to normal classes? > > cheers > Dan Hi Dan, Great questions! This RFC has litte to no impact to the standard performance benchmarks. These benchmarks do not have functions with type declarations, so they are largely unaffected by an of the code changed by this RFC. The largest impact is to functions with scalar parameter or return type declarations. An extra integer comparison is performed during the compilation step to check if the type declaration equals IS_ITERABLE. [1] for parameter and [2] for return types. If a parameter is not a class name and has a default argument, another integer compare is performed [3]. The patch also performs an additional integer compare to IS_ITERABLE when a type not directly matching the type declaration is provided and the type declaration is a scalar type. This applies to both parameter [4] and return type declarations [5]. User code using `iterable` would only be slightly slower than using `array` or `Traversable`, as a few extra integer comparisons are made and additional function call is made to verify the type matches one of the two allowed types (see [4] and [5] again). However, the flexibility provided by `iterable` is well worth this very small penalty. For comparison, this overhead is far less than the `callable` pseudo-type as the value is not examined, only the type. In my tests against type declarations using other interfaces such as `Iterator` or `IteratorAggregate`, using `iterable` was about equal in performance. [6] Overall in my opinion, the performance impact of this RFC is negligible. Dmitry, could you take a look at the patch and do some of your own performance checks? Thanks! Aaron Piotrowski [1] https://github.com/php/php-src/pull/1941/files#diff-9760ee109b1c5922071fac1e19d117dfR332 [2] https://github.com/php/php-src/pull/1941/files#diff-9760ee109b1c5922071fac1e19d117dfR360 [3] https://github.com/php/php-src/pull/1941/files#diff-3a8139128d4026ce0cb0c86beba4e6b9R5082 [4] https://github.com/php/php-src/pull/1941/files#diff-a5fb5fd8c4f7311c6d0788763e665daaR857 [5] https://github.com/php/php-src/pull/1941/files#diff-a5fb5fd8c4f7311c6d0788763e665daaR1080 [6] https://gist.github.com/trowski/6f4b8b689228c7ba930fa658bb3c87f9 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Iterable
Hi all, I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable) to a vote in about a week, does anyone have any further feedback on this proposal? Thanks! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Throw Error in Extensions
Hello, I have written a short RFC to change most conditions in extensions that raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead. This change follows the conversion of most of these errors in the engine to thrown exceptions. RFC: https://wiki.php.net/rfc/throw_error_in_extensions PR: https://github.com/php/php-src/pull/1942 Thanks! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Iterable
Hello, I would like to propose a new iterable pseudo-type that accepts both arrays and objects implementing Traversable. Values accepted by iterable can then be used with foreach and yield from, or help to reduce type-checking logic in general. Please review the RFC here: https://wiki.php.net/rfc/iterable <https://wiki.php.net/rfc/iterable> Thanks! Aaron Piotrowski
Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too few arguments" exception
> On Jun 1, 2016, at 3:56 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > > On 01/06/2016 19:36, Aaron Piotrowski wrote: >> While this might be considered a BC break, I can't imagine there's an actual >> code out there relying on suppressing the warning just to call a function >> without enough arguments. I see no problem putting this change in 7.1. > > I think you're overestimating how much people care about their code running > without warnings. You don't have to suppress anything, just lazily ignore > warnings, or log them to a file you never get round to reading. It *might* be > that most users spot and act on the warnings, but I'm not sure how we could > know that with any confidence. > Perhaps I'm overestimating how much people care about eliminating warnings, but I doubt many functions work as intended without being supplied all required arguments. The few situations where code worked as intended when too few arguments were provided to a function are fragile and should be fixed. This change will better alert users to those problems. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too few arguments" exception
> > On Jun 1, 2016, at 5:55 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > hi, > > > Please take a look into the proposal. > > > https://wiki.php.net/rfc/too_few_args > > > The RFC is extremely simple (both proposal and implementation) and almost > completely described by the email subject. > > I think, this mini-RFC doesn't need 2-weeks discussion period, so I'm going > to start the vote on next week. > > > Thanks. Dmitry. +1 on this change. IMO, this is one of the few remaining unusual PHP behaviors that exists for no obvious reason. A function should not be called if too few arguments are provided. While this might be considered a BC break, I can't imagine there's an actual code out there relying on suppressing the warning just to call a function without enough arguments. I see no problem putting this change in 7.1. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Callable Types
Hi!
> On Apr 22, 2016, at 9:39 AM, Levi Morrison <le...@php.net> wrote:
>
>> Not much else to say, the syntax reads a bit weird/heavy being all in-line
>> with the function signature but at the same time I can't imagine how else it
>> would work that would be any better.
>
> As mentioned on Reddit and in the future scope section of union types,
> we may want to introduce named type expressions:
>
>type IntReducer = callable(int, int): int;
>
> Which would also allow unions (if passed, of course):
>
>type Iterable = Array | Traversable;
>
> It would also allow for a general type-aliasing mechanism for single
> names. This feature has been asked for in the past but I can't
> remember the use-cases so this example is not very good:
>
>type Foo = SomeFoo;
>
> Then we just use the names where we would have put the expressions:
>
>function reduce(int $a, int $b, IntReducer $reducer): int {
>return $reducer($a, $b);
>}
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
While this is somewhat off-topic of this particular RFC, since we can already
do general type-aliasing with `use`,
use SomeFoo as Foo;
perhaps similar syntax could be used for type expressions, eliminating the need
for a new keyword.
use callable(int, int): int as IntReducer;
use array | Traversable as Iterable;
Cheers!
Aaron Piotrowski
@trowski2002
trowski.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)
> On Jan 5, 2016, at 12:22 PM, Sara Golemon <poll...@php.net> wrote:
>
> On Tue, Jan 5, 2016 at 10:09 AM, Ferenc Kovacs <tyr...@gmail.com> wrote:
>>>> I don't think that would work out too well. Remember that many projects
>>>> have
>>>> error handles which convert all errors to exceptions: if you disable @
>>>> in
>>>> those projects, wouldn't their code break?
>>>>
>>> Nope.
>>> Supressed errors already reach custom error handlers:
>>> https://3v4l.org/TG8aA
>>
>> sure and most projects check the error_reporting() level against the $errno
>> like in the manual:
>>if (!(error_reporting() & $errno)) {
>>// This error code is not included in error_reporting
>>return;
>>}
>>
>> @ changes the error_reporting() level for that particular call, so those
>> custom error handler won't throw exceptions for the suppressed errors but
>> when you remove/nop @ their code would throwing stuff left and right.
>>
> Today I learned... Okay, def a problem (for a specific set of
> circumstances). And one which makes me more amenable to Ze'ev
> declare() suggestion (on a per-request bases, not per-file) as anyone
> modifying a project's codebase for testing can also modify it to
> suppress those exceptions as needed and/or just not enable the custom
> error handler.
>
Exactly. There’s no need for a new ini setting, since an error handler can be
written that ignores the current error level and throws an exception or does
whatever the coder wants.
Abuse is the only real problem with the @ operator. Coders use it in place of
proper state or error checking. However, there are legitimate uses such as with
fwrite, fopen, stream_select, etc. that Grzegorz Zdanowski and I pointed out.
Before anything can be done with the @ operator, changes will need to be made
to remove warnings for conditions that the code has no way of checking prior to
calling these functions. Setting a custom error handler before calling these
functions and removing the error handler afterwards is a clunky solution. Any
proposal to remove the @ operator needs to address how functions issuing
unavoidable warnings will be changed.
Aaron Piotrowski
https://trowski.com
@trowski2002
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)
Hi Bishop,
> On Dec 31, 2015, at 3:48 PM, Bishop Bettini <bis...@php.net> wrote:
>
> I am -1 on removing @ for 7.x series. But, I would be in favor of all
> changes that remove unnecessary error messages or add functionality to
> better work with error messages. In my mind, those are requisite steps
> before removing @.
>
I am also very much in agreement with this. There are many conditions where a
warning or other error is raised with no way to test for the condition that
will trigger the error. Before the @ can be removed, either these errors need
to be removed or they need to become an exception that can be caught. For
example, I have the following code for writing to a non-blocking stream (assume
$resource is a stream socket resource and $data is a string):
// Error reporting suppressed since fwrite() emits E_WARNING if the pipe is
broken or the buffer is full.
$written = @fwrite($resource, $data);
if (false === $written) {
$message = 'Failed to write to stream.';
if ($error = error_get_last()) {
$message .= sprintf(' Errno: %d; %s', $error['type'],
$error['message']);
}
throw new FailureException($message);
}
There is no way of knowing if the stream buffer is full before calling
fwrite(), resulting in a warning and 0 being returned. IMO, just 0 should be
returned without issuing a warning.
Aaron Piotrowski
https://trowski.com
@trowski2002
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility
Hi Sean,
> On Oct 21, 2015, at 11:17 AM, Sean DuBois <s...@siobud.com> wrote:
>
> On Wed, Oct 21, 2015 at 03:54:48PM +, Dan Ackroyd wrote:
>> Hi Sean, internals,
>>
>> While I support this RFC, it seems that the actual implementation is
>> still under discussion.
>>
>> In particular, whether the RFC is going to allow protected constants
>> in an interface is not clear.
>>
>> In the text of the RFC, on one line it says: "This RFC propose PHP
>> support class constant visibility that mirror the behaviour of method
>> and property visibility." This would imply that protected constants
>> are not allowed, as protected methods are not allowed in interfaces.
>>
>> Just below it says: "//Interfaces only support protected/public const,
>> and a compile time error will be throw for privates" Which says
>> clearly that protected constants _would_ be allowed.
>>
>> Please can you update the text of the RFC?
>>
>> Unfortunately, that may need a restart of the voting :-\ However that
>> should just be a formality as it seems to be a popular RFC.
>>
>> cheers
>> Dan
>>
>> --
> Hi!
>
> That is an unfortunate mistake on my part. The *proper* way to adjust
> visibility of a trait from a class constant is the following.
>
>trait myTrait {
>public const FOO = 'bar'
>}
>
>class myClass {
>use myTrait { FOO as protected; }
>}
>
>class myClass {
>use myTrait { FOO as private; }
>}
>
> We should not allow anything besides public in trait, this mirrors the design
> of methods.
>
> If this is right (mind just sending an ACK to make sure I got it right this
> time) I
> will update the RFC. Who decides if/when we should restart voting?
>
> thanks
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
I think you may have misunderstood. Traits should be able to have protected and
private constants. The issue that Dan pointed out is with an interface having a
protected constant in the example code, contradicting what was written prior in
the RFC about mirroring the current behavior of method and property visibility.
Interfaces should only be allowed to have public constants. Protected constants
would infer that the interface knows something about implementation, which
doesn’t make sense for an interface. I think the RFC should be updated to
remove this ambiguity.
I’m not sure if this would require the vote to be restarted, as I doubt anyone
who voted yes would now vote no with this change.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?
Hi Thomas, > On Sep 29, 2015, at 10:22 AM, Thomas Hruska <thru...@cubiclesoft.com> wrote: > > On 9/29/2015 6:52 AM, Joe Watkins wrote: >> We shouldn't reserve words on a whim ... >> >> async/await doesn't solve any problems for multithreaded programming, at >> all ... it solves problems for asynchronous programming, a different >> concept ... let's not confuse the two ... > > Actually, it does. Asynchronous and multithreaded programming are attempts > at solving the exact same problem: Simultaneously handling multiple data > streams in whatever form that takes whether that be network, hard drive, > random device XYZ, RAM, or even CPU. The former says, "Let's wait until we > can read or write and continue when we have data." The latter says, "Let's > read and write but let the OS handle context switching to give the appearance > of simultaneously handling multiple data streams." > > Async/await is both the best of and THE solution to both worlds. It allows, > on a single thread, multiple functions to be executed simultaneously, > resuming each function exactly where it left off when the async call > "returns" to the await. This feature results in *elegant userland code* that > never unexpectedly blocks, transparently fires up threads wherever necessary, > maintains mapped pools of handles behind the scenes, and resumes functions > where they left off on the original thread. There is no other equivalent > model today that doesn't involve tons of error-prone plumbing. Also, with > today's error-prone models, portions of async/await actually can't be > implemented without resorting to questionable assembler hacks (hello > 1980's!). As I said earlier, async/await is the single greatest solution to > multithreading (because very little code actually needs multiple threads in > an async/await world) but it also dramatically simplifies asynchronous > programming. Async/await also can't be implemented in libraries - it has to > be implemented in the core of the language itself and therein lies both the > genius for userland code (thank you Microsoft!) as well as the horribleness > for language designers (thank you Microsoft?). Everyone who writes "userland > code" in any given language wants this, but no one ever wants to be > responsible for correctly implementing this feature because there is much > evil hackery required to pull it off. > > For the most part, PHP follows a single-threaded, synchronous/sometimes > asynchronous model, which works well for web, and therefore means users can > somewhat fake async/await with promises/futures and no one there will really > notice because no one there will really use either feature. However, the > single-threaded model doesn't necessarily apply to CLI where some of the real > power of PHP can be leveraged - with long-running processes, unlimited CPU, > and fewer RAM limitations, a lot of possibilities open up. > > So the underlying question really is: Is PHP, particularly CLI, ever going > to leave its single-threaded model? If not, then this discussion dies here. > But if so, then async/await is the most desirable solution, albeit being > extremely evil and difficult to implement. > > https://channel9.msdn.com/Events/Build/2012/3-011 > > -- > Thomas Hruska > CubicleSoft President > > I've got great, time saving software that you will find useful. > > http://cubiclesoft.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Asynchronous programs do not solve the same problem as multithreading. Asynchronous programs cannot execute code in parallel like a multithreaded program. Asynchronous code relies on non-blocking I/O to continuously execute available tasks in a single thread of execution, but only one function is ever being executed at a time within that thread. Often separate threads are used to implement non-blocking I/O or other tasks. Asynchronous coding is a complement to multithreading, not a replacement. Implementing elegant, readable, and stable asynchronous code in userland PHP code is very possible. In fact, I’ve done exactly this with Icicle (https://github.com/icicleio/icicle). Icicle uses generators and promises to implement coroutines. When a coroutine yields a promise, the coroutine is interrupted until the promise resolves, sending or throwing the resolution value into the generator. While a coroutine is interrupted, other code in the program is given the chance to be executed. This behavior is similar to async/await, instead using a generator as the async function and yield as await. There are several packages available for Icicle that implement
Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?
Hello, > On Sep 28, 2015, at 3:29 AM, S.A.N <ua.san.a...@gmail.com> wrote: > > Are there any future plans for - async/await? > This need to know now, not to use these words to constants, and class names... > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > As a few others have pointed out, the idea has certainly been discussed, but I’m not aware of any real progress toward integrating this into PHP in the near future. Implementing async/await in PHP is certainly possible, but will be no small task. I would love to see it in a 7.x release, but I’m thinking it might have to wait until 8 just because of all the changes that would be required. I’ve created a library called Icicle (https://github.com/icicleio/icicle) that uses promises and generators to implement coroutines that use yield to interrupt execution of the coroutine until the promise is resolved. Combined with non-blocking I/O and concurrent execution implementations available in other packages designed for Icicle, you can create non-blocking and multi-threaded servers that are designed to be run from the CLI instead of the Apache SAPI, etc. If you are not familiar with Icicle, I encourage you to take a quick look at the documentation, as the proceeding paragraph will make more sense if you understand how Icicle works. I think the engine could use a similar strategy to that of Icicle for async/await. Async functions could return promises. Calling an async function with the await keyword would be similar to yielding a promise (or coroutine) within a coroutine in Icicle. If the await keyword is not used when calling an async function, this could be similar to calling Promise::wait() in Icicle, blocking control flow at that point until the promise is resolved. Perhaps in this way existing functions could be modified to support async/await while maintaining the existing blocking behavior when called without the await keyword. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Aug 6, 2015, at 3:52 AM, Niklas Keller m...@kelunik.com wrote: Scott, could you setup a RFC with a vote, so we can decide? Nikita proposed those two options: 1) Error is to be used in cases where an error is attributable to programmer mistake. 2) Error signifies a failure condition that the programmer is discouraged (and unlikely to want) to handle. It should only be dealt with at the top level. I'm in favor of 2), I would phrase it like: Error should be used if a repetitive call with the same input parameters would _permanently_ result in a failure, otherwise Exception. Regards, Niklas I’m in favor of 1), as this was my original intention of the Error branch of exceptions. Errors should be attributable to a programming mistake that should be corrected. Exception should be thrown for unexpected conditions that are not due to programmer error, but instead things like IO or permission errors. I think this is how exceptions thrown from core functions (and all functions or methods in extensions) should be organized. Based on this interpretation, random_int() should throw an Error if $min $max and random_bytes() should throw an Error if $length = 0. random_bytes() and random_int() should throw an Exception if random data cannot be generated. Another quote from Nikita’s message to the prior thread: Another interesting aspect are the zpp calls. Currently these will throw a warning and return NULL in weak mode and throw a TypeError in strict mode. I wonder whether we should be using zpp_throw for new functions, so a TypeError is also thrown in weak mode. Continuing to use the old warning+NULL behavior was a BC concern, which we don't have for new functions. The reason why I think this is worth considering, is that if all other error conditions of a function already throw, then ordinary zpp will still add one case where a different type is returned on error. This makes random_int from a function returning int, to a function returning int|null. I would also be in favor of throwing TypeError from zpp calls in new functions (and quite frankly, from zpp calls in all functions, including old functions). Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core functions throwing exceptions in PHP7
I must have overlooked a detail here. According to https://github.com/tpunt/PHP7-Reference#throwable-interface there are Throwables called Error, as a separate designation from an exception. I didn't see this in the engine exceptions RFC, so I was unaware that was even a thing. In this case, yes, as long as you can wrap it in try/catch blocks, SecurityError which extends Error and/or implements Throwable is an excellent suggestion. Previously, I thought the suggestion was to stick to triggering errors (E_ERROR, E_RECOVERABLE_ERROR, etc.). Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I believe some were suggesting triggering an E_ERROR, though most E_ERRORs in the engine have been replaced with thrown Error exceptions, so I think using E_ERROR in this case would be inappropriate. As I suggested in my prior email, I think throwing an instance of Error would be appropriate when the functions random_bytes() and random_int() fail. There are several conditions that already cause the engine to throw an Error (or subclass thereof): (1)-method(); // Throws Error declare(strict_types=1); array_map(1, 1); // Throws TypeError require 'file-with-parse-error.php'; // Throws ParseError eval($a[ = 1;); // Throws ParseError 1 -1; // Throws ArithmeticError intdiv(1, 0); // Throws DivisionByZeroError 1 % 0; // Throws DivisionByZeroError Of particular interest in the above examples is intdiv(), an internal function that can throw an instance of Error if the denominator is zero. I propose that random_bytes() and random_int() should throw an instance of Error if the parameters are not as expected or if generating a random number fails. (To avoid further debate about a subclass, the function should throw just a plain instance of Error, it can always be subclassed later without BC concerns). random_bytes() and random_int() failing closed is very important to prevent misguided or lazy programmers from using false in place of a random value. A return of false can easily be overlooked and unintentionally be cast to a zero or empty string. A thrown instance of Error must be purposely caught and ignored to produce the same behavior. As Larry pointed out, it is a very common error for programmers to not do a strict check using === against false when calling strpos(). Does anyone have a strong objection to the above proposal? If not, then I think Sammy should update his PRs to throw an Error so they can be merged before the next beta release. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core functions throwing exceptions in PHP7
On Jul 14, 2015, at 4:04 PM, Sammy Kaye Powers m...@sammyk.me wrote: Hello lovely PHP nerds, There are two open PR's for PHP7 to modify the behavior of the CSPRNG's: https://github.com/php/php-src/pull/1397 (main discussion) https://github.com/php/php-src/pull/1398 Currently the random_*() functions will issue a warning and return false if a good source of random cannot be found. This is a potential security hole in the event the RNG fails and returns false which gets evaluated as 0 in a cryptographic context. To prevent this exploit the proposed behavior will throw an Exception when the RNG fails or certain argument validation fails. This also gives the developer a graceful way to fall back to an alternate CSPRNG. Since the core functions in PHP don't throw Exceptions, there is debate on whether or not this change should be implemented. Some say the CSPRNG's should get a special pass since they will be relied on for cryptography. If we can't throw Exceptions, there were suggestions of raising a fatal error if the RNG fails. I think the argument can be boiled down to consistency vs security. We'd love to hear your feedback to decide what we should do in this context. :) Thanks, Sammy Kaye Powers sammyk.me Chicago, IL 60604 How about instead of throwing an instance of Exception, the random_*() functions throw an instance of Error on failure. A subclass of Error, such as SecurityError could also be added. As it is unlikely that the failure of these functions to generate a random value could be handled at runtime, throwing an instance of Error makes the most sense imho. Many internal functions can result in an instance of Error being thrown, particularly with declare(strict_types=1). So those looking for consistency can be satisfied that other internal functions already can behave similarly, and those looking to fail closed can be satisfied that an exception will be thrown if securely generating a random value fails. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JsonSerializable New Interface method Proposal
On Jul 13, 2015, at 1:56 PM, Dean Eigenmann dean.eigenm...@icloud.com wrote: I have updated the RFC with a new section showing the updates Sent from my iPhone On 13 Jul 2015, at 20:47, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann dean.eigenm...@icloud.com wrote: Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding Json to Object unserialization. The approach with typecasting will not work, because the function json_decode doesn't have that information. Instead something like the JMS Serializer api is probably necessary: $user = json_decode($data, 'User'); I agree with Guilherme that we need a second interface for this, especially because changing the existing one would be a BC break. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php What are the advantages of the proposed functionality versus writing a static constructor? Writing $user = json_decode_to_class($json, User::class); doesn’t seem to offer anything over $user = User::fromJson($json);. In my opinion, it seems less obvious what is happening in the former case and the latter case requires no additional functions or modification to the engine. Regards, Aaron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Subclasses
Hi Anatol, On Jul 6, 2015, at 8:29 AM, Anatol Belski anatol@belski.net wrote: Hi Bob, -Original Message- From: Bob Weinand [mailto:bobw...@hotmail.com] Sent: Monday, July 6, 2015 2:59 PM To: Anatol Belski Cc: Aaron Piotrowski; internals@lists.php.net Subject: Re: [PHP-DEV] Error Subclasses Hey Anatol Am 06.07.2015 um 12:06 schrieb Anatol Belski anatol@belski.net: Hi Aaron, -Original Message- From: Aaron Piotrowski [mailto:aa...@icicle.io] Sent: Monday, July 6, 2015 8:16 AM To: internals@lists.php.net Subject: [PHP-DEV] Error Subclasses Hello everyone! I recently pushed changes that eliminated E_EXCEPTION and allows an exception type to be provided for what were fatals in PHP, while still falling back to an E_ERROR if necessary. Since more specific Error classes can be thrown, I'd like to propose the following additions to the Error tree of exceptions: AccessError and IdentifierError. AccessError - Thrown when trying attempting to call a public, private, or abstract method, when statically calling a non-static method, or trying to use self::, parent::, or static:: outside of a class. IdentifierError - Thrown when referencing an undefined function, method, class, constant, etc. I’ve created a patch that implements the exceptions above as well as updating all the related tests: https://github.com/trowski/php-src/tree/error-subclasses https://github.com/trowski/php-src/tree/error-subclasses This patch also broadens the usage of TypeError to include conditions such as calling a method on a scalar, passing a value that does not specify a callback when one is expected, and various other conditions based on an incorrect type that otherwise are throwing plain Error objects. This patch introduces no functional changes, only more specific types of Errors are thrown from conditions that were already throwing Error objects. I was hoping this could be merged before beta 1, though I’m not sure if the time table is too tight. Thanks for the ping. While I find the idea about more specific exceptions correct, I would not recommend merging it in beta1. Reason - we have no big time now to verify the patch completeness, to discuss the exception names and areas where it's applicable. IMHO if it goes in, it has to be complete and well verified, maybe also voted (regarding namings). As the area is very public and if we find any issues later and have to rename/rework the exception names, etc. - it would be bad. So 7.1 might be a better place to target. Technically it would be anyway worky as those specialized extension classes will have the same parent. Regards Anatol I like what Aaron did here. I really think that should target 7.0. It's actually not breaking anything (really just changing the exception names). And I really think we should have a proper Error hierarchy at the release of PHP 7.0. Considering it especially one of *the* features of 7.0. But I think, at end of beta 2 or so, we really should do a final review of all the Errors in order to ensure everything is aptly named and used. Thanks for the feedback. That's what I said as well - the idea is correct. Unfortunately it is too late. Just to remind - Trowable was too late as well by the time no more new RFCs was allowed. But as it was important and still acceptable in the alpha phase, so there was an exception for the exception RFC. This gives a good base to for further improvements. Now with actual subject - it's has nothing to do with the Trowable directly as it's in. However I don't think it's to decide by me, you or anyone else alone, whether the names fit good. Also in such a short period it's hard to check whether alle the needed places are touched and everything is ok. These are two main concerns preventing this to go in, IMHO. And we cannot target beta2 because it's a feature freeze already tomorrow when beta1 is tagged. One can argue, sure ... but some when there should be a clean cut. Then we should be working on fixing bugs and stabilizing the codebase. This PR is not a bug fix. Thus, 7.1 - this well thought and good tested feature would be welcome there. Starting with the time we've branched the 7.0 dev branch (middle September), the door is popen for any good features and RFCs. Now, having what we have - Error where it is, nothing is lost, as AnotherError extends Error. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There are no functional issues with the patch, since as Bob pointed out, it is only changing the names of the exceptions thrown. I agree that if beta 1 is to be the feature freeze then this will have to wait. There certainly is not enough time if we want to discuss naming or the situations where each type of Error is thrown. I see no problem with waiting on this until 7.1
[PHP-DEV] Error Subclasses
Hello everyone! I recently pushed changes that eliminated E_EXCEPTION and allows an exception type to be provided for what were fatals in PHP, while still falling back to an E_ERROR if necessary. Since more specific Error classes can be thrown, I'd like to propose the following additions to the Error tree of exceptions: AccessError and IdentifierError. AccessError - Thrown when trying attempting to call a public, private, or abstract method, when statically calling a non-static method, or trying to use self::, parent::, or static:: outside of a class. IdentifierError - Thrown when referencing an undefined function, method, class, constant, etc. I’ve created a patch that implements the exceptions above as well as updating all the related tests: https://github.com/trowski/php-src/tree/error-subclasses https://github.com/trowski/php-src/tree/error-subclasses This patch also broadens the usage of TypeError to include conditions such as calling a method on a scalar, passing a value that does not specify a callback when one is expected, and various other conditions based on an incorrect type that otherwise are throwing plain Error objects. This patch introduces no functional changes, only more specific types of Errors are thrown from conditions that were already throwing Error objects. I was hoping this could be merged before beta 1, though I’m not sure if the time table is too tight. Cheers, Aaron Piotrowski
Re: [PHP-DEV] Fix division by zero to throw exception (round 2)
On Jul 4, 2015, at 6:30 PM, Bob Weinand bobw...@hotmail.com wrote: Am 05.07.2015 um 00:50 schrieb Andrea Faulds a...@ajf.me: Hey Sherif, On 4 Jul 2015, at 21:56, Sherif Ramadan theanomaly...@gmail.com wrote: I'm proposing that we reconsider removing the warning from floating point division and here's why. While IEEE 754 defines special values for floating point arithmetic when division by zero occurs, there's nothing stopping the language from providing useful error information to the user, which may help them debug potentially buggy code. It's true that it's not exceptional since there is now well defined behavior in the case of changing division by zero to IEEE 754 standard in PHP. However, PHP didn't actually distinguish between integer division and floating point division prior to intdiv. So in the case of division by zero the warning was useful to help someone catch their mistake. Now, the onus is on the person writing the code to decipher whether or not they created a potential division by zero scenario by deducing how they arrived at INF at some point in their code. This is creating an unnecessary burden when we've always provided the user with the useful error information in the past. I'm not sure why we should remove it now, but based on this conversation I can see that the confusion resonates around this urge to convert the warning to an exception and the conflict of it not being exceptional (in the case of floating point math) since there is now well defined behavior. So my conclusion is that... Yes, it's not exceptional. No, we shouldn't throw an exception for division by zero in floating point arithmetic. No, we shouldn't remove the warning since it still provides useful information to the person debugging the code. Debugging the code without this warning can be a monstrosity since you won't necessarily know at which point in a compounded operation the division by zero occurred. For example, PHP_INT_MAX ** PHP_INT_MAX creates an overflow resulting in INF. Though 0 / INF results in 0. So an operation like (1 / ($x / PHP_INT_MAX ** PHP_INT_MAX) where $x happened to be 0 in one particular case, makes both hunting down and reproducing the bug quite difficult without some direction. The warning has historically provided this direction in the past and I believe that removing it now will only further the confusion. I don't think people actually care about whether or not we keep the warning. I think what they would care about more is the consistency of the return value and defined behavior, which I believe we have already addressed very well. Yeah, keeping it around makes sense. Thing is, if it’s a problem, you can silence it with @, so @($a / $b). If that’s slow, we could optimise it (make it call div_function_no_error or something?) At that point it's just a bit weird. The @ operator IMO shouldn't be the recommended way to handle fundamental operations. You ideally just check if the divisor is 0 and then do the operation. And at that point, we should just throw the DivisionByZeroError. Honestly, a warning is just the wrong thing to use. Either you enable it (like double division in C) or disable it completely (runtime exception in C). I can get behind both, but not behind a warning. Thanks, Bob. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 In my opinion division by zero should result in some notification. I think a DivisionByZeroError seems the most appropriate. If a user wants the result of NaN or Inf it is trivial to write a function for that purpose. Perhaps PHP could provide such a function. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Jul 1, 2015, at 1:06 PM, Sara Golemon poll...@php.net wrote: On Tue, Jun 30, 2015 at 10:36 PM, Joe Watkins pthre...@pthreads.org wrote: Another possible issue is engine integration: $string = (UString) $someString; $string = (UString) someString; That sounds as a cool idea to discuss as a completely separate, unrelated RFC, and not specific to UString. e.g. $obj = (ClassName)$arg; /* turns into */ $obj = new ClassName($arg); So you could use casting with any class which supports single-argument constructors. But again, orthogonal to this RFC. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Expanding on this idea, a separate RFC could propose a magic __cast($value) static method that would be called for code like below: $obj = (ClassName) $scalarOrObject; // Invokes ClassName::__cast($scalarOrObject); This would allow UString to implement casting a string to a UString and allow users to implement such behavior with their own classes. However, I would not implement such casting syntax for UString only. Being able to write $ustring = (UString) $string; without the ability to do so for other classes would be unusual and confusing in my opinion. If an RFC adding such behavior was implemented, UString could be updated to support casting. Obviously a UString should be able to be cast to a scalar string using (string) $ustring. If performance is a concern, UString::__toString() should cache the result so multiple casts to the same object are quick. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Jul 1, 2015, at 2:25 PM, Anatol Belski anatol@belski.net wrote: Expanding on this idea, a separate RFC could propose a magic __cast($value) static method that would be called for code like below: $obj = (ClassName) $scalarOrObject; // Invokes ClassName::__cast($scalarOrObject); This would allow UString to implement casting a string to a UString and allow users to implement such behavior with their own classes. However, I would not implement such casting syntax for UString only. Being able to write $ustring = (UString) $string; without the ability to do so for other classes would be unusual and confusing in my opinion. If an RFC adding such behavior was implemented, UString could be updated to support casting. Obviously a UString should be able to be cast to a scalar string using (string) $ustring. If performance is a concern, UString::__toString() should cache the result so multiple casts to the same object are quick. Hi, One way doing this is already there thanks https://wiki.php.net/rfc/operator_overloading_gmp . Consider $n = gmp_init(42); var_dump($n, (int)$n); However the other way round - could be done on case by case basis, IMHO. Where it could make sense for class vs scalar, casting class to class is a quite unpredictable thing. While users could implement it, how is it handled with arbitrary objects? How would it map properties, would those classes need to implement the same interface, et cetera? We're not in C at this point, where we would just force a block of memory to be interpreted as we want. Regards Anatol Hello, I was thinking that the __cast() static method would examine the parameter given, then use that value to build a new object and return it or return null (which would then result in the engine throwing an Error saying that $scalarOrValue could not be cast to ClassName). It was just a suggestion to see what others thought because someone suggested supporting casting syntax such as $ustring = (UString) $scalarString. I don’t really care for either method though (__cast() or enabling casting just for UString), as they don't offer any advantage over writing new UString($string) or UString::fromString($string). Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved zend_string API
the macros instead? Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: trowski
Quickly applying bug fixes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On Jun 25, 2015, at 2:08 PM, Marc Bennewitz dev@mabe.berlin wrote: I would really like to see directly calling a string of Class::method be fixed for 7.0. It's currently resulting in a fatal error and is inconsistent with call_user_func[_array], is_callable and the callable type-hint. There is also a PR open since April 2014 : https://github.com/php/php-src/pull/659 Actually this has already been fixed for PHP 7, see this commit: https://github.com/php/php-src/commit/07ecfc7ba9dabc4dfb2a068744b76540308b Thanks, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current behavior;
http://3v4l.org/HkRQ7 http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined function
Foo::()
This behavior is inconsistent!
Thanks
Marc
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Thanks,
Aaron Piotrowski
Re: [PHP-DEV] [RFC][VOTE] Throwable Interface
Hello, Voting for the Throwable Interface RFC has been changed to remain open only through today at midnight EST so the patch can be merged and tested before the next alpha release. https://wiki.php.net/rfc/throwable-interface Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On Jun 15, 2015, at 6:56 AM, Anatol Belski anatol@belski.net wrote:
Hi Dmitry,
-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: Monday, June 15, 2015 10:53 AM
To: Aaron Piotrowski
Cc: Anatol Belski; PHP Internals
Subject: Re: [PHP-DEV] [RFC] Throwable Interface
Hi,
I made a quick code review, and I don't see any technical problems in
implementation.
1) Anyway, I think it's a bad idea to rename EngineException (and others)
into
Error(s).
This will prevent using class Error in applications, and may potentially
break
some of them.
I also don't like renaming in ~440 tests (I didn't review all these changes).
2) I think it's better to move zend_ce_throwable
definition/initialization from zend_interfaces.h/c into zend_exception.h/c.
At least, this will allow arg_info reuse. (it's missed now, but should be
added
now or in the future).
3) In ext/simplexml/tests/SimpleXMLElement_xpath_3.phpt EngineExcpetion is
not renamed into Error.
Thanks for the review. I've also tested the branch which has today's master
merged in, by now it doesn't show any functional regression.
Actually I part your first concern about Error. Spent some time phishing for
class Error on github and found three apps doing this without namespace.
But that's from 100 search result pages. And those three apps are forked zero
to 1 times, so pretty much low usage. This will likely break more in the
world, we hardly know.
The current RFC can't be changed while in voting. But how it looks like, the
principle of the Trowable RFC is something everyone agrees on. Maybe do
another RFC in parallel for better names? Still I'd stand for taking it into
alpha2 - if we want to have it, better to arrange it in a way that it doesn't
cause unnecessary delays in the release process.
Hi Dmitry and Anatol,
I fixed three more tests that were missed when merging, as I only checked those
that failed after the merge. I should have used find and replace again after the
merge, which is how I changed the majority of the tests. Only a few tests
required
manual changes, mostly because of hard-coded string lengths, and one or two
tests used the class name Error. Note that Nikita recently changed nearly all
these tests and many others when updating the phrasing on uncaught exception
messages. While many tests were changed, users won’t have such issues
because they aren’t catching these exceptions yet.
Would you like me to move zend_ce_throwable to zend_exceptions.h/c or is that
something you’d take care of after the merge?
I am strongly against naming something _Exception if it doesn’t extend
Exception. This was most of the point of the RFC, as I find code such as
`catch (Exception $e) { … } catch (EngineException) { … }` very unintuitive and
I
feel it will lead to confusion for users.
I sifted through search results on GitHub looking for usage of Error before
proposing the RFC and also found only a couple of actual uses from generally
unused projects. Most of the other results are forks of an old version of
PHPUnit.
Namespaces have been around long enough that most libraries and apps will not
have such a class in the root namespace. As far as BC breaks go, renaming a
class in an app is a fairly trivial one to make, and one that very, very few
people
will have to do. I feel having a simple name such as Error is more important
than
avoiding naming conflicts with a very small amount of code.
Regards,
Aaron Piotrowski
Re: [PHP-DEV] [RFC] Throwable Interface
On Jun 15, 2015, at 9:53 AM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Jun 15, 2015 at 4:55 PM, Aaron Piotrowski aa...@icicle.io mailto:aa...@icicle.io wrote: On Jun 15, 2015, at 6:56 AM, Anatol Belski anatol@belski.net mailto:anatol@belski.net wrote: Would you like me to move zend_ce_throwable to zend_exceptions.h/c or is that something you’d take care of after the merge? I don't care about this a lot. I just think it's better. If you don’t see any problems, please, move the code. Moving the definition of zend_ce_throwable to zend_exceptions.h/c requires either: 1. Moving #define REGISTER_ITERATOR_INTERFACE from zend_interfaces.c to zend_interfaces.h so it is available in zend_exceptions.c (I could take the opportunity to rename this macro to REGISTER_INTERFACE). 2. Defining a macro in zend_exceptions.c that is identical to REGISTER_ITERATOR_INTERFACE. Which option sounds better? Aaron Piotrowski
Re: [PHP-DEV] [RFC] Throwable Interface
On Jun 15, 2015, at 4:02 PM, Anatol Belski anatol@belski.net wrote: I would then suggest Aaron to stick to the minimal voting period (announcing this as early as possible), if the voting passes - then merge the branch on Wednesday. This way we would have nearly one week to test and do fixes in master. Kalle, Ferenc, how do you feel about this? Is changing the voting dates on the RFC to run only through tomorrow allowed? If so, I can make that change so it can be merged this week. Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On Jun 14, 2015, at 11:31 AM, Anatol Belski anatol@belski.net wrote: Hi Dmitry, I would go by accepting this. Furthermore – if you feel that the implementation is stable enough and does not BC, I would suggest to have it already in the alpha2. As there seems to be at all no resistance in the votes (no even single “no” voter yet), nor strong objection here on the lists. The minimal voting period is 1 week, so theoretically if it were ended on Wed (the voting RFC doesn’t disallow this) – there were still some time to do extensive testing and fixes. Alpha2 is the time where a) a lot of users will be able to test it and b) it still can be reverted in the worst case. What do you think? Regards Anatol I will have some time to resolve the merge conflicts later today, so I will be happy to take care of that. Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Throwable Interface
Hello, Voting is now open on the Throwable Interface RFC: https://wiki.php.net/rfc/throwable-interface Please remember that this vote is not about creating separate exception branches, as that decision was made in the Exceptions in the Engine RFC. This vote is about having short, concise, more intuitive names that clarify the separation rather than obfuscating it. Throwable and Error make stacked catch blocks cleaner with more obvious behavior. Voting no means keeping BaseException, EngineException, etc. that do not extend Exception, but are named as though they do. Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On Jun 10, 2015, at 2:37 AM, Dmitry Stogov dmi...@zend.com wrote: I also like EngineException more than Error. I think EngineException has a couple of problems with it: 1) EngineException doesn’t really accurately represent the reason for the error. For example, passing the wrong type to a function isn’t an ‘engine' problem, it’s an error in user code. In the future it may be desirable to add more classes in this exception branch, and I think a more general name would be more desirable. 2) The name EngineException implies it descends from Exception. I worry that this will cause a lot of confusion for users thinking they have to be catching Exceptions when the problem is actually an error in their code. Discussing why you should not catch Error objects is easier than trying to explain why certain Exception objects should not be caught. Error is best choice for the name of the second exception branch. It has precedent in other languages and is less likely to cause confusion. Most user code that would collide with the name is likely very outdated, but still could easily be updated in only a few minutes. Regards, Aaron Piotrowski
[PHP-DEV] Re: [VOTE] Throwable Interface
On Jun 10, 2015, at 12:29 PM, Christoph Becker cmbecke...@gmx.de wrote: Aaron Piotrowski wrote: Voting is now open on the Throwable Interface RFC: https://wiki.php.net/rfc/throwable-interface When will the voting end? It seems to be best to clearly state that in the RFC also. -- Christoph M. Becker Thank you, I’ve added this to the RFC. Voting will be open through June 24th. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Throwable Interface
On Jun 10, 2015, at 10:13 AM, Levi Morrison le...@php.net wrote: On Wed, Jun 10, 2015 at 9:05 AM, Aaron Piotrowski aa...@icicle.io wrote: Hello, Voting is now open on the Throwable Interface RFC: https://wiki.php.net/rfc/throwable-interface Not even 24 hours ago you asked for questions and comments (which there have been) and now it's in voting? That's a bit impatient... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php We spoke in chat, but I wanted to reply to this for the record. Most of the comments and discussion (both here and in chat) was in favor of the RFC, so I decided that since the RFC had been up for discussion for over two weeks that it should be put to a vote. Since this change needs to be made for PHP 7.0, the matter needs to be settled soon. Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Throwable Interface
On Jun 10, 2015, at 7:42 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Aaron, On Thu, Jun 11, 2015 at 2:50 AM, Aaron Piotrowski aa...@icicle.io mailto:aa...@icicle.io wrote: On Jun 10, 2015, at 12:29 PM, Christoph Becker cmbecke...@gmx.de mailto:cmbecke...@gmx.de wrote: Aaron Piotrowski wrote: Voting is now open on the Throwable Interface RFC: https://wiki.php.net/rfc/throwable-interface https://wiki.php.net/rfc/throwable-interface When will the voting end? It seems to be best to clearly state that in the RFC also. -- Christoph M. Becker Thank you, I’ve added this to the RFC. Voting will be open through June 24th. You need new mail thread titled [RFC][VOTE] Throwable Interface. Otherwise, people like me will miss it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net mailto:yohg...@ohgaki.net I apologize, still learning all the protocol. I followed the format of the voting notification I received yesterday, which also did not include [RFC] in the title. I will send another email. Thanks, Aaron Piotrowski
[PHP-DEV] [RFC][VOTE] Throwable Interface
Hello, Resending this notification with the proper subject line. Voting is now open on the Throwable Interface RFC: https://wiki.php.net/rfc/throwable-interface Voting will remain open through June 24th. Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
