Much of the reasons for PHP being stringly typed are historical. For example, extremely old database drivers used to stringify everything so you didn't get individually-typed columns. An HTTP request, specifically an encoded GET or POST, all values from the browser are strings. A file system is a stream of bytes, but many common web file formats stringify all values (JSON, XML, INI, etc).
> Strings are an implementation detail which should be abstracted over.
That's exactly what PHP does -- PHP doesn't care what representation a value has. But that is also then the source of it's strangeness.
> > Strings are an implementation detail which should be abstracted over.
> That's exactly what PHP does -- PHP doesn't care what representation a value has. But that is also then the source of it's strangeness.
I don't know if that's a valid use of the term "abstract", but it's certainly not what I meant. Rather than passing around low-level values for as long as possible, and only interpreting their contents when forced to (eg. when "+" forces them to be treated numerically); instead, I meant interpreting values as soon as possible so that they're treated as the appropriate type.
> An HTTP request, specifically an encoded GET or POST, all values from the browser are strings.
Again, they're only represented as strings. When I use an "order" parameter in my application, I want it to be an Order. I don't want it to be NULL. I don't want it to be a string which may-or-may-not be the numeric ID of an Order which may-or-may-not be stored in my database. If it's not an Order (eg. if the "readOrder" function I declared as the handler for this parameter returned [] instead of [$the_order]), the request is malformed so a HTTP 400 response should have been sent. My application should never even start if the data it needs isn't available.
Of course, that's exactly what "dependency injection" is in the OOP world; it's also a major use-case for the Reader monad in the Functional Programming world.
That is sort of the opposite of abstracting over the type but I get what you mean. I totally agree that interpreting values as soon as possible into the appropriate types is superior. I'm a big proponent of fail early. PHP, as with many scripting languages, are designed for short-term programmer convenience over long-term programmer convenience. Which given it's history and the original tasks it was designed for, that makes sense.
But PHP is moving in the direction of interpreting types quickly and failing early. Specifically, scalar type hinting seems like an almost certainty once there is an agreement on the semantics.
> Strings are an implementation detail which should be abstracted over.
That's exactly what PHP does -- PHP doesn't care what representation a value has. But that is also then the source of it's strangeness.