On 17/02/2020 15:55, Paul M. Jones wrote:
I apologize in advance for the length of this email. I hate reading
walls-of-text, but the answers are necessarily long. I have tried to break it
up into bullets where possible for easier reading.
No, thank you for taking the time to respond. I've cherry-picked
rearranged the quotes in this reply a bit so I can try not to repeat
myself too much; let me know if I've taken your words too far out of
context.
...it is likewise valid to say that AdoDB "took functionality that was scattered
across a dozen different vendor-specific extensions with different naming and calling
conventions, and centralised it into one more-or-less consistent interface." So did
PEAR DB, Metabase, MDB, and so on. PDO did it as an extension, instead of in userland,
but the goals and outcomes noted were identical.
That's a fair point, everything PDO does could be and has been done in
userland. There is one thing that couldn't be done outside of an
extension, though, which is that PDO doesn't rely on the legacy
extensions, it (in theory at least) replaces them.
What I think is slightly more relevant, is that PDO makes writing
wrappers like ADODB easier, because it contains non-trivial
functionality that those wrappers would otherwise have to write.
I don't *expect* anything from existing published library authors
...
I always thought of the "intended audience" as the much the same as
for any RFC
I think perhaps my choice of words has caused a bit of confusion.
Perhaps "hope" would have been better than "expect", and "use cases"
better than "intended audience".
I was trying to draw out two pieces of information:
- What's the sales pitch - what do YOU think is great about these classes?
- When working out the details, what code should we be picturing using
the new classes?
I wasn't around when PDO was proposed, but an imaginary "sales pitch"
might have gone something like this:
- Developers should be able to implement multiple database systems
without learning the quirks of each vendor's extension
- Library authors shouldn't need to implement the basic functionality of
every driver from scratch when the vendor could do it for them
- Vendors shouldn't need to decide which API to follow, when we can
normalise everything internally
- We can offer different result formats and error-handling models out of
the box
...and so on
- some [library authors] may find their own work so close to this extension
that they migrate over to it entirely.
So, there is at least some hope that this will entirely replace some
people's existing libraries, even if it doesn't replace the more
powerful ones like HttpFoundation. That's probably reasonable.
(Note that I've been thinking of "library" fairly loosely - a single
class used in a completely private monolithic repo, but which is written
to be generic functionality, has much the same role as a public composer
package in this case.)
For myself, and as noted by Jan Schneider and others, those benefits center
around...
This is what I was looking for. Sell it to me! :)
...a built-in OO-ish request/response object set...
"OO-ish" is a wise choice of words here. One of the reasons I'm not
terribly keen on this proposal - particularly the request half - is that
I'm a bit of an OO purist. By that I mean that I prefer objects that
have a strong responsibility, and encapsulate useful behaviour, rather
than just spitting out what went in. The response part of the proposal
is closer to "real" OO, IMO, because it includes behaviour like
manipulating individual headers and cookies.
The lack of behaviour also makes it less useful to people writing their
own request and response objects: if I have a copy of $_POST and want to
put it in my own object property, why would I first pass it to a
ServerRequest object, and then get it straight back out again, if the
object isn't helping me do anything with that data?
That said, I know some people are happy with OO-ish code, some even to
the extent of preferring stdClass to an array. So it's not unreasonable
to say that this will appeal to developers who are less puritanical
about objects than me.
...that does pretty much just what PHP itself already does...
As you say elsewhere, this is useful for helping people migrate to it.
The flipside of that is that it ties us into past decisions, rather than
evaluating whether those decisions are still what we want.
The approach in providing both $files and $uploads arrays is a good
compromise - provide the new better way, but also an easy-to-migrate
way. I'd love to see them named more distinctly, though, maybe even
calling one of them "legacy". I'd probably also make them methods so
that the data can be stored once (in the new format) and re-formatted on
demand (again, objects as behaviour rather than data).
...easing their transition away from global state
This I find less convincing. To quote from further down the e-mail, I wrote:
...you can do almost as much in that direction as the RFC by writing "$get=$_GET;
unset($_GET);" The hard problem is that the entry point for a request is in global
scope, not a main() or handleRequest() function.
and you replied:
Another "hard" problem is carrying those values around in the system once they
are decoupled from global state; the objects in this RFC purport to do so.
If all the object does is "carry around" a copy of the superglobal
arrays, I can write it in about a dozen lines of code. Admittedly, the
implementation wouldn't match anyone else's, but if I wanted
interoperability, I would need to follow a standard like PSR-7, or match
a popular existing library; this does neither.
Again, the response object is more powerful in this regard, because we
can't currently pass around a list of prepared cookies and trivially
output it to the client.
Along the lines of my previous message about decoupling concerns, I
would personally like the response parts of the proposal split out and
re-cast as a kind of "response buffer". That could be useful directly,
and it could provide useful functionality to people implementing a full
PSR-7 or similar Response object.
I had considered mentioning the dual OO+procedural APIs of mysqli, date, etc.
but it seemed too much in an already-long RFC; I'm glad you brought it up, as I
did have it in mind.
This is an interesting comparison to consider. Just as those extensions
have procedural options for people who can't stand objects, the current
proposal has objects for people who like "OO-ish".
Introducing these objects as part of a new calling convention for PHP scripts
would definitely add value, and make them a true replacement for the
superglobals, but that would be a very different RFC.
That does seem rather ambitious. If you feel that's a valuable thing to add to
PHP, perhaps it could be part of a future RFC, maybe even one that uses the
objects in this RFC as a starting point.
One of the things I don't like about the current proposal is that it's
modelled so closely around the current superglobals that I fear it would
actually be *harder* to replace them.
I find this constraint particularly awkward:
N.b.: It is up to you to make sure the various content-related header
values in |$GLOBALS| match the custom |$content| string.
Parsing a request body from an arbitrary source into arrays that match
the structure of $_POST and $_FILES would be a really useful feature. It
would be something userland libraries could make use of right now, and
would fit in nicely with a future where those arrays aren't populated by
default.
I also really want to see the day when I never have to interact with
$_SERVER again. Other than renaming it, this object's design makes that
less likely, not more.
Imagine if in future we're able to redesign the internals so that there
is a dedicated and reliable field for the requested URL; the current
object doesn't have anywhere we can put that. If we add it later, it
will be too late, code will be written that passes around ServerRequest
objects, but relies on the full array of CGI variables to reconstruct
the URL.
If this object took a more opinionated view of what behaviour to
encapsulate, we could simply hide the "server" array completely. Common
use cases would be exposed via methods, and rarer use cases would have
to be added in userland with their own copy of $_SERVER. Then my dream
of deprecating $_SERVER could mean something other than moving it into
an object.
I hope I haven't left any unfinished sentences as I went back and forth
through this! And thanks again for taking the time to engage with me.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
