On 04/11/2017 03:19 PM, Larry Garfield wrote:
Hello, peoples. In response to some recent off-list discussion (at
conferences and elsewhere), I offer this brief survey about how we
should namespace interface PSRs once we start producing "updated"
versions (eg, PHP 7-ified versions) of existing specs. The survey
itself has more details, and should take under a minute to complete.
Please do so!
https://docs.google.com/forms/d/e/1FAIpQLSc8VJySoz_3koQThe057zYhzSkmOvOAgO0pEmenwr1Biu6JEA/viewform
This is a non-binding information gathering tool only to kick off a
discussion, not to end one. Feel free to discuss more in this
thread. I'll leave the survey open for 2 weeks or until people stop
responding to it. :-)
All are welcome and encouraged to respond, even if you're not a Core
Committee member or Project Rep.
--Larry Garfield
A bit late (I've been a bit distracted, plus DrupalCon), but I've closed
the poll. The results are available here:
https://docs.google.com/forms/d/1XAi_RZW_Ang_N-QZEc0SU2DwmV-6n31elex2753d9QU/edit#responses
Items of note:
* Only 5/12 members of the Core Committee participated. :-(
* Only 7 project reps participated. :-(
* Overall, there seemed to be a strong lean toward "no change", vis, a
hypothetical updated PSR-20 logger would live in the \Psr\Log namespace
and the psr/log Composer package, with a 2.0 tag.
* That was far from a unanimous position, however. All other options
had their adherents, although \Psr\Log\V2 seemed to be generally disliked.
The strong lean toward "stet", plus the discussion thread, makes me
think I did a poor job of explaining the problems with it. So, let me
try again:
Consider PSR-3:
interface LoggerInterface
{
public function emergency($message, array $context = array());
public function alert($message, array $context = array());
public function critical($message, array $context = array());
public function error($message, array $context = array());
public function warning($message, array $context = array());
public function notice($message, array $context = array());
public function info($message, array $context = array());
public function debug($message, array $context = array());
public function log($level, $message, array $context = array());
}
Now consider a hypothetical "PHP7-ify only" PSR-20:
interface LoggerInterface
{
public function emergency(string $message, array $context =
array()) : void;
public function alert(string $message, array $context = array()) :
void;
public function critical(string $message, array $context = array())
: void;
public function error(string $message, array $context = array()) :
void;
public function warning(string $message, array $context = array())
: void;
public function notice(string $message, array $context = array()) :
void;
public function info(string $message, array $context = array()) : void;
public function debug(string $message, array $context = array()) :
void;
public function log(string $level, string $message, array $context
= array()) : void;
}
Off hand it seems like they should be easily compatible. However,
consider that most packages are likely to be referencing it like so in
composer.json:
{
"require": {
"psr/log": "~1.0"
}
}
That is, they are saying they're not compatible with psr/log 2.0.
Now we release PSR-20 as psr/log 2.0 on Packagist. My Hare library
already requires PHP 7.3 (because I'm just that forward-looking) so I
can require it easily:
{
"name": "crell/hare",
"require": {
"psr/log": "~2.0"
}
}
Michael's Tortoise library, however, is more staid (by which I mean,
only minimally maintained), and so he hasn't updated his composer.json
file. It still says ~1.0.
Now Sara comes along and tries to write an application that uses both
crell/hare and michaelc/tortoise, because both are solid libraries that
do useful things. Composer will, of course, not let her install both
the 1.0 and 2.0 versions of the same package, so it will simply error
out. crell/hare and micahelc/tortoise are now utterly incompatible with
each other, because they depend on different versions of an
otherwise-identical logging interface. Both would technically work fine
if run on a supported PHP version (that is, 7.1 and up), but the
versioning collision gets in the way. This makes Sara sad, and nobody
wants that.
The simple answer is "well submit a PR to micahaelc/tortoise to update
his version requirement, since we know it works." However, that
introduces a new language version dependency on Tortoise which should be
treated as a major version bump. It also means that Tortoise is now
incompatible with philsturgeon/turtle, which is also using the 1.0
logger. Hence Phil needs to update his Turtle at the same time. (That
sentence is begging to be OHed...)
In short, it means that all 2494 PSR-3 using packages on packagist.org
(as of this writing) need to all release a new major version *at the
same time*. That's totally not going to happen. Or, someone needs to
develop a bridge library called LogPlug that abstracts away the
differences, which... rather defeats the whole purpose of having a PSR
interface.
This seems like an undesirable situation, and one that would likely lead
to PSR-20 never being adopted by anyone simply for entirely artificial
chicken-and-egg reasons. (And really, you don't want artificial chicken
or eggs. They're kinda gross.)
Now, for a trivial case like this where all that's happening is adding
scalar type hints, one could argue that a 1.1 version would suffice.
That's a reasonable argument. However, not all changes are so trivial.
For instance, we may also have cause to add another reserved keyword in
the $context array besides "exception". As a (small) API change that
would necessitate a 2.0 release either way. Or consider PSR-6, where any
update should, presumably, update the expiresAt() method to include a
proper type hint (as we can safely assume PHP 5.5+ now); however, that
would then mean the error handling changes from the errata I *just*
posted (and which is likely to pass based on previous discussion), and
thus also be nominally an API change. Certainly for the heightened
precision one would expect from a "standard" such minor changes should
be taken with caution.
And all of that is assuming changes that are, in all but the strictest
sense, "mostly backward-compatible". Should any other changes be
appropriate for an updated version of a spec, the problem is far worse.
Versioning the interface names would *not* solve all of the problems
presented above. It would, however, address *some* of them.
Given that, I must disagree with the poll respondents who favored a "do
nothing" approach. I am not sure what alternative I favor at the
moment, but I do not feel the status quo is adequate.
(Anthony Ferrara, please correct me if I explained the above wrong;
you're the one who brought it up to me originally.)
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/dd263211-d00d-82a7-98d9-1ca353503f89%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
