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 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 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
> - 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
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, 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
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
>
> 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
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
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 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 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
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
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
>
> 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 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 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: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),
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 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 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
>
> 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 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.
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:
>> >
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.
>
>
>
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, 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,
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 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 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
31 matches
Mail list logo
