On Fri, 14 Feb 2020 at 11:09, Rowan Tommins wrote:
>
> That would also cover the fluent interface case:
>
> after delegate setFoo {
> $this->delegated = $return;
> return $this;
> }
>
I just realised that this could be easily extended to share an
implementation across multiple methods,
On Fri, Feb 14, 2020 at 7:44 AM Marco Pivetta wrote:
> On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon wrote:
>
>> Thanks for picking it up, and I agree with your response to Larry. As
>> nice
>> as it would be to lazy iterate, the scanner is just in NO shape to
>> tolerate
>> reentering
Hi internals,
https://wiki.php.net/rfc/calls_in_constant_expressions has hit some roadblocks
in the implementation shortly after the last email.
I've been blocked on how to resolve them in the implementation in a way I'm
certain would work.
I had assumed the calling scope wouldn't have the
On Fri, Feb 14, 2020 at 10:18 AM Philipp Tanlak
wrote:
> Hello PHP Devs,
>
> I would like to propose the new basic function: str_contains.
>
> The goal of this proposal is to standardize on a function, to check weather
> or not a string is contained in another string, which has a very common
>
>
> If somebody really wants a `mixed` property to be immutable, they could
> write `private immutable null|bool|int|float|string|array|object
> $property;`.
>
Yeah, one of my ideas was to first add support for mixed (for which there
have been a proposal/PR since quite some time), so that all
On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon wrote:
> Thanks for picking it up, and I agree with your response to Larry. As nice
> as it would be to lazy iterate, the scanner is just in NO shape to tolerate
> reentering userspace and potentially reinvoking the scanner before the
> first run
>
> Having said that, we are willing to revisit that naming decision if
> there's support for doing so. Perhaps:
> - rename $get to $query, populating it from `$globals['_GET']`, on the
> basis stated above
> - rename $post to $input, populating it from `$globals['_POST']`, on the
> basis that it
On Fri, Feb 14, 2020 at 2:23 PM Máté Kocsis wrote:
>
> So far, my biggest question (apart from the name) have been how non-typed
> properties should behave: as they are implicitly initialized to null if
> they don't have an explicit default value (while typed properties remain
> uninitialized),
Am Fr., 14. Feb. 2020 um 12:54 Uhr schrieb Nikita Popov <
nikita@gmail.com>:
> On Fri, Feb 14, 2020 at 10:18 AM Philipp Tanlak
> wrote:
>
>> Hello PHP Devs,
>>
>> I would like to propose the new basic function: str_contains.
>>
>> The goal of this proposal is to standardize on a function, to
Hi Côme & Niklas,
> On Feb 13, 2020, at 04:52, Côme Chilliet
> wrote:
>
> Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit :
>
>> Naming
>>
>> I think we shouldn't take over the naming of the super globals, e.g.
>> $_GET really contains the query parameters and has nothing to
On 2/14/2020 1:48 AM, Nikita Popov wrote:
On Thu, Feb 13, 2020 at 6:06 PM Larry Garfield
wrote:
On Thu, Feb 13, 2020, at 3:47 AM, Nikita Popov wrote:
Hi internals,
This has been discussed a while ago already, now as a proper proposal:
https://wiki.php.net/rfc/token_as_object
tl;dr is that
On Fri, Feb 14, 2020 at 2:44 PM Marco Pivetta wrote:
> On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon wrote:
>
>> Thanks for picking it up, and I agree with your response to Larry. As
>> nice
>> as it would be to lazy iterate, the scanner is just in NO shape to
>> tolerate
>> reentering
On Fri, Feb 14, 2020 at 5:47 PM Paul M. Jones wrote:
>
> - rename $get to $query, populating it from `$globals['_GET']`, on the basis
> stated above
> - rename $post to $input, populating it from `$globals['_POST']`, on the
> basis that it typically relates to the parsed form of php://input
> - Solving the above two issues while continuing to throw for func_get_args(),
> get_defined_vars(), etc.
> get_defined_vars() would throw for dynamic calls
Then again, it's already possible to get function parameters through
debug_backtrace(), so implicitly creating a closure and call with
On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon wrote:
> On Thu, Feb 13, 2020 at 3:48 AM Nikita Popov wrote:
>
>> This has been discussed a while ago already, now as a proper proposal:
>> https://wiki.php.net/rfc/token_as_object
>>
>> tl;dr is that it allows you to get token_get_all() output as an
I had considerable difficulty getting mysqli_connect to use SSL/TSL to
connect to a db and I think some things need to be improved. I apologize
for also describing documentation issues here, but I'll describe the coding
issues first. I may need some help to prompt the documentation team to
remedy
>
> What about $query and $body? That would be closer to the terminology
> used in HTTP RFCs.
The problem is that $body is typically used to get the raw message body as
a string or stream.
I was thinking more something along the lines of $bodyParams, which is more
verbose but leaves no
On Fri, 14 Feb 2020 at 16:33, Nikita Popov wrote:
> This constructor will initialize the corresponding properties. Now, the
> behavior that would make most sense to me (if extension of the class is
> allowed) is that MyPhpToken::getAll() is going to create the new tokens
> based on "new
Hi all,
> On Feb 14, 2020, at 10:47, Benjamin Morel wrote:
>
>>
>> What about $query and $body? That would be closer to the terminology
>> used in HTTP RFCs.
>
>
> The problem is that $body is typically used to get the raw message body as
> a string or stream.
>
> I was thinking more
On 14/02/2020 13:42, Máté Kocsis wrote:
Maybe only if our long-term goal would be to deprecate/remove
non-typed properties and implicit initialization altogether in favour of
mixed type and implicit uninitialization...
Can I just leave an "ugh, please no" on this part. I remain of the
Hi Internals,
I'd like to propose the idea of adding support for immutable/final/readonly
properties in PHP 8.
My plan is to add a new immutable/final/readonly (the name is up for
debate) property modifier to the language so that these kind of properties
could only be initialized but not
On Thu, Feb 13, 2020 at 3:48 AM Nikita Popov wrote:
> This has been discussed a while ago already, now as a proper proposal:
> https://wiki.php.net/rfc/token_as_object
>
> tl;dr is that it allows you to get token_get_all() output as an array of
> PhpToken objects. This reduces memory usage,
On 14 February 2020 00:39:15 GMT+00:00, Mike Schinkel
wrote:
>> On Feb 13, 2020, at 7:24 PM, Rowan Tommins
>wrote:
>>
>> An idea I had earlier which might solve some of them is if what was
>returned was not a normal Closure instance, but a new class like
>FunctionReference. It could then
On Thu, Feb 13, 2020 at 6:06 PM Larry Garfield
wrote:
> On Thu, Feb 13, 2020, at 3:47 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > This has been discussed a while ago already, now as a proper proposal:
> > https://wiki.php.net/rfc/token_as_object
> >
> > tl;dr is that it allows you to get
On Tue, 11 Feb 2020 at 10:14, Nikita Popov wrote:
> I'd like to get some feedback on the idea implemented in
> https://github.com/php/php-src/pull/5168. It provides an easy way to
> implement decorates, by taking care of forwarding any methods you do not
> want to override in a type-safe way.
> Le 14 févr. 2020 à 10:17, Philipp Tanlak a écrit :
>
> Hello PHP Devs,
>
> I would like to propose the new basic function: str_contains.
>
> The goal of this proposal is to standardize on a function, to check weather
> or not a string is contained in another string, which has a very common
On Fri, 14 Feb 2020 at 09:18, Philipp Tanlak
wrote:
> I would like to propose the new basic function: str_contains.
>
> The proposed signature for this function follows the conventions of other
> signatures of string functions and should look like this:
>
> str_contains(string $haystack,
I generally like the idea, but it seems many (most?) real-world
implementations actually use mb_strpos() !== false by default.
https://github.com/danielstjules/Stringy/blob/df24ab62d2d8213bbbe88cc36fc35a4503b4bd7e/src/Stringy.php#L206-L215
On Fri, Feb 14, 2020 at 9:48 AM Nikita Popov wrote:
> On Thu, Feb 13, 2020 at 6:06 PM Larry Garfield
> wrote:
>
>> On Thu, Feb 13, 2020, at 3:47 AM, Nikita Popov wrote:
>> > Hi internals,
>> >
>> > This has been discussed a while ago already, now as a proper proposal:
>> >
Hello PHP Devs,
I would like to propose the new basic function: str_contains.
The goal of this proposal is to standardize on a function, to check weather
or not a string is contained in another string, which has a very common
use-case in almost every PHP project.
PHP Frameworks like Laravel
On Fri, 14 Feb 2020 at 10:58, Aegir Leet wrote:
> I generally like the idea, but it seems many (most?) real-world
> implementations actually use mb_strpos() !== false by default.
>
>
>
31 matches
Mail list logo