Re: [PHP-DEV] Re: [IDEA] allow extending enum

Am Mi., 29. März 2023 um 12:49 Uhr schrieb Rokas Šleinius : > Sidenote, just asking :) was this expected behaviour that I had to > analyse PHP source of the Docuwiki, create a new input field in > the registration form named "spam" and fill it to gain a wiki > username? Otherwise it would just

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

Hey Nikita, I'd like to propose using HackerOne instead of bugs.php.net for security issues: https://www.hackerone.com/company/open-source-community Best, Niklas Am Di., 2. Nov. 2021 um 15:19 Uhr schrieb Nikita Popov : > Hi internals, > > The migration from bugs.php.net to GitHub issues has

Re: [PHP-DEV] intersection types and null for defaults, properties and return types

> > > > > nicolas-grekas wrote on the PR: > > > > > ?X cannot be confused with > > > > > > > > It confused me. A compiler might understand it, but as a human I have > > > > trouble understanding it. > I think ?X would be a pretty poor syntax choice, as it's ambiguous as many others said:

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

Hey all, please remember that you can also use php -r to quickly evaluate expressions, e.g. generating a random password: php -r 'var_dump(bin2hex(random_bytes(16)));' I'm in favor of removal without readline. Best, Niklas Rowan Tommins schrieb am Mi., 12. Mai 2021, 22:46: > On 12/05/2021

Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT

Sara Golemon schrieb am Fr., 23. Apr. 2021, 00:21: > On Thu, Apr 22, 2021 at 3:27 PM Niklas Keller wrote: > >> Do you have a link to places where frameworks are doing this? I built a > >> contrived example which I think summarizes the behavior you described > here: >

Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT

Sara Golemon schrieb am Do., 22. Apr. 2021, 17:27: > On Thu, Apr 22, 2021 at 12:58 AM Niklas Keller wrote: > > Thank you for your work. I think this is a really good safety check to > have. I'd however go a step further and also throw on NUL in > password_verify. > > &

Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT

Sara Golemon schrieb am Do., 22. Apr. 2021, 03:47: > I have this notion that we've discussed this before, I'm certain I knew > that bcrypt wasn't binary safe, but someone reminded me that > password_hash() could be called with null bytes in the password itself and > that is just SCREAMING to

Re: [PHP-DEV] wiki.php.net upgrade

Hey all, the wiki is up to date now with the help of @Sergey Panteleev . :-) Sorry for the upgrade downtime being slightly longer than intended. Best, Niklas

Re: [PHP-DEV] wiki.php.net upgrade

Hey Sergey, I've tried the same yesterday, but the auth plugin does no longer work for me. I get a 404 after trying to sign in. 2692 files changed, 35365 insertions(+), 102210 deletions(-) Dokuwiki changed a lot in the latest release, e.g. namespacing and refactoring quite a bit. I'll need to

Re: [PHP-DEV] [VOTE] Fibers

the implementation is merged into core. Best, Niklas Am Mo., 22. März 2021 um 21:08 Uhr schrieb Niklas Keller : > >> I hope others would >> >> play with it more as well if we had more time. Any objections? >> > >> > Yes, I object. >> > >>

Re: [PHP-DEV] [VOTE] Fibers

> > >> I hope others would > >> play with it more as well if we had more time. Any objections? > > > > Yes, I object. > > > > You've been around PHP internals long enough to see the drama has > > occurred on other RFCs where people have been > > cajoled/pressured/threatened to either suspend votes

Re: [PHP-DEV] [VOTE] Fibers

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 > >

Re: [PHP-DEV] [VOTE] Fibers

Hey Josh, > > This is a very valid concern to have. However, this code won't simply > break if executed asynchronously. > > It only breaks if the same method (or other methods making use of the > same state) is executed concurrently on that object. > > I understand this, but of course this will

Re: [PHP-DEV] [VOTE] Fibers

Hey Josh, > Apologies, this is a long one! > > This RFC strikes me as being very dangerous. Implicitly allowing code > which is synchronous by design to be executed asynchronously seems > sure to lead to very subtle, unpredictable, confusing and dangerous > bugs. > Thank you for sharing your

Re: [PHP-DEV] [RFC] Fibers

Hey Nikita, Thank you for the proposal. Ergonomics of async I/O in PHP certainly leave > something to be desired right now, and improvements in this area are > welcome. > > Despite your explanations in the RFC and this thread, I'm still having a > hard time understanding the purpose of the

Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on iterables

> > I want to re-iterate my opinion on this discussion thread: anything > with a prefix is a hard-no from me. Namespaces are literally designed > for this, and I will not vote "yes" to `iter_all`, `iterable_all`, > etc, no matter what the prefix is. Anything without a namespace is a > no from me.

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

Hey all, > > > Given that it's a very small change, the RFC is probably not necessary, > in > > which case it's not too late, however I'd like some clarification about > > what this actually offers over defaulting to 1.0. > One thing it offers is detecting truncated responses. Servers will often

Re: [PHP-DEV] VCS Account Request: ondrejmirtes

Am Sa., 11. Juli 2020 um 08:04 Uhr schrieb Kalle Sommer Nielsen < ka...@php.net>: > Hi > > Den lør. 11. jul. 2020 kl. 08.55 skrev Ondřej Mirtes : > > Oh, thank you. Should I fill out this form? > https://wiki.php.net/?do=register > > Yes that is the one. Someone with wiki admin karma needs to

Re: [PHP-DEV] Graceful timeout

Hey David, I guess you're looking for a preemptive timeout. I guess an alarm signal and PHP's async signal handling will be your best bet here. In case you're looking for a cooperative timeout, https://amphp.org/ and it's `Amp\Promise\timeout()` / `TimeoutCancellationToken` might be helpful.

Re: [PHP-DEV] Deprecating uniqid()

Rowan Tommins schrieb am Mo., 4. Mai 2020, 10:59: > On Mon, 4 May 2020 at 06:27, Andreas Heigl wrote: > > > > > As replacement I could think of showing people the way to UUIDs. > > > > > Although the name sounds similar, I don't think UUID would be a good > replacement for uniqid(). In my

Re: [PHP-DEV] Deprecating uniqid()

Hey Allen, there's been discussion on whether we should deprecate or replace its functionality. Without changing the output format, it's impossible to have enough entropy. Without consensus on the best way forward, I've just never cared to put this to a vote. I'll happily collaborate on moving

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

Hey Benas, a question has come up whether we even need the PhpAttribute / Attribute attribute at all. We could prevent any conflict if we just delete it. Best, Niklas Am Di., 28. Apr. 2020 um 17:37 Uhr schrieb Benas IML : > > Hey internals, > > Since it's safe to say that the Attributes v2 RFC

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

Hey Benas, I've also tried to get that change into the original RFC, but wasn't able to. I'm in favor of an amendment RFC to change the name to Attribute. Best, Niklas Am Di., 28. Apr. 2020 um 17:37 Uhr schrieb Benas IML : > > Hey internals, > > Since it's safe to say that the Attributes v2

Re: [PHP-DEV] Re: [RFC] Attributes v2

Hey Benjamin, thanks for your answers! > <> would best require a namespace (PHP\Attributes) as I feel > claminig "Attribute" class in the main namespace might cause problems for > users. While this is true, I don't see how Attribute is different to any classes introduced in the "recent"

Re: [PHP-DEV] Re: [RFC] Attributes v2

Hey Benjamin, I haven't really followed the discussion, so sorry if anything I'm writing has already been discussed. Attributes / annotations are one of the two things I currently miss most in PHP (the other being generics), so thanks for the work on that! There are a few points that seem odd

Re: [PHP-DEV] Re: Changing the generated name for anon classes

Hi Nikita, while we're changing the naming scheme, could we also get rid of the NUL byte, please? Binary in logs due to things like get_class really isn't that nice. Regarding checking whether something is an anonymous class, how about adding a function to check whether a class name is an

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> Hi Internals, > > After a couple of years of incubation, I am happy to offer a second version > of this RFC: > > https://wiki.php.net/rfc/request_response > > It proposes an object-oriented approach around request and response > functionality already existing in PHP, in order to reduce the

Re: [PHP-DEV] Warn when declaring required parameter after optional one

Hi Nikita, while this is a rather small change, it has quite some BC impact, as not all old code has been adjusted to run on PHP 7.1+ only using nullable types. I'd like to see an RFC with a vote for this. Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] fdiv() function

Hi Nikita, > The fdiv() function will perform a floating-point division while treating > division by zero as a perfectly legal operation, and will not emit any kind > of diagnostic in that case. Instead it will return the INF/-INF/NAN result > mandated by IEEE-754. It mirrors the existing fmod()

Re: [PHP-DEV][RFC] Normalize array's "auto-increment" value on copy on write

> Maybe it would be good to add a secondary vote to decide if this should be > implemented in PHP 7.4 or PHP 8. Missed that, it should definitely target PHP 8, not 7.4. Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC] Normalize array's "auto-increment" value on copy on write

Hi Wes, I don't think it'll work the way you described. I think we have to make the auto-increment value be entirely dependent on the values in the array for it to work. Consider the following example combining your initial assertion in the RFC with an example further down: ```

Re: [PHP-DEV] open_basedir?

> > That's exactly the reason why I'm for removing it. There will always > > be ways to circumvent open_basedir and setups like this are insecure. > > It gives a false sense of security. It's not better than nothing, > > because most hosting providers would opt for a real solution instead > > of

Re: [PHP-DEV] PHP header files, restrict to declaring code only

Instead of introducing a declare option or special open tag, how about another "include" construct, that only allows side-effect free (apart from class loading) operations? e.g. "require_noexec 'foobar.php'" Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] open_basedir?

> I'm against deprecating it or removing it. > > As said earlier, it has some security value, especially with mass > hosting. If I'm hosting thousands of websites for thousands of users, > using chroot is not doable, and open_basedir is a good alternative (at > least it's better than nothing). > >

Re: [PHP-DEV] open_basedir?

Am Di., 7. Mai 2019 um 12:11 Uhr schrieb Nikita Popov : > > Hi internals, > > The open_basedir ini setting has two significant problems: > > 1. It is a major performance hit, because it disables the realpath cache. > > 2. Many people think it is a security feature and use it as such. However, >

Re: [PHP-DEV] [RFC] [Vote] Change the precedence of the concatenation operator

Hey Bob, in the RFC you mention: > While this is a subtle behavior change in that it will give different outputs > without notice or warning, it is trivially possible to statically analyze the > code and find all instances where this happens. On the other hand, there's: > PHP 8, with a

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

Am Mo., 29. Apr. 2019 um 09:03 Uhr schrieb Bob Weinand : > > > Am 25.04.2019 um 11:52 schrieb Nikita Popov > mailto:nikita@gmail.com>>: > > On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand > mailto:bobw...@hotmail.com>> wrote: > Hey, > > I feel like concatenation having the same precedence than

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

> Hey, > > I feel like concatenation having the same precedence than addition and > subtraction is promoting programmers to make mistakes. Albeit typically easy > to catch ones, it is a quality of life change at least. > > Hence I'm proposing a RFC changing the precedences: >

Re: [PHP-DEV] [RFC] Abolish Short Votes

Resend, because sent from the wrong address previously. +1, but it should probably be possible to extend the voting period once started, but not shorten it. This allows for extension during holidays in case the author didn't think about that when starting the vote. Regards, Niklas Joe Watkins

Re: [PHP-DEV] [RFC] Saner string to number comparisons

Am Mo., 4. März 2019 um 18:00 Uhr schrieb Nikita Popov : > > On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski wrote: > > > > > > > On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov wrote: > > > >> Hi internals, > >> > >> I think it is well known that == in PHP is a pretty big footgun. It > >> doesn't >

Re: [PHP-DEV] wiki.php.net

Hey all, the upgrade to the latest release is live now. Please report any issues directly to me. Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] wiki.php.net

I am. I already wanted to make the upgrade last weekend, but didn't find the time. Hopefully I'll find the time for that tomorrow. Regards, Niklas Am Do., 14. Feb. 2019 um 09:33 Uhr schrieb Sebastian Bergmann : > > Who is in charge of wiki.php.net and updates for its software? I ask > because

Re: [PHP-DEV] RFC Abolish Narrow Margins

> I'll reiterate my main two issues with this RFC: > - I do think that we need 50%+1 votes for certain decisions. Naming the > next version of PHP, or even deciding to release it outside of the yearly > cycle should not require a 2/3 vote. It's not so much erring on the side > of being

Re: [PHP-DEV] [RFC] JIT

> > Can you give some information on if there are pre-conditions that > > must hold for a function to be jitted, or quit conditions that force > > the JIT to be reverted for a function? > > -dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment > tag. It's possible to

Re: [PHP-DEV] RFCs "under discussion"

Am Di., 5. Feb. 2019 um 18:40 Uhr schrieb Stanislav Malyshev : > > Hi! > > Looking at our RFC page, we have over 50 RFCs under discussion. This is > obviously not true - and can not be true, really, it's impossible to > properly discuss 50+ RFCs at a time, and indeed most of these aren't > being

Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

Am Sa., 22. Dez. 2018 um 11:32 Uhr schrieb Nikita Popov : > > On Thu, Dec 20, 2018 at 4:13 PM Dmitry Stogov wrote: > > > Hi internals, > > > > > > The FFI RFC is turned into voting state. > > > > > > https://wiki.php.net/rfc/ffi > > > > > > There were very few minor changes since the initial

Re: [PHP-DEV] [RFC] [VOTE] Improve openssl_random_pseudo_bytes()

Hey Sammy, could you please turn your patch into a PR, so it's easier to comment? Thanks, Niklas Am Fr., 2. Nov. 2018 um 20:30 Uhr schrieb Sammy Kaye Powers : > > Hey internals! > > Given there has been at least two weeks of discussion around the RFC, > "Improve openssl_random_pseudo_bytes()"

Re: [PHP-DEV] Re: RFC Proposal

I'd be fine with throwing exceptions in PHP 7.4, but maybe a warning in PHP 7.4 and an exception in 8.0 then? Things like that can be a pretty stupid error that doesn't get noticed, and there are probably not many use cases checking the return to be false and then not throwing an exception.

Re: [PHP-DEV] Re: PHP 7.1.21

Please announce the re-tag in a separate thread. Everyone that pulled while the tag existed will have to delete it manually locally. Regards, Niklas Am Do., 2. Aug. 2018 um 07:24 Uhr schrieb Anatol Belski : > > Hi, > > > -Original Message- > > From: Peter Kokot > > Sent: Thursday, August

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

Am So., 22. Juli 2018 um 18:52 Uhr schrieb Christoph M. Becker : > > On 22.07.2018 at 18:40, Niklas Keller wrote: > > > Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães > > : > >> > >> On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller wrote: > &g

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães : > > On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller wrote: > > > It'd be great to use an OO approach instead of "magic" array keys, > > e.g. like this: > > > > https://github.com/amphp/http/bl

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

Am So., 22. Juli 2018 um 14:16 Uhr schrieb Andrey Andreev : > > Hi, > > On Sun, Jul 22, 2018 at 2:21 AM, Pedro Magalhães wrote: > > On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev wrote: > >> > >> Yes. > >> > >> All other "options" are actual *cookie attribute* names, as defined by > >> the

Re: [PHP-DEV] Improvements to openssl_crs_new. Need advice

Hey, I'd prefer a proper OO API in case we add new features in that area. Regards, Niklas Am Do., 19. Juli 2018 um 01:05 Uhr schrieb Jakub Zelenka : > > Hi, > > On Wed, 18 Jul 2018, 00:15 Dominic Luechinger, > wrote: > > > I'd like to improve the openssl_csr_new function to add any X509 > >

Re: [PHP-DEV] bugs.php.net downtime

Hey Rasmus I just found this bug: https://bugs.php.net/bug.php?id=76553 Has this bug been like that before the migration, too? Or did something go wrong? Regards, Niklas Am Do., 19. Juli 2018 um 10:35 Uhr schrieb marius adrian popa : > > Hello Rasmus, > > I can't access previous patches > >

Re: [PHP-DEV] Re: [RFC] Typed Properties

Zeev Suraski schrieb am Di., 17. Juli 2018, 00:10: > > Based on the feedback we received, we have decided to target PHP 7.4 for > this > > RFC. A main factor for this decision was that the RFC requires some > non-trivial > > changes to 3rd-party extensions for full compatibility. This would put

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

Hey, any reason for not having both, resulting in a total of 6 functions? Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [VOTE] Deprecate and remove case-insensitive constants

> Hi Nikita, > > I'm a terrible person for only bringing this up now (I apologise for not > following the list as closely as I used to), but one reason > case-insensitive constants are maybe useful is they leave open the > possibility of being able to access functions as values in future: like >

Re: [PHP-DEV] [VOTE] Deprecations for PHP 7.3

I put that item onto the list. The author of https://github.com/mikey179/bovigo-assert originally had the issue that a function named `assert` behaves really weird. `assert()` in namespaced code might refer to the namespaced `assert()` function, but might also fall back to the global `assert()`.

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

Hey, could you please fix the creation date in the RFC? It lists 2018-06-27, which would mean that the minimum discussion period wouldn't be over, yet, but it's actually been created somewhen last year. Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] PHP 2^3

Hey Dmitry, > > hi Aaron, > > > On Jun 25, 2018 10:49 PM, Aaron Piotrowski wrote: > > > 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

Re: [PHP-DEV] [VOTE] Fiber API

Hey Haitao, there doesn't seem to be any voting snipped on that page, so there's no actual vote yet. Also, the open issues section should usually be empty when the vote starts. The implementation in its current state is very limited and not really useful to real-world applications. Written code

Re: [PHP-DEV] Re: desiring a PHP.net wiki account

This issue has been resolved, thanks for your patience. :-) Regards, Niklas Am Do., 7. Juni 2018 um 15:23 Uhr schrieb Christoph M. Becker < cmbecke...@gmx.de>: > On 07.06.2018 at 14:28, Simon Hamp wrote: > > > My name is Simon Hamp (wiki username: simonhamp). I'd like to join the > RFC wiki to

Re: [PHP-DEV] Parse error: Invalid body indentation level

Am Di., 29. Mai 2018 um 07:34 Uhr schrieb Sebastian Bergmann < sebast...@php.net>: > Am 28.05.2018 um 22:16 schrieb Nikita Popov: > > Good point, I have added a note in UPGRADING in > > > https://github.com/php/php-src/commit/c70468b8d3c1d6711da0db84cba30d87d2482e5c > > Thank you so much, Nikita!

[PHP-DEV] [RFC] Deprecation of uniqid()

Hey, I hereby propose to deprecate uniqid(). There have been attempts to fix it ( https://wiki.php.net/rfc/uniqid), but those were rejected during discussion, because there's no possible fix without breaking BC. Instead of a subtle BC break, this RFC favors the deprecation and moving users to

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

Hey, > Problem with checking array on assignment is that it could be N dimensions > deep and one would have perform check for each item in each dimension for > mutable values which could have some performance implications. if you want to enforce that in userland now, you have even higher

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

Hey, > I do have rough idea how to go about arrays possibly without recursive > scan, I have to try couple of things, it could work if some checks are > moved to zval level. For now it is in the future scope unless I manage to > handle the within week or two. What's the issue with a one-time

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

Hey, > If you do allow arrays, they would have to follow the same rules as the > immutable object. > > Alternatively, perhaps an ImmutableArrayObject would be a good addition or > followup to the RFC. That would just move the problem and doesn't have any benefit over directly allowing arrays,

Re: [PHP-DEV] Re: [RFC] [Discussion] Arrays starting with a negative index

Hey, "Will no longer produce any output." in the BC example is wrong, it will produce a notice due to an undefined index then. > NOTE: If accepted, during the deprecation phase the following E_DEPRECATED > notice would be emitted in cases where the behavior will change: I guess that means also

Re: [PHP-DEV] About assert()

> In PHP 7 only foo() will be in the backtrace. In PHP 5 assert will be > listed as well. > > What you are proposing has already been done. It's also why > zend.assertions has three settings: 1: on, -1: off, 0: emulate PHP 5. > Unless you have code on your hands that is breaking when the -1

Re: [PHP-DEV] [RFC] Fiber support (again)

>> There would also need to be something that stops the script execution >> as soon as there's no non-suspended Fiber anymore. > > As you pointed out, the main process cannot be a Fiber because it need to > schedule other fibers. The conclusion is wrong. There just needs to be a way to access

Re: [PHP-DEV] [RFC] Fiber support (again)

> Hi, all, > > I have updated the RFC https://wiki.php.net/rfc/fiber > > changes list: > > - introduce the `throw(Exception $exceptin)` API > - record issues discussed What about my suggestion of making PHP's main() automatically a Fiber, which avoids Fiber::yield() being used outside of a Fiber,

Re: [PHP-DEV] [RFC] Fiber support (again)

2018-02-09 21:53 GMT+01:00 Björn Larsson : > Regarding these potential new keywords await & async. > Any need to look into how Hacklang uses these keywords? > Could there be portability aspects on the functionality in > itself? No, there's no need to look at Hacklang

Re: [PHP-DEV] [RFC] Fiber support (again)

> > > The language should offer a sane API, not the absolute minimum required > to > > work for these things. > > The Ruby's Fiber do offer a live? method but does not have a getStatus > method. > The Lua's coroutine only offer a status method. > > So do we really need to offer three additional

Re: [PHP-DEV] [RFC] Fiber support (again)

> > > - 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() > > Offering methods like

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

+1 Why should it emit an E_NOTICE instead of E_DEPRECATED? The code for the shim should probably use define() for constants instead of eval(). Regards, Niklas

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

Michael Morris <tendo...@gmail.com> schrieb am Fr., 26. Jan. 2018, 02:06: > On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller <m...@kelunik.com> wrote: > > > > >> > >> $a instanceof array > >> > > > > That might work, but array

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

> > On Thu, Jan 25, 2018 at 2:39 PM, Niklas Keller <m...@kelunik.com> wrote: > >> >> So, given `$a collectionof string` the operator returns whether or not $a >>> is, at that time, a collection of strings (be it an array or other >>> iterable). It doe

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

Michael Morris schrieb am Do., 25. Jan. 2018, 21:19: > On Thu, Jan 25, 2018 at 2:10 PM, Rowan Collins > wrote: > > > On 25/01/2018 14:52, Derick Rethans wrote: > > > >> IMO, it makes a lot more sense to check integrity when creating the > >> "array"

Re: [PHP-DEV] New login to RFC

Hey Gabriel, rights have been granted. Regards, Niklas 2018-01-20 18:35 GMT+01:00 Gabriel Caruso : > I've requested a login for _carusogabriel_ username to create a RFC for new > function in PHP's Core. > > > -- > Gabriel Caruso >

Re: [PHP-DEV] ICU and the INTL_IDNA_VARIANT_2003 deprecation

2018-01-19 20:09 GMT+01:00 Andrey Andreev : > On Fri, Jan 19, 2018 at 8:55 PM, Sara Golemon wrote: > > (Seriously though, who's on php 7.2, but hasn't updated ICU for that > > long?) > > Probably nobody yet. The issue was uncovered in code that assumed the >

Re: [PHP-DEV] php wiki user, want to contribute edits

> > > Thanks, fixed! > A few more little changes: > > %s/Global symbol tales/Global symbol tables/ > %s/operands jut refer/operands just refer/ > > Thanks for the docs. I'm off to read https://wiki.php.net/phpng-upgrading > as I got segfaults in my > php extension when upgrading from 5 to 7 due to

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

Hey Michael, I don't think the BC break is acceptable. You argue that scalar type declarations are relatively new, but in fact they're already years old now. They're used in most PHP 7+ packages. Even if changing types might be discouraged, it still happens a lot. Regards, Niklas

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

> > Am 24.12.2017 um 15:34 schrieb Fleshgrinder: > > I prepared a PR to add the `scalar` pseudo-type to PHP after the > > discussions around adding a `mixed` pseudo-type. I strongly believe that > > it makes sense to provide the most common primitive union types with > > handy aliases even if we

Re: [PHP-DEV] spam on user notes

> > hi internals, > > User contribution notes are flooded by spam. For example, > http://php.net/manual/en/install.problems.bugs.php#122116 > > The tool on master.php.net can only remove/reject the notes one by one, > which is inefficient in this case. > I'm wondering if there is a way can remove

Re: [PHP-DEV] [RFC] Mixed Typehint

> > > I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: > > https://wiki.php.net/rfc/mixed-typehint > > > > The purpose of this RFC is to introduce "mixed" typehint on language > level > > to be used > > as a valid typehint. PHP currently forces users to not use any type in > case >

Re: [PHP-DEV] ReflectionContext for imports and namespace

Andreas Hennings schrieb am Mo., 11. Dez. 2017, 01:39: > TLDR: > I propose to introduce a new class \ReflectionContext (or perhaps > \ReflectionScope?), to give information about imported aliases and the > namespace. > > > ## Background / motivation > > Some libraries that

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

> > This. There's nothing undefinable about "1 instanceof \stdClass", the > clear and obvious answer is: "No, it's not an instance of \stdClass, > it's an integer." The runtime result of false makes sense, the > compile time error doesn't. Let's relax the compile time error (fold > it into a

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

> > That is fine for code that is broken in the first place. Similarly we added > a warning some years back about array to string conversions. > Code using instanceof on possible non-objects isn't broken. instanceof simply does an implicit is_object() check without needing an extra function call.

Re: [PHP-DEV] C++-like function-try-block proposal

> > > No, sorry. Neither Hannes nor anybody from systems@ has responded yet. > As a workaround it should be sufficient to request a php.net account via > (use the same username and email address); > after somebody has approved the account, access to the Wiki should be

Re: [PHP-DEV] PHP 7.2.0 Released

> > and to be clear here: > > a client when connecting to a server configured like below has to respect > the cipher order of the server while > https://www.ssllabs.com/ssltest/ exists for years to give dministrators > of the server some help and which clients are using which cipher > Just minor

Re: [PHP-DEV] C++-like function-try-block proposal

> > > > I did (using this e-mail address), and got the message: "The user has > been created and the password was sent by email." However, I did not > receive any e-mail with the password. > > > > Sorry for the trouble, seems like nobody tested the sign up process > after the server migration yet.

Re: [PHP-DEV] PHP 7.2.0 Released

li...@rhsoft.net schrieb am Fr., 1. Dez. 2017, 17:13: > > > Am 30.11.2017 um 17:41 schrieb Hannes Magnusson: > >> - Improve TLS constants to sane values > > > > This worries me a lot. Last time someone thought it was a good idea they > > introduced security vulnerability for

[PHP-DEV] Re: Public Tags of Releases

> > On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller <m...@kelunik.com> wrote: > > it's the current practice to tag releases publicly two days before > release > > and then do the final QA phase. Could we please stop that? > > > > If there's a mistake tha

[PHP-DEV] Re: Public Tags of Releases

> > Afternoon, > > Tags are created in release branches, these branches should not be part of > any workflow other than our internal one. > I'm not talking about branches, but tags. Updating these release branches doesn't matter and is totally fine, as these are normal branches and thus not

[PHP-DEV] Public Tags of Releases

Morning, it's the current practice to tag releases publicly two days before release and then do the final QA phase. Could we please stop that? If there's a mistake that needs to be fixed and that's detected within these two days, a re-tag needs to happen. If the old tag is deleted and a new

Re: [PHP-DEV] [PHP-CVS] com php-src: ext/sodium: throw exceptions instead of errors: ext/sodium/libsodium.c

2017-11-28 15:27 GMT+01:00 Christian Schneider : > Am 28.11.2017 um 14:17 schrieb Sebastian Bergmann : > > Am 28.11.2017 um 13:56 schrieb Frank Denis: > >> Commit:c05cbd1e775fa69ed9939796a908390f2bfb4459 > >> Author:Frank Denis

Re: [PHP-DEV] C++-like function-try-block proposal

Hey Alexei, > I did (using this e-mail address), and got the message: "The user has been > created and the password was sent by email." However, I did not receive any > e-mail with the password. > Sorry for the trouble, seems like nobody tested the sign up process after the server migration

Re: [PHP-DEV] net_get_interfaces()

Hey Sara, I'm not sure about the naming, but I think such a function is a good idea. Why a `net_*` prefix when it's in ext/standard? I'd suggest `get_network_interfaces()` instead. As previously mentioned on Twitter [1], it could be really useful for us in amphp/socket [2]. [1]

Re: [PHP-DEV] C++-like function-try-block proposal

Hey, > I have been referred to this mailing list by > https://wiki.php.net/rfc/howto > as the first step to propose a language change. I first tried to register > on wiki.php.net as per php-src/README.SUBMITTING_PATCH in order to > actually > make an RFC, only to be given an error: > >

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

> > I just pushed support for security_level [1] which is more comprehensive > and the patch is also very simple. > > Apology for such last minute addition but I felt that it is really useful > for 7.2 and I have already messaged about that and haven't heard any > objections. Of course if anyone

  1   2   3   4   5   >