On 17 February 2020 00:45:26 GMT+00:00, Mike Schinkel
wrote:
>I think your latter points are orthogonal to this. And that you are
>taking my advocacy for adding filtering to apply too literally to only
>the specific implementations in filter_input().
Firstly, I deliberately didn't say "the
On Fri, Feb 14, 2020 at 11:14 AM G. P. B. wrote:
>
> Moreover, checking for a substring to start/end a string seems
> to be
> fitting for the current strpos functions.
Maybe in terms of semantics (`0 === strpos($haystack, $needle)`), but
suboptimal in terms of performance, especially when
> > I've created a straw poll at
> > https://wiki.php.net/rfc/calls_in_constant_expressions_poll ,
> > to measure interest in allowing calls in different types of constant
> > expressions.
>
> I've yet to make my mind up for most circumstances, although I'm leaning
towards a general "No".
>
>
On 17/02/2020 02:08, tyson andre wrote:
I've created a straw poll at
https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure
interest in allowing calls in different types of constant expressions.
I've yet to make my mind up for most circumstances, although I'm leaning
towards
I'd definitely agree on returning `int` instead of `integer`.
PHP allows both `class integer` and `class resource`, so `int` (plus
documenting exact return values for examples, as Nikita mentioned) would be
useful to prevent ambiguity.
Also, it'd be nice to have `null` return the lowercase
Hi internals,
I've created a straw poll at
https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure
interest in allowing calls in different types of constant expressions.
If there aren't any problems with the poll structure or rules preventing
creating a poll, I was going to
> On Feb 16, 2020, at 6:28 PM, G. P. B. wrote:
>
> Erf pls no, I'd rather have something like `get_canonical_type()`
That works fine too.
-Mike
P.S. But not sure what "Erf" means, though. '-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
> On Feb 16, 2020, at 6:34 PM, Rowan Tommins wrote:
>
> On 13/02/2020 20:31, Mike Schinkel wrote:
>> If I had a vote I would vote I would enthusiastically vote for the RFC if it
>> includes filter_input() functionality. But I would vote against this RFC if
>> it omits filter_input()
On 13/02/2020 20:31, Mike Schinkel wrote:
If I had a vote I would vote I would enthusiastically vote for the RFC if it
includes filter_input() functionality. But I would vote against this RFC if it
omits filter_input() functionality because it would mean another subsystem in
core that does
On Mon, 17 Feb 2020 at 00:25, Mike Schinkel wrote:
> > On Feb 16, 2020, at 8:15 AM, Mark Randall wrote:
> > The name is up for debate.
>
> Cool.
>
> Though still not exactly sure where you are headed with it since there are
> few detailed and no code examples the first name that comes to mind
> On Feb 16, 2020, at 8:15 AM, Mark Randall wrote:
>
> On 16/02/2020 10:16, Mike Schinkel wrote:
>> Why "debug" type?
>
> I would imagine because it is only really useful in the context of debugging.
JMTCW but I generally think names should describe what something is, not what
it can be
Hi,
Just to check, at the moment, if I was an evil hacker, and was to run:
curl -F 'file=@example.jpg;filename=../../../example.php'
https://example.com/upload/
The $_FILES['file']['name'] would be set to "example.php", where PHP has
removed the leading "../../../" (good to see).
Does that
On 16/02/2020 14:13, jan.h.boeh...@gmx.de wrote:
Except for simple numbers, almost no mathematical objects define division
(only some special matrices can be on the right hand of a division, and for
vectors there is no definition for division at all).
Then my philosophical question would be:
> ) I know you're not alone in that feeling. If it turns out this is the
majority view, I think it answers a couple of open questions:
>
> Overload methods should definitely be named after operations, not symbols,
to remind people they are implementing addition, not giving new meaning to +
>
>
On 16/02/2020 10:16, Mike Schinkel wrote:
Why "debug" type?
I would imagine because it is only really useful in the context of
debugging. There is no reason to ever expose such information to userland.
The name is up for debate.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP
On 16/02/2020 01:17, marand...@php.net wrote:
> N :( Notices are the enemy of all that is great and good.
>
> If operator overloading is going to become a first-class feature then it
> should be treated as such, and attempting overloading operators on
> objects that don't have the relevant
On Sat, 15 Feb 2020 at 23:06, wrote:
> Hi internals,
>
> based on the discussions here (https://externals.io/message/108300) and
> here
> (https://github.com/php/php-src/pull/5156), I have created a proper RFC
> for
> userspace operator overloading:
>
> On Feb 15, 2020, at 3:01 AM, Larry Garfield wrote:
>
> Data point:
>
> In PSR-7, the names used are:
>
> - queryParams: The query string values.
> - parsedBody: The body of the message, converted to a meaningful value. If
> the request type is a form, then it MUST be equivalent to $_POST.
On 16 February 2020 05:07:03 GMT+00:00, Stanislav Malyshev
wrote:
>Hi!
>
>> - The individual symbolic operators, with no intrinsic meaning - e.g.
>> overloading . for concatenation on strings but dot-product for
>> vectors; or a DSL overloading << and >> for "into" and "out of".
>
>Please no. I
> On Feb 15, 2020, at 9:32 AM, Mark Randall wrote:
>
> Greetings,
>
> I offer a short RFC to add a new function, get_debug_type, which would
> return the type name of a variable, automatically resolving the class
> name in the event of it being an object.
>
> Unlike gettype, this function will
20 matches
Mail list logo
