Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
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 filter API isn't well designed", I said "designing a good validation API is hard". In particular, finding the balance between flexibility and simplicity is key. Including a single blessed validation API in something as fundamental as a request object should take a lot of careful design, not be an afterthought to something like the current RFC. I also talked specifically about moving away from the old assumptions of CGI. What does it mean to "filter" a JSON body? We could check it's valid JSON, but parsing it will reveal that anyway. We could automatically parse it in the request object, and have "filters" apply to individual elements; but where would the user supply parser options, and how would you specify nested elements? Or we could keep it as a dumb string, and leave the validation to other systems, like a JSON Schema validator. Even with a plain HTML form, you might be using a form builder and want to associate your validation with the form definition rather than having it baked into the request object. >But given how much work it is get to an RFC over the line, it feels >like decoupling would end up with a lot more work, lengthen the >timeline to achieve base level functionality, and add uncertainty to >whether it will even happen whereas handling the 20% now that we need >80% of the time would mean the API would be mostly fully usable out of >the gate. Funny, I see the exact opposite: trying to build a single set of classes which include a system for getting global state AND a system for parsing it in different ways AND an in-built validation API seems like a mammoth task. And if you keep it monolithic, any feature you miss or make a mistake on is much harder to fix later. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for a new basic function: str_contains
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 $haystack is a
*very long* string which *doesn't* contain $needle, strpos() will
vainly search along the whole string, while a specialized function
would stop as soon as possible (which is also the case of existing
strncmp() but you need to write `0 === strncmp($haystack, $needle,
strlen($needle))`, arguably not really the cleanest code...).
For "contains" you have to search along the whole string anyway, so
`str_contains()` is "just" `false !== strpos()` but cleaner.
To be clear, I'm not against the current proposal (rather for
actually) [I just would want `str_{starts,ends}_with` even more
(without case-insensitive nor multibyte variants)]
--
Guilliam Xavier
On Fri, Feb 14, 2020 at 11:14 AM G. P. B. wrote:
>
> 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.
> >
> >
> > https://github.com/danielstjules/Stringy/blob/df24ab62d2d8213bbbe88cc36fc35a4503b4bd7e/src/Stringy.php#L206-L215
> >
> > https://github.com/illuminate/support/blob/6eff6cff19f7ad5540b9a61a9fb3612ca8218c19/Str.php#L157-L166
> >
> > So there should definitely be an mb_str_contains in ext/mbstring in
> > addition to the regular str_contains proposed here.
> >
>
> The biggest reason to have an mb_* variant if for when comparing with case
> insensitivity.
> The only other reason is if you need to check a string which is in a
> different encoding,
> which is, I'm assuming, is a quasi non-existent problem as everything
> things is UTF-8
> nowadays.
>
> The reason why I personally voted no on the previous RFC was that I don't
> see the
> value of having functions checking if a string starts/ends with a sequence
> but not a
> general one. Moreover, checking for a substring to start/end a string seems
> to be
> fitting for the current strpos functions.
>
> This function on it's own is way more reasonable and useful to add IMHO
>
> Best regards
>
> George P. Banyard
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Straw poll: Places to allow function calls in constant expressions
> > 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". > > What I can't express on this strawpoll though, is that I would > unequivocally vote against "any function or method call" in all > circumstances. Thanks for the feedback. When reading the poll results, I was planning to interpret both "whitelist of function calls" and "no" as a plan for a "no" vote on any RFC I would write that did allow "any function or method call", in the absence of any response otherwise. You definitely have a point that it doesn't include complicated reasons such as "yes on whitelist, less preferably yes on any function/method", or "yes on any function, definitely no on a whitelist". But I felt like adding too many voting polls or options would discourage responding to a request for quick feedback, and that any more detailed feedback such as this or implementation details could be included in this email thread. - Tyson. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Straw poll: Places to allow function calls in constant expressions
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 a general "No". What I can't express on this strawpoll though, is that I would unequivocally vote against "any function or method call" in all circumstances. -- Mark Randall marand...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] get_debug_type
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 string null instead of uppercase. get_canonical_type() is my weak preference. I'd also considered suggesting get_class_or_type(), but that seemed misleading since the value of get_class_or_type(2) would be different from gettype(2). This would save some time and make it easier to write better messages debugging, syslogging, throwing exceptions for unexpected values, etc. - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Straw poll: Places to allow function calls in constant expressions
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 add it to the rfc index page and move it to voting. This poll was created to gather opinions on which of the below statement types would be desirable to change, and in which ways, before rewriting https://wiki.php.net/rfc/calls_in_constant_expressions . It seems desirable to change some of these expression types (e.g. parameter defaults, static properties, static variable defaults) in different ways from others. (e.g. forbidding static property declaration expression results from containing objects seems like a completely unnecessary limitation from trying to reuse the implementation, in retrospect). This poll was created for feedback on whether changes to the following places had support, and what types of changes there were interest in. - Initial values of static or instance properties. This poll only addresses static properties. - Parameter defaults of functions, methods, and closures. - Class constant values. - Global constant values. - Static variable default values. I'd asked earlier about creating a poll in https://externals.io/message/108430 , but didn't receive a response. Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] get_debug_type
> 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: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
> 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() functionality because it would mean another
>> subsystem in core that does not actually address day-to-day concerns.
>
> I think you are over-estimating how central the filter API is to most
> people's workflow with requests. I think that's partly because designing a
> good validation API is hard, but also because filter_input in particular is a
> combination of three different concerns:
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().
I can see addressing your comments below *and* having a filtering method built
into these objects. Possibly even with applicable method names as opposed to a
2nd type parameter, like:
$request->getInt('db_id');
$request->getJson('package');
$request->getUrl('return_url');
> 1) Fetching the raw information about the incoming HTTP request from the web
> server (the "SAPI")
> 2) Parsing that raw information into individual fields
> 3) Validating those fields against expected type constraints
>
> The superglobals already combine concerns 1 and 2, and the filter API adds
> concern 3; but to do so they all assume that the user is basically writing a
> CGI wrapper for some HTML forms.
>
> The modern reality is rather different, and step 2 in particular is much more
> variable:
>
> - Rather than query string parameters, it might involve extracting parameters
> from an SEO URL like "/products/123-acme-thingummy" or a RESTish URL like
> "/products/123/description/en-GB"
> - Rather than submitted form data, it might involve parsing JSON from an AJAX
> request or API call
>
>
> I would love to see new APIs that take a step back from the legacy, and
> tackle each of these concerns separately, based on modern requirements.
>
> For concern 1, getting data out of the web server, I'd love to see:
>
> - A more intuitive way to get the raw request body than
> file_get_contents('php://input')
> - A more reliable way to get the URL the user requested than checking 5
> different variables in $_SERVER to handle different deployment methods (see
> e.g. [1] and [2] for the lengths libraries go to for this)
> - A proper distinction between HTTP headers, server status variables, and
> environment variables, because CGI name-mangling is legacy cruft that users
> shouldn't need to learn
>
> For concern 2, parsing that data, I'd love to see:
>
> - A better API than parse_str for parsing arbitrary strings in
> application/x-www-form-urlencoded format
> - A way to parse data in multipart/form-data format decoupled from the
> current HTTP request
> - Tools for working with Content-Type strings, such as a function for
> correctly parsing things like "text/html;charset=UTF-8", and constants for
> common MIME types
>
> Concern 3, filtering / sanitising / validating, I think is a really hard
> problem space, and I don't think there will ever be one implementation that
> suits all cases.
>
> A similar "shopping list" could probably be made for responses, but if we
> decoupled the pieces, we wouldn't have to perfect them all at once; instead,
> we could provide building blocks that make userland implementations easier.
Decoupling is a valid approach.
But given how much work it is get to an RFC over the line, it feels like
decoupling would end up with a lot more work, lengthen the timeline to achieve
base level functionality, and add uncertainty to whether it will even happen
whereas handling the 20% now that we need 80% of the time would mean the API
would be mostly fully usable out of the gate.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
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 not actually address day-to-day concerns.
I think you are over-estimating how central the filter API is to most
people's workflow with requests. I think that's partly because designing
a good validation API is hard, but also because filter_input in
particular is a combination of three different concerns:
1) Fetching the raw information about the incoming HTTP request from the
web server (the "SAPI")
2) Parsing that raw information into individual fields
3) Validating those fields against expected type constraints
The superglobals already combine concerns 1 and 2, and the filter API
adds concern 3; but to do so they all assume that the user is basically
writing a CGI wrapper for some HTML forms.
The modern reality is rather different, and step 2 in particular is much
more variable:
- Rather than query string parameters, it might involve extracting
parameters from an SEO URL like "/products/123-acme-thingummy" or a
RESTish URL like "/products/123/description/en-GB"
- Rather than submitted form data, it might involve parsing JSON from an
AJAX request or API call
I would love to see new APIs that take a step back from the legacy, and
tackle each of these concerns separately, based on modern requirements.
For concern 1, getting data out of the web server, I'd love to see:
- A more intuitive way to get the raw request body than
file_get_contents('php://input')
- A more reliable way to get the URL the user requested than checking 5
different variables in $_SERVER to handle different deployment methods
(see e.g. [1] and [2] for the lengths libraries go to for this)
- A proper distinction between HTTP headers, server status variables,
and environment variables, because CGI name-mangling is legacy cruft
that users shouldn't need to learn
For concern 2, parsing that data, I'd love to see:
- A better API than parse_str for parsing arbitrary strings in
application/x-www-form-urlencoded format
- A way to parse data in multipart/form-data format decoupled from the
current HTTP request
- Tools for working with Content-Type strings, such as a function for
correctly parsing things like "text/html;charset=UTF-8", and constants
for common MIME types
Concern 3, filtering / sanitising / validating, I think is a really hard
problem space, and I don't think there will ever be one implementation
that suits all cases.
A similar "shopping list" could probably be made for responses, but if
we decoupled the pieces, we wouldn't have to perfect them all at once;
instead, we could provide building blocks that make userland
implementations easier.
[1]
https://github.com/symfony/symfony/blob/9acb06041cc88b5c14d40f8cd9a74dd14d7ac786/src/Symfony/Component/HttpFoundation/Request.php#L1741
[2]
https://github.com/laminas/laminas-diactoros/blob/b36d6bf376b03dfc3190b1065630090e57f2e20d/src/functions/marshal_uri_from_sapi.php
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] get_debug_type
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 for me > would be get_real_type(). > > -Mike > Erf pls no, I'd rather have something like `get_canonical_type()` George P. Banyard
Re: [PHP-DEV] [RFC] get_debug_type
> 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 used for. The former can typically be definitive, the latter is based on perspective and thus both multiple names could apply and for some people the "can be used for" name turns out to be confusing. For example, when I first saw the name I was wondering if it would return some kind of debugging "mode" and was curious if there were more than one mode for debugging. I was hopeful that there was something new about debugging for me to learn. > There is no reason to ever expose such information to userland. Hmm. Depending on what you envision, I could definitely see using it in userland. Basically something that merges gettype() and get_class() so that I can get one definitive type for a value and not have to call two functions. I can of course write my own, but my own would not be "standard" and so I would see value in having a standard function for this in core. > 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 for me would be get_real_type(). -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $_FILES['name'] check
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 happen simply because of this IE fix, where it uses _basename() in the PHP source: https://github.com/php/php-src/blob/0b4778c377a5753a0deb9cfc697d4f62acf93a29/main/rfc1867.c#L1144 Craig
Re: [PHP-DEV] [RFC] Userspace operator overloading
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: are those really the same
operation as we have for integers and floats, or are they
domain-specific meanings of the symbols?
Vectors and matrices, for instance, have multiple types of "product";
does exactly one of them directly correspond to multiplication, or would
* simply be overloaded with whichever named operation was most commonly
used?
Also think of time
differences: $datetime1 - $datetime2 results in a DateInterval, but
$datetime1 + $datetime2 is not a meaningful operation (Datetime already has
a diff() method that do this).
I'm not necessarily saying that the operations need to be symmetrical in
allowed types and behaviour, but there is at least a meaning to both
addition and subtraction in this case. And notably, DateTime +
DateInterval and DateTime - DateInterval *are* a symmetrical pair.
Also it is not really possible to split multiplicative and additive methods
into different behavior, as when $a implements Additive Behavior it should
be possible to do an -$a, but because of the the way PHP compiles the code
this becomes -1*$a.
That's a design decision; you could also treat it as equivalent to 0 -
$a and call the subtraction overload.
In my opinion this would lead to that even if an object implements these
interfaces, in many cases you cannot be sure that it really supports all
operations, which would contradict the whole idea of defining interfaces.
The value I see is not so much about checking the interface and assuming
particular behaviour, but encouraging developers to use the feature in a
certain way, if there is consensus that the feature is not intended for
Domain-Specific Languages.
Under the current RFC, I could write this:
/**
* Class to represent a Unix command
*/
class Command {
// ...
/**
* Implement $command1 | $command2
*/
public static function __or(Command $first, Command $second): Command {
return $first->pipeOutputTo($second);
}
}
If the operations were grouped into interfaces, I would be forced to
write this, making it much clearer that I am abusing the feature:
/**
* Class to represent a Unix command
*/
class Command implements BitwiseOperators {
// ...
/**
* Implement $command1 | $command2
*/
public static function bitwiseOr(Command $first, Command $second):
Command {
return $first->pipeOutputTo($second);
}
public static function bitwiseAnd(Command $first, Command $second) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
public static function bitwiseXor(Command $first, Command $second) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
public static function bitwiseNot(Command $operand) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
public static function bitwiseShiftLeft(Command $operand, int $i) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
public static function bitwiseShiftRight(Command $operand, int $i) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
}
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Userspace operator overloading
> ) 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 + > > They should probably be grouped into interfaces, which this RFC has so far resisted. How often does it make sense for a type to support addition but not subtraction, or multiplication but not division? Even more clearly, if a type claims to implement bitwise OR but not bitwise AND, NOT, and XOR, something is > definitely fishy. > > You can't stop people using overloading DSL-style, but you can make it obvious that it's not the intention of the feature (if we agree that it's not the intention; maybe some people here are really hoping to use it that way?) On 16/02/2020 10:31, rowan.coll...@gmail.com 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). Also think of time differences: $datetime1 - $datetime2 results in a DateInterval, but $datetime1 + $datetime2 is not a meaningful operation (Datetime already has a diff() method that do this). Also it is not really possible to split multiplicative and additive methods into different behavior, as when $a implements Additive Behavior it should be possible to do an -$a, but because of the the way PHP compiles the code this becomes -1*$a. This is sufficient for almost all cases, but it would require that the code also provides an possibility to handle multiplication. In my opinion this would lead to that even if an object implements these interfaces, in many cases you cannot be sure that it really supports all operations, which would contradict the whole idea of defining interfaces. I wonder if it would be reasonable to allow voting between an interface approach and the "separate magic function for each operator" approach... Greetings, Jan Böhmer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] get_debug_type
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 Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Userspace operator overloading
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 method available should trigger an > Error. I agree with that throwing an error would be the better approach. But that would be a breaking change, as it would break existing code. Something like this is valid code in the moment: $a = new ClassA(); $b = $a + 1; Currently a only a notice (Object of class ClassA could not be converted to int) is triggered, and the object is handled like a numeric 1. ($b have the value 2). I have no clue, how big the impact of changing this to an error would be, so my current implementation just triggers an NOTICE. In this RFC https://wiki.php.net/rfc/engine_warnings, it was decided to remain the NOTICE behavior for casting an object to an int. If it is decided to reclassify the usage of operators on objects (without overloaded behavior) to thrown an Error, this would be totally fine for me, but we should discuss this. Greetings, Jan Böhmer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Userspace operator overloading
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: > https://wiki.php.net/rfc/userspace_operator_overloading > > The main differences to my original concept, is the removed __compare() > method (comparison overloading is a complex topic and should be handled in > a > different RFC) and the possibility to signal that the operator handler does > not support the given types (by typehints or returning a special value). > This way, only one of both objects has to know about the other type. This > should expand the use case of operator overloading compared to my old > concept. > > What do you think about the RFC? > > Some discussion points, I can think of, would be the naming of the methods > (maybe naming them after the operator symbol and not the arithmetical > operation they represent, e.g. __plus instead of __add) or putting the > methods inside of interfaces like done for ArrayAccess (But I don’t see any > advantage in doing so, as it is very difficult grouping different operators > in a single interface usefully. Also, operators can accept and return > different types, so there is no real common interface between classes you > could rely on). > Furthermore, maybe the idea of allowing operator overloading in general > should be discussed as it is sometimes considered an anti-pattern (e.g. the > usage of '<<' for outputting a string in C++). On the other hand there are > many languages and libraries where operator overloading is used > successfully > (e.g. numpy in Python). > > Regards, > Jan Böhmer > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Just as a FYI, I'll vote No to this RFC regardless of arguments as I find operator (and method) overloading a bad idea in general. Moreover, the only ones I am a tiny bit less reluctant to overload are the mathematical operators. However, one of the major reasons to want to have this seems to add better support for Matrices and Complex number which can already be done at the extension/engine level. Best regards George P. Banyard
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
> 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. If not, > it's up to the particular implementation to determine what "parsed" means. > (Eg, parsing a JSON body of a POST into some domain object, or whatever.) > - The raw body is a stream called "body", or rather an OOP wrapper around a > stream since PHP's native stream interface is fugly. > - There's specific handling for uploadedFiles, too. > > cf: https://www.php-fig.org/psr/psr-7/ > > To the earlier point about existing implementations, while there are a myriad > of older, custom implementations of abstractions around superglobals, there's > only two that are not decade-old proprietary implementations: HttpFoundation > and PSR-7. Those are, realistically, the only implementations that matter. > Anything else would be on the same order of magnitude effort to port to one > of those as to port to this proposal. In a meaningful sense, those are the > only "existing competition". Both also have robust ecosystems that make > leveraging them in an entirely custom app pretty straightforward. > > (Whatever your feelings of the technical merits of either design, that's the > current state-of-the-market.) > > Which therefore begs the question, is this proposal intended to supplant > HttpFoundation and PSR-7, or to become a common underpinning that both of > them wrap, or to be a third cohabitating implementation in the ecosystem? > > It doesn't seem robust enough to supplant both of them entirely, there's > little value to either HttpFoundation or PSR-7 to rewrite their guts to wrap > this object (though it's easier for PSR-7, as an interface, for someone to > write a new implementation of it than for HttpFoundation), which would mean > we'd end up with a 3rd in-the-wild implementation for user space to keep > track of. > > I am unclear how that is a market win. The win is it allows developer to provide a simple to use object oriented interface *in core*. IOW, without having to bring in an external PHP-code implementation that may or may not break in the future. Another big win would be to allow developers to deprecate use of superglobals in their own apps. However Paul do not want to add an ini setting to disable the use of superglobals. But how could disabling superglobals be done in HttpFoundation or PSR-7? Maybe Paul will reconsider adding such an capability to his RFC because it is something we cannot get with HttpFoundation and PSR-7. Or maybe we should be looking at is a core implementation of PSR-7 instead; one that would allow us to disable access to the superglobals? One that people could subclass, of course. If we did that, we might hash out why some developers do not use PSR-7 and possibly fix its (perceived?) faults in a new PSR to amend PSR-7. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Userspace operator overloading
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 know it looks fancy and some languages love it, but for a >person not in on the joke reading such code is a nightmare :) 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 + They should probably be grouped into interfaces, which this RFC has so far resisted. How often does it make sense for a type to support addition but not subtraction, or multiplication but not division? Even more clearly, if a type claims to implement bitwise OR but not bitwise AND, NOT, and XOR, something is definitely fishy. You can't stop people using overloading DSL-style, but you can make it obvious that it's not the intention of the feature (if we agree that it's not the intention; maybe some people here are really hoping to use it that way?) Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] get_debug_type
> 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 return the true name of scalar > types, rather than their aliases, thus get_debug_type will return > "int" rather than "integer" etc. > > https://wiki.php.net/rfc/get_debug_type > Why "debug" type? -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
