Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

Hi, On Tue, Aug 6, 2019 at 8:20 PM G. P. B. wrote: > > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and

Re: [PHP-DEV] Re: [VOTE] Voting opens for str_starts_with and ends_with functions

Hi, On Mon, Jul 8, 2019 at 4:54 PM Claude Pache wrote: > > > > Le 8 juil. 2019 à 15:20, Christoph M. Becker a écrit : > > > > FTR, there is already substr_compare(). > > `substr_compare()` (as well as `strncmp()` which I am currently using in lieu > of `str_starts_with()`) forces you to

Re: [PHP-DEV] [RFC] Deprecations for 7.4

Hi, On Sat, Jun 22, 2019 at 3:59 PM Nikita Popov wrote: > > On Sat, Jun 22, 2019 at 2:24 PM Andrey Andreev wrote: >> >> Hi, >> >> With regards to the array_key_exists() deprecation, the RFC currently >> says nothing about things like ArrayAccess and object pr

Re: [PHP-DEV] [RFC] Deprecations for 7.4

Hi, With regards to the array_key_exists() deprecation, the RFC currently says nothing about things like ArrayAccess and object properties that contain arrays. I'm sure that these are exceptions that aren't meant to be deprecated, but can you please specify that explicitly? We all know how little

Re: [PHP-DEV] The real world ...

Hi, On Thu, Jun 13, 2019 at 3:21 PM Lester Caine wrote: > > On 13/06/2019 13:04, Andrey Andreev wrote: > > You have logs to see the errors; relying on your users to report the > > actual error messages to you is the worst way to do it. > > How many website logs can you

Re: [PHP-DEV] The real world ...

Hi, I too am in favor of a mechanism to strip out sensitive data from error messages. But Lester, man, you have it all backwards ... On Thu, Jun 13, 2019 at 11:37 AM Lester Caine wrote: > > On 13/06/2019 08:55, Andreas Heigl wrote: > >> display_errors=Off in production. > > Which give a white

Re: [PHP-DEV] Error in PHP documentation

Hi, On Thu, May 30, 2019 at 1:11 PM Alain D D Williams wrote: > > I have noticed an error, please can someone with update rights fix it. > > https://www.php.net/manual/en/regexp.reference.character-classes.php > > 7th paragraph contains: > > However, if the "]" is escaped with a backslash it is

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

Hello, I personally am not happy with the outcome of the vote. I think there's no practical benefit to be gained from the proposal and I don't even understand what has urged the author to make it; I voted No on both questions. However, what's done is done and these post-vote protests are getting

Re: [PHP-DEV] random_seed()

Hi, On Mon, Apr 1, 2019 at 11:08 AM Benjamin Morel wrote: > > Seeds could even be dangerous here, as these numbers are supposed to be > cryptographically secure. If you need a seedable PRNG for testing, just use > rand(). > Not only it could be dangerous, it would beat the entire purpose of

Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags

Hi, On Mon, Mar 25, 2019 at 8:02 PM G. P. B. wrote: > > On Mon, 25 Mar 2019 at 16:38, Andrey Andreev wrote: >> >> OK, so why not flip it and make it always available instead? I'm aware >> of the potential XML conflict, but I've personally never seen it, so >> to

Re: [PHP-DEV] bool values and increment operators?

Hi, On Mon, Mar 25, 2019 at 5:09 PM Chase Peeler wrote: > > 1.) Update the documentation to add booleans to the second list > 2.) Update the documentation to remove the second list - anything not in > the first list is not affected. > 3.) Update the language so that ++ and -- cast booleans to

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

Hi, On Mon, Mar 25, 2019 at 5:16 PM Johannes Schlüter wrote: > > On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote: > > > > As we stand now, code using short open tags works when those tags are > > enabled. As we'd stand in the future, that code would not work. > > That > > level of BC break

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi again, On Tue, Feb 5, 2019 at 10:37 AM Zeev Suraski wrote: > > Regardless of what you did, actually obtaining full voting rights > meant you had to ask for a VCS account, and have a reasonably good > explanation on why you need one - enough to convince one of the folks > with admin rights on

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi again, On Tue, Feb 5, 2019 at 5:32 AM Kris Craig wrote: > Stripping any existing contributors of our voting rights is a non-starter for > me, period. Any changes must not be applied retroactively, as that would > just lead to all kinds of problems and severe animosity/drama. > > The

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi, I was avoiding this, but since the discussion has already turned into all about who gets to vote, I might as well ... On Tue, Feb 5, 2019 at 1:46 AM Zeev Suraski wrote: > the barrier to obtaining a vote is ridiculously low. You keep saying that, but it hasn't been explained how it is so.

Re: [PHP-DEV] New website for the PHP project

Hi, On Mon, Feb 4, 2019 at 5:14 PM azjezz wrote: > > > ‐‐‐ Original Message ‐‐‐ > On Monday, February 4, 2019 2:32 PM, Andrey Andreev wrote: > > > Hi, > > > > I could nitpick on most of the proposed plan, but I really only wanted > > to reply t

Re: [PHP-DEV] New website for the PHP project

Hi, I could nitpick on most of the proposed plan, but I really only wanted to reply to this: > > * A new home page, not a "news" page, but a page simply showing the PHP > > Logo, a code example maybe and > > the download link [3]. > > > > [...] > > > > [3] > >

Re: [PHP-DEV] RFC Abolish Narrow Margins

Hi, On Thu, Jan 31, 2019 at 5:28 PM Zeev Suraski wrote: > > Secondly - the threshold and voting eligibility are not, in any way, > independent. They're two fundamental aspects of the same topic - how votes > take place. A 2/3 majority out of a subset of ~200-300 people is very > different from

Re: [PHP-DEV] Add FILTER_VALIDATE_INCLUDE validation filter for variable includes

Hi, On Mon, Sep 24, 2018 at 2:21 PM, Arnold Daniels wrote: > > > Please have a look at > * https://wiki.php.net/rfc/script_only_include - PHP RFC: Introduce script > only include/require > * https://wiki.php.net/rfc/allow_url_include - PHP RFC: Precise URL include > control > > Both describe the

Re: [PHP-DEV] Add FILTER_VALIDATE_INCLUDE validation filter for variable includes

Hi, On Sat, Sep 22, 2018 at 12:35 PM, Markus Fischer wrote: > > On 21.09.18 14:07, Andrey Andreev wrote: >> >> On Fri, Sep 21, 2018 at 3:03 PM, Rowan Collins >> wrote: >>> >>> Hi Arnold, >>> >>> Please remember to click "Rep

Re: [PHP-DEV] Add FILTER_VALIDATE_INCLUDE validation filter for variable includes

Hi, On Fri, Sep 21, 2018 at 3:03 PM, Rowan Collins wrote: > Hi Arnold, > > Please remember to click "Reply All" / "Reply List" rather than just > "Reply", to make sure the list is included in your replies. Right now, most > of us are only seeing half the conversation: >

Re: [PHP-DEV] Add FILTER_VALIDATE_INCLUDE validation filter for variable includes

Hi, On Thu, Sep 20, 2018 at 11:30 PM, Arnold Daniels wrote: > > > On Thu, Sep 20, 2018 at 8:50 PM Andrey Andreev wrote: >> >> Hi again, >> >> >> On Thu, Sep 20, 2018 at 5:29 PM, Arnold Daniels wrote: >> > >> > Variable inc

Re: [PHP-DEV] Add FILTER_VALIDATE_INCLUDE validation filter for variable includes

Hi again, On Thu, Sep 20, 2018 at 5:29 PM, Arnold Daniels wrote: > > Variable includes have proper purposes, like for a (PSR-4) autoloader. This > can't be simply replaced with an 'if' statement. Other reasons are module > inclusion and generated code. > Of course, there are a few valid

Re: [PHP-DEV] Add FILTER_VALIDATE_INCLUDE validation filter for variable includes

Hi, On Thu, Sep 20, 2018 at 1:37 PM, Arnold Daniels wrote: > There are many security issues that arise from not sanitizing a variable > before using it in an include (eg `include $script;`). > > The filter extension is intended to prevent this kind of security issues. A > validation filter would

Re: [PHP-DEV] Re: setcookie() doesn't follow the RFC in 7.3

Hi, On Thu, Sep 20, 2018 at 12:12 PM, Christoph M. Becker wrote: > On 20.09.2018 at 08:15, Nicolas Grekas wrote: > >> yesterday I submitted https://bugs.php.net/76906 to report that I wasn't >> able to set the "samesite" attribute on cookies while I followed what's >> been approved in

Re: [PHP-DEV] Wiki account gone missing?

Hi, On Tue, Sep 11, 2018 at 6:22 PM, Colin O'Dell wrote: > Hello Internals, > > I seem to be unable to access my wiki account (colinodell / > colinod...@php.net). My credentials are not being accepted and the > password reset functionality does not recognize my username. I am > therefore

Re: [PHP-DEV] Lift ICU requirements

Hi, On Tue, Sep 4, 2018 at 7:22 PM, Sara Golemon wrote: > On Tue, Sep 4, 2018 at 6:44 AM, Andrey Andreev wrote: >> On Mon, Sep 3, 2018 at 6:13 PM, Christoph M. Becker >> wrote: >>> On 03.09.2018 at 17:02, Andrey Andreev wrote: >>> >>>> I raise

Re: [PHP-DEV] Lift ICU requirements

Hi, On Mon, Sep 3, 2018 at 6:13 PM, Christoph M. Becker wrote: > On 03.09.2018 at 17:02, Andrey Andreev wrote: > >> I raised this issue back in January[1], but then got distracted and >> completely forgot about it ... sorry about that. > > Thanks for having raised

Re: [PHP-DEV] Lift ICU requirements

Hi, I raised this issue back in January[1], but then got distracted and completely forgot about it ... sorry about that. Would the change target 7.3 or 7.4? [1] https://externals.io/message/101626 Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

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

On Mon, Jul 30, 2018 at 5:46 AM, Yasuo Ohgaki wrote: > On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev wrote: >> >> Hi, >> >> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki wrote: >> > >> > One thing regarding implementation. >> >

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

Hi, On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki wrote: > > One thing regarding implementation. > Since the internet RFC has only 2 values for "samesite", the parameter can > be > bool rather than string so that users can avoid "broken security by a typo". > If "samesite" has more than 2

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

Hi, On Tue, Jul 24, 2018 at 7:37 PM, Pedro Magalhães wrote: > On Sun, Jul 22, 2018 at 6:54 PM Andrey Andreev wrote: >> >> Last, but certainly not least, we talk about $expires here only becase >> that's how it's (currently) named in either documentation and/or >> refl

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

Hi again, On Sun, Jul 22, 2018 at 6:47 PM, Pedro Magalhães wrote: > On Sun, Jul 22, 2018 at 1:16 PM Andrey Andreev wrote: >> >> But while I didn't quote that part of your >> message, you did also suggest to apply the same decision to other >> functions and so I a

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

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 various IETF RFCs, while "li

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

Hi, On Thu, Jul 19, 2018 at 12:00 AM, Pedro Magalhães wrote: > > With this being said, would anyone oppose an implementation where all the > options (including lifetime) are included in the array parameter? > Yes. All other "options" are actual *cookie attribute* names, as defined by the

Re: [PHP-DEV] Unifying logical operators

Hi, On Wed, Jul 11, 2018 at 5:20 AM, Ryan wrote: > On Tue, Jul 10, 2018 at 2:58 PM, Andrey Andreev wrote: > >> isset($foo) OR $foo = 'bar'; (and similar variations using empty() >> and/or &&) is another pattern I use often to set fallback values for >> empty or m

Re: [PHP-DEV] Unifying logical operators

Hi, On Tue, Jul 10, 2018 at 9:37 PM, Kalle Sommer Nielsen wrote: > Den tir. 10. jul. 2018 kl. 20.22 skrev Larry Garfield > : >> "do() or die()" code is/was very common in example code, tutorials, and other >> intro material because it means you don't need to think about error handling. > > I

Re: [PHP-DEV] On not rushing things at the last minute

Hi, On Tue, Jul 10, 2018 at 4:10 PM, Sara Golemon wrote: > I'm disappointed by the last minute kitchen-sink dump of RFCs being > raised, rushed through discussion, and voted on with minimal periods. > While I'm all for delivering useful features to end users, I don't > want us to get in the

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions YasuoOhgaki

Hi again, On Fri, Jun 29, 2018 at 6:07 PM, Christoph M. Becker wrote: > On 29.06.2018 at 16:54, Andrey Andreev wrote: > >> On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev >> wrote: >>> >>>> Readline is the only extension in your list that I would b

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions Yasuo Ohgaki

Hi, On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev wrote: > Hi! > > >> Readline is the only extension in your list that I would be sad about >> losing. I use it every day, I guess a lot of devs do. > > It's not "losing", per se, as the code doesn't get erased, it just moved > to PECL. All

Re: [PHP-DEV] Strict switch statements

Hi, On Thu, Jun 14, 2018 at 7:53 AM, Sara Golemon wrote: > Just for casual discussion at this point: > https://github.com/php/php-src/pull/3297 > > switch ($a) { > case FOO: > // Works exactly as current behavior. > break; > case == FOO: > // Nearly identical, though not

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Hi, On Mon, Feb 12, 2018 at 3:16 PM, CHU Zhaowei wrote: > Hello, > >>But that being said, I do support the proposal. I understand people >>opposed to removing features for no reason, but nobody needs this to >>be an operator, it's not a widely-used one, and we all know if it was

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Hi, I agree with the criticism towards the RFC contents raised so far. It's obviously put together with as little effort as possible, and the cheeky version number doesn't help either ... Treating the RFC process as a joke doesn't get you support. But that being said, I do support the proposal.

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

Hi, What's not obvious (to me at least) here is why is the current behavior preventing a ("sensible", as the RFC desribes it) implementation of function autoloading? That seems to be a major motivation factor for the proposal, yet doesn't seem to be explained anywhere. Cheers, Andrey. -- PHP

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

Hi, > Realistically, how often do you override strlen? If I say "never", I > probably would be close enough for all practical purposes. It's an ironic coincidence that you use strlen() as an example. Because it and substr() are possibly the most likely to be overriden, where we need code to be

Re: [PHP-DEV] Shorthand proposal for associative arrays

Hi, I've got mixed feelings about this ... On one hand, I've always avoided compact() because it is magic; a hack that was very obviously made because there was no language construct for it. This would've spared me lots of annoyance with code that was already otherwise boring. But on the other

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

Hi again, On Fri, Jan 19, 2018 at 9:30 PM, Niklas Keller wrote: > > I think we only have to bump the minimum version once 7.4 is out, because > only 7.4 will change the default. You only get a deprecation notice now, > which is totally fine. > I disagree that it's totally

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

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 constant was available on 5.4+, as noted in the manual, but it turned out

[PHP-DEV] ICU and the INTL_IDNA_VARIANT_2003 deprecation

Hello, It seems that an important detail was missed in the RFC to deprecate INTL_IDNA_VARIANT_2003 in PHP 7.2.0 (and later remove it). The only other option available - INTL_IDNA_VARIANT_UTS46 - may not be available at all, as PHP has ICU 4.0 as its minimum requirement, but support for UTS#46 was

Re: [PHP-DEV] [RFC] [DISCUSSION] Improve null-coalescing operator (??) adding empty check (??:)

Hi, On Wed, Jan 17, 2018 at 8:28 PM, Lito wrote: > No $foo ?: 'default' , it's only equivalent to (isset($foo) && $foo) ? $foo > : 'default' if $foo exists. > > Also PHP has added ?? as null-coalescing operator that works with undefined > variables/attributes/keys, my proposal

Re: [PHP-DEV] Mailing list moderation

Hi, On Wed, Jan 3, 2018 at 7:13 PM, Chase Peeler <chasepee...@gmail.com> wrote: > > > On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev <n...@devilix.net> wrote: >> >> Hi, >> >> On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler <chasepee...@gmail.com&

Re: [PHP-DEV] Mailing list moderation

Hi, On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler wrote: > > I agree with Paul. It would be different if email clients that allowed > filtering were expensive or hard to find. They aren’t, though. Pretty much > every email client not only allows filtering, but rather

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

Hi again, On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston <tonymars...@hotmail.com> wrote: > "Andrey Andreev" wrote in message > news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0...@mail.gmail.com... >> >> >> Hi, >> >> On Fri, Sep 15, 201

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

Hi, On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston wrote: > >> Far better that that >> problem is taken away from the file system (which should be clean, robust >> and >> fast) and if you want case independence put it up at the application >> layer. > > > You try telling

Re: [PHP-DEV] Re: hash_hkdf() signature and return value

Hi, On Fri, Sep 8, 2017 at 12:32 AM, Yasuo Ohgaki wrote: > > The reason why latter is a lot more secure is related to Andrey's > misunderstanding. > He said "when ikm is cryptographically strong, salt wouldn't add no more > entropy. > so salt does not matter". (not exact

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

Hi Frederik, On Mon, Aug 28, 2017 at 6:34 PM, Frederik Bosch | Genkgo wrote: > Hi Andrey, > > While I agree on your statement that back-porting is suboptimal, I do not > agree on the fact that I said that there was no time to wait. I submitted > the RFC, awaited the opinions,

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

Hi, On Mon, Aug 28, 2017 at 6:04 PM, Sara Golemon wrote: > On Sun, Aug 27, 2017 at 5:54 AM, Lars Strojny wrote: >> Sounds good! Let's vote in getting it in first and then we can have a 2nd >> RFC (and vote) if it should land in 7.2 >> > Mmmm, not quite. IF

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

Hi, On Wed, Aug 9, 2017 at 6:23 PM, Christoph M. Becker wrote: > On 08.08.2017 at 18:07, Nikita Popov wrote: > >> On Tue, Aug 8, 2017 at 5:43 PM, Christoph M. Becker >> wrote: >> >>> On 29.01.2017 at 16:52, Nikita Popov wrote: >>> On Sun, Jan 15, 2017

Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

Hi, On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon wrote: > > ftr; I'd vote in favor of several BC breaking things to do with > autoglobals, among them: > > * Make them objects (though ArrayAccess based for less hostile BC breakage) > * Make most of them read-only (offsetGet(),

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

Hi, On Fri, Jul 28, 2017 at 2:39 PM, Jakub Zelenka wrote: > On Fri, Jul 28, 2017 at 12:23 PM, Craig Duncan wrote: > >> Hi Nikita, >> >> Thanks for your input. Would you vote yes for throwing an exception? >> >> > Just to clarify exceptions are no go for 7.x.

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

Hi, On Fri, Jul 28, 2017 at 1:59 PM, Craig Duncan wrote: > Hi internals. > > As my initial thread about introducing warnings to the JSON functions was > not immediately flooded with disagreement I took the liberty of creating an > RFC for official discussion. > > The proposal

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

HI, On Tue, Jul 25, 2017 at 2:33 AM, Andreas Treichel wrote: > Hi Andrey, > >> 1. The wording here implies that these are the *only* attributes >> allowed. In the interest of forward-compatibility, I'd allow arbitrary >> attributes as well. > > > I just try to implement

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

Hello Andreas, On Sun, Jul 23, 2017 at 9:26 PM, Andreas Treichel wrote: > Hello Andrey, > >> That's what I was afraid of, and what I suggested be changed. >> >> If we had a similar, array-of-attributes API that did NOT ignore or >> trigger warnings for unknown attributes,

Re: [PHP-DEV] php.net website

Hi, On Fri, Jul 21, 2017 at 11:47 AM, Tony Marston wrote: > > Why on earth should you need to use HTTPS for a website that does not deal > with personal information? Nothing on that website can possibly be classed > as "sensitive" so what would be the point? > Because

Re: [PHP-DEV] [RFC] samesite cookie implementation

Hi, Not realizing I was looking at EOL dates, I (unintentionally) provided some wrong info yesterday: On Tue, Jul 18, 2017 at 5:13 PM, Andrey Andreev <n...@devilix.net> wrote: > > - HttpOnly was released with PHP 5.2.0 in January 2011 - just 3 months prior > to IETF RFC 6

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

Hi Andreas, On Tue, Jul 18, 2017 at 7:39 PM, Andreas Treichel wrote: > Hello Andrey, > >>> $options are equal to the optional parameters of setcookie and >>> setrawcookie. >>> $options may contain: >>> >>> expires: int >>> path: string >>> domain: string >>> secure: bool >>>

Re: [PHP-DEV] [RFC] samesite cookie implementation

Hi again, On Tue, Jul 18, 2017 at 4:23 PM, Frederik Bosch | Genkgo wrote: > Hi Andrey, > > Thanks for your feedback. If we are going to wait for http_cookie_set, > then my guess will be that it will take a while before we see samesite > cookie implemented. While I totally

Re: [PHP-DEV] [RFC] samesite cookie implementation

Hi Frederik, On Tue, Jul 18, 2017 at 12:11 AM, Frederik Bosch | Genkgo wrote: > LS, > > Today I finished writing the RFC for implementing same site cookies in PHP, > https://wiki.php.net/rfc/same-site-cookie. I am happy to receive your > remarks on the proposal, and improve

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

Hi Dan, On Tue, Jul 18, 2017 at 1:08 PM, Dan Ackroyd wrote: > On 18 July 2017 at 00:22, Andreas Treichel wrote: >> Hi, >> >> i want some feedback, about the following idea before i write a rfc. >> >> ... Most of them >> are optional and extensions (e.g.

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

Hi Andreas, On Tue, Jul 18, 2017 at 1:22 AM, Andreas Treichel wrote: > Hi, > > i want some feedback, about the following idea before i write a rfc. > > Problem: > The functions setcookie and setrawcookie has many parameters. Most of them > are optional and extensions (e.g.

Re: [PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs in opcode cache

Hi, On Mon, Jun 19, 2017 at 9:12 PM, François Laupretre wrote: > Hi, > > Opening vote for : https://wiki.php.net/rfc/url-opcode-cache > > Voting period will end Monday, July 3, 2017, 00:00 UTC. > You should start a new thread to announce the vote start, or people not

Re: [PHP-DEV] [RFC][Discussion] Consistent callables

Hi, On Mon, May 29, 2017 at 12:28 PM, Stephen Reay wrote: > > Regarding the big change you suggest, making protected/private methods return > false unless a new third parameter is true in is_callable(): > > I think you need to make your intention a *lot* clearer under

Re: [PHP-DEV] Parameter type widening RFC

Hi, On Thu, May 25, 2017 at 11:02 PM, Dan Ackroyd wrote: > > The RFC specifically didn't mention LSPbecause that is separate > from co/contravariance. It's unfortunate for other people to be > throwing the two around at you with a lack of precision. > Perhaps this

Re: [PHP-DEV] Parameter type widening RFC

Hi Marco, On Thu, May 25, 2017 at 6:58 PM, Marco Pivetta <ocram...@gmail.com> wrote: > On Thu, May 25, 2017 at 4:30 PM, Andrey Andreev <n...@devilix.net> wrote: >> >> I'm trying, but fail to find a source that says replacing stdClass >> with mixed/any/etc is

Re: [PHP-DEV] Parameter type widening RFC

Hi, On Tue, May 23, 2017 at 10:38 PM, Fleshgrinder wrote: > > I also had a look at the GitHub discussion, and I think that the things > that were written there have nothing to do with your concern. The people > commenting there simply did not understand LSP. > Well,

Re: [PHP-DEV] messages not delivering?

On Wed, May 17, 2017 at 5:28 PM, Ryan Pallas wrote: > > > On Wed, May 17, 2017 at 8:25 AM, Adam Baratz wrote: >> >> > > I'm think this problem might've cropped up again. I didn't receive >> > > this >> > > message: >> > >

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

Hi, On Wed, May 17, 2017 at 5:47 PM, Levi Morrison wrote: > > 1. Object variance should be implemented when we have generalized > variance for all types. By special casing it now we open ourselves to the > possibility that its implementation or semantics will differ from the >

Re: [PHP-DEV] messages not delivering?

Hi Adam, On Wed, May 17, 2017 at 4:42 PM, Adam Baratz wrote: > Hi, > > I'm think this problem might've cropped up again. I didn't receive this > message: > http://news.php.net/php.internals/99052 > > I only heard about it because it was mentioned in a PR thread. > I remember

Re: [PHP-DEV] Re: [Discussion] Dots and spaces in GPC variable names

Hi Andrea, On Tue, May 2, 2017 at 11:08 PM, Andrea Faulds <a...@ajf.me> wrote: > Hey Andrey, > > Andrey Andreev wrote: >> >> I'm not surprised by the suggestion for targeting 8.0, but perhaps we >> could think of a way to conditionally disable the mangling in 7

[PHP-DEV] Re: [Discussion] Dots and spaces in GPC variable names

Hi, On Tue, May 2, 2017 at 5:07 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote: > On 02.05.2017 at 12:56, Andrey Andreev wrote: > >> With parse_str() usage without a second parameter being deprecated, I >> was looking to possibly drop the behavior where it rep

[PHP-DEV] [Discussion] Dots and spaces in GPC variable names

Hi all, With parse_str() usage without a second parameter being deprecated, I was looking to possibly drop the behavior where it replaces spaces and dots with underscores in the result array, and ... As it often turns out - it's not that simple, because it re-uses the code that handles GPC vars.

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

Hi, On Tue, Apr 25, 2017 at 3:28 AM, Yasuo Ohgaki wrote: >> >> If you want examples, search GitHub for PHP code utilizing HKDF - you >> will see that most projects use it without a salt, including >> https://github.com/defuse/php-encryption - pretty much the best PHP >>

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

Hi, On Sat, Apr 22, 2017 at 10:37 PM, Yasuo Ohgaki wrote: > Hi Niklas, > > On Sun, Apr 23, 2017 at 4:32 AM, Niklas Keller wrote: >> >> >> What the... there were multiple concerns regarding the changes already. >> I'm hereby expressing another strong -1 on

Re: [PHP-DEV] Add __toArray() method to objects that would be called on cast to array

On Mar 16, 2017 2:01 AM, "Marco Pivetta" wrote: What changes is the interface of the `(array)` operator. I understand what you mean, I just disagree that it constitutes a BC break in the sense that no existing code would break/misbehave by simply updating to a PHP version

Re: [PHP-DEV] Add __toArray() method to objects that would be called on cast to array

Hi, On Thu, Mar 16, 2017 at 1:33 AM, Marco Pivetta wrote: > Correct: passing an object that implements `__toArray()` to an API that > uses an `(array)` cast internally will break or misbehave, if this feature > is added to the language. > I'm not particularly interested in

Re: [PHP-DEV] Add __toArray() method to objects that would be called on cast to array

Hi, On Wed, Mar 15, 2017 at 8:31 PM, Benoît Burnichon wrote: >> I like the idea kind of, but would this remove the ability to cast to >> array all classes not implementing __toArray, as is the case with >> __toString? This would be a HUGE BC if so: >> >> $ php -r 'class Foo

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

On Sat, Mar 11, 2017 at 3:57 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 3/11/2017 2:53 PM, Andrey Andreev wrote: >> I don't disagree with that in general, but strictly rejecting strings >> and other non-integer values would alleviate the problem for a >> ma

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

On Sat, Mar 11, 2017 at 3:34 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 11 March 2017 13:23:16 GMT+00:00, Andrey Andreev <n...@devilix.net> wrote: >>Ironically enough, the following code executes silently: >> >>$array = ['a', 'b', 'c'

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

On Sat, Mar 11, 2017 at 1:39 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 3/10/2017 11:57 AM, Andrey Andreev wrote: >> Yes, they're valid string values, but the examples I gave were meant >> to show that context can make them predictably invalid, and hence why >>

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

On Fri, Mar 10, 2017 at 4:20 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 10 March 2017 10:57:42 GMT+00:00, Andrey Andreev <n...@devilix.net> wrote: >>I'm not really interested in making "strict mode" less strict - it's >>already opt-in and no

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi Rowan, On Thu, Mar 9, 2017 at 10:09 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 08/03/2017 23:32, Andrey Andreev wrote: >> >> For example, a Cookie object may have the cookie attributes (domain, >> path, etc.) as value objects, but they can easily be

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi, On Thu, Mar 9, 2017 at 7:47 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 3/9/2017 12:47 PM, Andrey Andreev wrote: >> How can "any other scalar value" work? Using the cookie and headers examples: >> >> - booleans can be used as On/Off flags

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi, On Thu, Mar 9, 2017 at 1:49 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 3/9/2017 12:32 AM, Andrey Andreev wrote: >> On Thu, Mar 9, 2017 at 12:42 AM, Rowan Collins <rowan.coll...@gmail.com> >> wrote: >>> >>> I still don't understand wh

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

On Thu, Mar 9, 2017 at 12:42 AM, Rowan Collins wrote: > > I still don't understand what you're using this check for that means you > want to exclude integers. If you're passing on the value to anything that > actually needs a string, you're doing a string cast, either

Re: [PHP-DEV] [Discussion] is_string(), string type andobjectsimplementing __toString()

Hi Andrea, On Wed, Mar 8, 2017 at 8:44 PM, Andrea Faulds <a...@ajf.me> wrote: > Fleshgrinder wrote: >> >> On 3/8/2017 7:36 PM, Andrea Faulds wrote: >>> >>> Hi, >>> >>> Andrey Andreev wrote: >>>> >>>> The

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi again, On Wed, Mar 8, 2017 at 9:39 PM, Rowan Collins wrote: > > I think it comes down to what you're trying to achieve: the language can't > have pseudo-types for every possible combination of types, so if you want to > detect integers as one case, and other things

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi Ryan, On Wed, Mar 8, 2017 at 5:15 PM, Ryan Pallas <derokor...@gmail.com> wrote: > Sorry, accidently sent in the middle of typing that... > > On Wed, Mar 8, 2017 at 7:42 AM, Ryan Pallas <derokor...@gmail.com> wrote: >> >> >> >> On Wed, Mar 8, 2017

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi Rowan, On Wed, Mar 8, 2017 at 4:29 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Hi Andrey, > > I think this is an interesting area to explore, but do think the scope needs > to be widened slightly. > > > On 8 March 2017 12:25:54 GMT+00:00, Andrey Andreev &l

[PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi all, I submitted a GitHub PR* to allow objects implementing __toString() to *optionally* pass is_string() validation. More verbose wording of my motivation can be seen in the PR description, but here are the main points: - Simpler way to do checks like: is_string($var) || method_exists($var,

Re: [PHP-DEV] Nullable types and strict type-hinting with default null value

Hi, On Wed, Feb 22, 2017 at 11:18 PM, Michał wrote: > Hello PHP internals, > Scalar types declarations were introduced in PHP 7.0 but it was not > possible to pass null as a default value to function/method. It was finally > done by a small workaround described in documentation

  1   2   3   >