Hi everyone:
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
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
While attempting this I ran into the need to use GC_ADDREF() or else the
returned sub-object data would be gargled. Here is an example struct:
typedef struct _php_raylib_camera2d_object {
Camera2D camera2d;
HashTable *prop_handler;
php_raylib_vector2_object *offset;
This is fixed in master.
Thanks. Dmitry.
On Fri, Mar 5, 2021 at 4:43 PM Dennis Birkholz
wrote:
> Hello,
>
> I was also able to reproduce the error.
>
> I used the latest available "daily" cloud image for Debian Buster and
> created a small recipe to reproduce. Hopefully this helps in finding
Hey Tianfeng.Han,
> I am afraid that fiber can only be used in the amphp framework and is of
no value to other php projects.
My name is Cees-Jan and I'm one of the core maintainers of ReactPHP, and I
strongly disagree with this statement. While it might not be of value to
Swoole, it will provide
On 10.03.2021 19:06, Matthew Brown wrote:
> Ondřej Mirtes and I present an RFC for the noreturn type:
> https://wiki.php.net/rfc/noreturn_type
I don't like that type covariance would be allowed. Why such an
exception to the rules?
--
Aleksander Machniak
Kolab Groupware Developer
On 10/03/2021 19:21, Matthew Brown wrote:
If the Zend engine hits that operand — which only happens if a
throw/exit *hasn't* been encountered — it emits a TypeError.
Right, that should probably be spelled out in the RFC. Checking at
run-time in that way is consistent with actual return
Hi Matthew,
I am concerned with some edge cases. What if a function both returns and
throws at the same time? For example:
function a():noreturn {
return throw new Exception('Boom!');
}
or
function a():noreturn {
try {
throw new Exception('Boom!');
} finally {
return;
}
}
On 10/03/2021 18:06, Matthew Brown wrote:
Ondřej Mirtes and I present an RFC for the noreturn type:
https://wiki.php.net/rfc/noreturn_type
Thanks for the proposal, I can certainly think of uses for it.
I am however slightly confused by what exactly the implementation
checks, and when. Is
On 10.03.2021 at 16:54, Matthew Brown wrote:
> Long-time internals lurker, first-time RFC creator & C coder.> > Could I get
> some karma please?
Sure! RFC karma has been granted for mattbrown. Best of luck with the RFC!
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development
Thank you all for voting, which is now closed. This RFC has been accepted
on the final tally.
Regards
David Gebler
On Thu, Feb 25, 2021 at 2:13 PM David Gebler wrote:
> Thanks Marco, objection understood. I think Nikita's already said what I
> would say, from my view I can only reiterate I
> 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
On Wed, Mar 10, 2021 at 2:22 PM Matthew Brown
wrote:
> On Wed, 10 Mar 2021 at 13:55, Rowan Tommins
> wrote:
>
> > I am however slightly confused by what exactly the implementation
> > checks, and when. Is it actually looking for "exit" and "throw"
> statements?
> >
>
> No. Any function
Hi Rowan,
On Wed, Mar 10, 2021, 20:55 Rowan Tommins wrote:
> On 10/03/2021 18:06, Matthew Brown wrote:
> > Ondřej Mirtes and I present an RFC for the noreturn type:
> > https://wiki.php.net/rfc/noreturn_type
>
>
> Thanks for the proposal, I can certainly think of uses for it.
> The other
On Wed, 10 Mar 2021 at 13:55, Rowan Tommins wrote:
> I am however slightly confused by what exactly the implementation
> checks, and when. Is it actually looking for "exit" and "throw" statements?
>
No. Any function annotated with `: noreturn` causes the engine to insert
a
> On Mar 10, 2021, at 13:24, Aleksander Machniak wrote:
>
> On 10.03.2021 19:06, Matthew Brown wrote:
>> Ondřej Mirtes and I present an RFC for the noreturn type:
>> https://wiki.php.net/rfc/noreturn_type
>
> I don't like that type covariance would be allowed. Why such an
> exception to the
Sara,
I'd love to throw my hat into the ring! I am new to internals but have
been developing in php for 20+ years. I would love to start contributing
back to the community.
--Gunnard
Hey!
Long-time internals lurker, first-time RFC creator & C coder.
Could I get some karma please?
Best wishes,
Matt
Thanks!
On Wed, 10 Mar 2021 at 11:30, Christoph M. Becker wrote:
> On 10.03.2021 at 16:54, Matthew Brown wrote:
>
> > Long-time internals lurker, first-time RFC creator & C coder.> > Could I
> get some karma please?
> Sure! RFC karma has been granted for mattbrown. Best of luck with the
>
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
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
Hello, Joseph! I faced exactly the same problems and believe that the
Observer API is necessary.
To solve a similar problem, I implemented my own API over FFI, however,
it does not work very stable (I have little experience in send api), but
it may help to solve your problems:
Sara,
I'd love to throw my hat into the ring! I am new to internals but have
been developing in php for 20+ years. I would love to start contributing
back to the community.
--Gunnard
@gunnard
gunnard.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
> 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
> 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
Den ons. 10. mar. 2021 kl. 20.22 skrev Dan Ackroyd :
>
> 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
Hey Matthew,
I have look at the implementation a few days ago, and was patiently waiting for
the RFC.
a huge +1 from me ( even tho i can't vote ), `noreturn` type would be a great
addition to PHP type system.
Regards,
Saif.
‐‐‐ Original Message ‐‐‐
On Wednesday, March 10, 2021
On Wed, 10 Mar 2021 at 16:04, Kamil Tekiela wrote:
> I am concerned with some edge cases. What if a function both returns and
> throws at the same time? For example:
>
> function a():noreturn {
> return throw new Exception('Boom!');
> }
>
> or
>
> function a():noreturn {
> try {
> throw new
Hello Internals,
I congratulate you for the successful release of PHP 8.0.3. I also
appreciate your efforts to bring union types and return type hints.
Although the type hints have made debugging more easier, it has created
another problem for those that use 'return' to end the execution of a
On Wed., Mar. 10, 2021, 11:22 Matthew Brown,
wrote:
> If a significant number agree I can add a secondary vote on noreturn vs
> never, but never introduces more of a BC risk.
>
Hi Matt,
I like this RFC, but I'd like to see the RFC cover if any other languages
have a similar return type.
The
On 10.03.2021 20:28, Ben Ramsey wrote:
>> I don't like that type covariance would be allowed. Why such an
>> exception to the rules?
>
> It’s not an exception. Returns are covariant. Parameters are
> contravariant. Since `noreturn` is a subtype of all other types, it
> behaves as expected.
I see
On Wed., Mar. 10, 2021, 02:16 韩天峰, wrote:
> I am afraid that fiber can only be used in the amphp framework and is of
> no value to other php projects.
>
Hi,
I'd like to see you elaborate on this point. Are you able to provide
anything to back up this claim?
I don't see anything that is
Am 11.03.2021 um 07:51 schrieb Peter Stalman:
I like this RFC, but I'd like to see the RFC cover if any other languages
have a similar return type.
The RFC has a "Prior art in other interpreted languages" section.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Wed., Mar. 10, 2021, 22:59 Sebastian Bergmann, wrote:
> Am 11.03.2021 um 07:51 schrieb Peter Stalman:
> > I like this RFC, but I'd like to see the RFC cover if any other languages
> > have a similar return type.
>
> The RFC has a "Prior art in other interpreted languages" section.
>
Oh, my
34 matches
Mail list logo
