[PSR-6] Minimum PHP version?

[Larry Garfield]

As long as we're not yet back in Review, there's one more minor point
that I realized. We have a method (expiresAt()) that accepts either a
DateTime or DateTimeImmutable, and so its docblock specifies
DateTimeInterface. However, since DateTimeInterface was introduced in
PHP 5.5 the code itself doesn't specify a type. It's left technically
untyped, which means the interface is compatible all the way back to PHP
5.3.

However, PHP 5.5 is already the legacy, security-only version of PHP.
Does that mean we should go ahead and include DateTimeInterface in the
interface? That would make PSR-6 require PHP 5.5. W3Techs reports that
as being only 13% of the market[1], but most major projects with
releases this year have moved to 5.5 anyway (Symfony3, Zend 3, Drupal 8,
Guzzle 6, many others) so it's likely a done-deal for anyone that would
bother using it. http://phpversions.info/ also indicates that 5.5 is not
exactly hard to come by.

I am not going to delay the PSR too long on it, so if this is a
controversial suggestion I will drop it and move on as is. But I figure
it's worth throwing it out there. Are we comfortable requiring 5.5 for
a PSR interface in a case where it makes sense for the spec?

--
--Larry Garfield

[Robert Hafner]

A few projects using Stash (some of whom are on this list) are still committing to 5.4 support, and I don’t want to tell them they can’t use PSR6 as a result.

Rob

> --
> 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 php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/563918F4.5000708%40garfieldtech.com.
> For more options, visit https://groups.google.com/d/optout.

[Korvin Szanto]

On Tue, Nov 3, 2015 at 12:31 PM Robert Hafner <ted...@tedivm.com> wrote:

A few projects using Stash (some of whom are on this list) are still committing to 5.4 support, and I don’t want to tell them they can’t use PSR6 as a result.

concrete5 uses Stash and requires 5.4+ in every current development branch - though the discussion for 5.5+ is under way - so I feel this sentiment.

That said, where do we draw the line? How long will we be supporting 5.4 with future PSRs? Maybe a better question is how long until we can start writing PSR's that only support PHP 7?

I think we should think about making a bylaw that defines some structure around what minimum php versions we can target. Maybe that's something like "minimum PHP version must be supported at the time of PSR number assignment", maybe it must be supported at the time of PSR release. 

I also want to point out the effect that continued targeting of legacy PHP versions might have on the PHP community as a whole. We don't want to be part of the problem here.

Best wishes,,

Korvin

 

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0963CD15-4A42-41E9-A941-ED4DDD6617B2%40tedivm.com.

[Woody Gilk]

On Tue, Nov 3, 2015 at 2:31 PM, Robert Hafner <ted...@tedivm.com> wrote:

expiresAt()) that accepts either a DateTime or DateTimeImmutable, and so its docblock specifies DateTimeInterface

Any reason not to use:

@param integer|DateTimeInterface $time

In general it is more convenient to use timestamps than to create a new DateTime object: 

$item->expiresAt(time() + 30);

Maybe this was discussed and rejected? It would make the type hint be irrelevant though.

Regards,

--
Woody Gilk
http://about.me/shadowhand

[will.g...@couchbase.com]

A timestamp does not have an explicit timezone so it is not particularly concrete regarding when it should be expired. That being said, most people would expect it to be UTC+0.

[Matteo Beccati]

Hi,

On 03/11/2015 22:02, will.g...@couchbase.com wrote:
> A timestamp does not have an explicit timezone so it is not particularly
> concrete regarding when it should be expired. That being said, most
> people would expect it to be UTC+0.

Why UTC? If anything, I think they would expect it to be their current
(server) timezone. But in fact timestamps are timezone agnostic.

> On Tuesday, November 3, 2015 at 8:53:33 PM UTC, Woody Gilk wrote:
> On Tue, Nov 3, 2015 at 2:31 PM, Robert Hafner <ted...@tedivm.com
> <javascript:>> wrote:
>
> expiresAt()) that accepts either a DateTime or
> DateTimeImmutable, and so its docblock specifies DateTimeInterface
>
> Any reason not to use:
>
> @param integer|DateTimeInterface $time
>
> In general it is more convenient to use timestamps than to create a
> new DateTime object:
>
> $item->expiresAt(time() + 30);
>
> Maybe this was discussed and rejected? It would make the type hint
> be irrelevant though.

Isn't the latter what expiresAfter() is for?

If you remove this particular use case, creating timestamps and DateTime
objects takes pretty much the same effort.


Cheers
--
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

[Matteo Beccati]

On 03/11/2015 21:31, Robert Hafner wrote:
> A few projects using Stash (some of whom are on this list) are still
> committing to 5.4 support, and I don’t want to tell them they can’t
> use PSR6 as a result.

I agree with Robert.

We shouldn't try to enforce a PHP version is single PSRs, unless
strictly necessary, of course.


Cheers

[Woody Gilk]

On Wed, Nov 4, 2015 at 2:56 AM, Matteo Beccati <mat...@beccati.com> wrote:

On 03/11/2015 22:02, will.g...@couchbase.com wrote:
> A timestamp does not have an explicit timezone so it is not particularly
> concrete regarding when it should be expired. That being said, most
> people would expect it to be UTC+0.

Why UTC? If anything, I think they would expect it to be their current
(server) timezone. But in fact timestamps are timezone agnostic.

The timestamp of time() is always timezone independent because the epoch is defined as January 1 1970 00:00:00 GMT.

[Anthony Ferrara]

IMHO, you have the opportunity here to set a strong precedent here.
Why hold everyone else back for years because a few projects haven't
kept up? Keep in mind that the standard is intended to live longer
than individual projects.

So I'd definitely suggest having a minimum of 5.5 for this considering
that it's the minimum supported version. If that means projects who
support 5.4 can't use it, then they should upgrade to 5.5 (considering
5.4 is unsupported). The more pressure we can put on everyone to keep
moving up (and the easier we can make it), the better it will be for
everyone.

We should be discouraging people from avoiding upgrading, not placating to them.

MHO at least...

Anthony

> --
> 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 php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/CAGOJM6LhHeNJL7MFTJEhbS45KzPq216cvnCUAuj1cZmQ_ow%3Dbw%40mail.gmail.com.

[Larry Garfield]

On 11/4/15 9:17 AM, Anthony Ferrara wrote:
> IMHO, you have the opportunity here to set a strong precedent here.
> Why hold everyone else back for years because a few projects haven't
> kept up? Keep in mind that the standard is intended to live longer
> than individual projects.
>
> So I'd definitely suggest having a minimum of 5.5 for this considering
> that it's the minimum supported version. If that means projects who
> support 5.4 can't use it, then they should upgrade to 5.5 (considering
> 5.4 is unsupported). The more pressure we can put on everyone to keep
> moving up (and the easier we can make it), the better it will be for
> everyone.
>
> We should be discouraging people from avoiding upgrading, not placating to them.
>
> MHO at least...
>
> Anthony

I'm very sympathetic to this position, honestly. I agree we shouldn't
break an older version "just because", but in this case there is a
benefit to the spec (albeit a smaller one) to using the 5.5 interface
explicitly.

Really, I'm torn. I want to push PHP forward, and I firmly believe FIG
can/should be a force for that momentum in the world. On the other
hand, I know there are projects stuck on older versions for
release-schedule-promise reasons (dropping a PHP version is a BC
change), and that would inhibit adoption of the spec, even if only for a
while.

Korvin, the C5 dependency is the main sticking point we know about at
the moment. :-) Any chance they could be pushed to 5.5 in the next 2
weeks? Feel free to use this discussion as leverage.

--
--Larry Garfield

[Robert Hafner]

I think there is a fundamental misunderstanding by some of the nonvoting members about what this group is. This is the “Framework Interoperability Group”. It is not the “Progressive PHP group”, the “PHP Police”, or anything like that. The goal of this group is to make it so libraries and components can be shared amongst frameworks with minimal difficulty. The goal, again, is framework interoperability.

Forcing a version upgrade as part of a non-version related PSR is completely inappropriate for this group, especially if multiple framework members have already said they are supporting a lower version for the next N months. It would be one thing if we passed a PSR-version that defined minimum versions (and would obviously have to keep up with that), and we had support from the frameworks. We haven’t gone this yet, so trying to force it through as a last minute change to PSR-6 is, as I have said, inappropriate- it literally goes against the goals of this group by preventing libraries from being interoperable with some of the frameworks that make up this group.

If people think this is something that FIG should get behind then lets go for it as a separate proposal, rather than hijacking this one. If the frameworks vote on it and agree then it should be approached as it’s own issue.

Rob

> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAyV7nHxCHkPHkOGM4JrERJ-%2BZbWRPTHsfNUX5BEtexh4ymhsA%40mail.gmail.com.

[Robert Hafner]

C5 is not the only issue. EZPublish is also supporting 5.4.

Rob

-- 
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 php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/563A2EBD.5010504%40garfieldtech.com.

[Larry Garfield]

The degree to which FIG should be just "standardizing what is already
done" vs. "pushing the PHP ecosystem forward" has been a topic of debate
since the beginning, with no clear resolution. That was one of the
arguments against the PSR-6 model we're using, that it's too forward
looking. :-P

If it were a matter of irrelevancies, like using [] arrays or something,
I would completely agree that it's not wise to force the matter.
However, this is a case where a newer language feature *does* improve
the spec itself, by making it more self-enforcing and explicit. That's
why I think it's worth considering. (As I said, I won't insist on it
and won't delay the spec just for this, but I think it's a fair question
to ask.)

A formal FIG statement on what versions FIG itself targets is probably a
good idea, but I agree it's a separate topic.

--
--Larry Garfield

[Jonathan Eskew]

Rather than force a minimum PHP version, someone could write a userland implementation of \DateTimeInterface (similar to how password_hash and password_verify were "backported" via https://github.com/ircmaxell/password_compat). Then PSR-6 could use \DateTimeInterface in type hints, and PHP 5.4 users could install a DateTimeInterface_compat package.

[Woody Gilk]

That's a good idea, but it won't work because it would also require the user to use an extended DateTime object that implements the interface. The password_hash backport worked because it didn't rely on anything else.

--
Woody Gilk
http://about.me/shadowhand

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ee3671e5-bceb-4814-af4c-b0f8fa652104%40googlegroups.com.

[Jonathan Eskew]

The compatibility library could include a way to convert a standard DateTime object to a provided implementation of \DateTimeInterface. Users would need to handle the conversion themselves.

[Andrew Carter]

Could there not be two tagged versions, one with DateTime and one with DateTimeInterface?

Composer is intelligent enough to resolve the dependencies and select the appropriate version based upon the environment.

[Larry Garfield]

I'd be comfortable with that if the rest of the group is. Specifying an
alternate in the spec itself is a reasonable enough task, and I can sort
out a 1.0.0 and 1.1 in the repo for Packagist.

> --
> 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 php-fig+u...@googlegroups.com

> <mailto:php-fig+u...@googlegroups.com>.

> To post to this group, send email to php...@googlegroups.com

> <mailto:php...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/8ed4ea6d-4b82-4658-92d6-b24d59b20271%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/8ed4ea6d-4b82-4658-92d6-b24d59b20271%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Dracony]

I definitely feel ok with it. A specific implementation that would be 5.3 compatible can easily drop the typehint entirely without violating the interface and do the conversion internally. So "best of two worlds". By the time PSR-6 actually sees the light of day and actually acquires some implementations PHP 5.5 will definitely be obsolete.

[Dracony]

I meant PHP 5.4

On Tuesday, November 3, 2015 at 9:28:45 PM UTC+1, Larry Garfield wrote:

[Andrew Carter]

Serious follow up question, should there be a PHP 7 version with return type hints included?

[Dracony]

I guess the best answer is to have a superceding PSR int he future, after PHP 5 goes EOL entirely

On Tuesday, November 3, 2015 at 9:28:45 PM UTC+1, Larry Garfield wrote:

[Andrew Carter]

I'm not sure I'm in favour of going through the entire PSR process to move type hints from phpdoc into the actual code (scalar or return).

PHP 7 would be a B/C break - so it would be a 2.0 version.

If there is going to be resistance in this group to releasing updated interfaces that use PHP-7 features then that's all the more reason to consider PHP-7 in this version now.

[Dracony]

the PSRs have to stay in the field of practicality. Setting PHP7 as a minimum requirement is imparctical at this time. Furthemore it's not like moving them from docblock to actual code will actually bring some tangible value to it.

On Tuesday, November 3, 2015 at 9:28:45 PM UTC+1, Larry Garfield wrote:

[Andrew Carter]

I didn't suggest setting PHP-7 as a minimum requirement?

"Furthemore it's not like moving them from docblock to actual code will actually bring some tangible value to it." <- That's ridiculous. Of course they bring value.

As has already been mentioned, this group is about making standards that last. By the time this PSR has gone through the review stage PHP 7 will have been released, it makes sense for it to accommodate those wanting to use PHP 7 features.

On top of this, there is absolutely no cost to doing it this way. Composer selects the version of the interfaces based on your environment - that way if PHP can enforce the specification (as written), it does.

[Korvin Szanto]

On Tue, Nov 10, 2015 at 9:25 AM Andrew Carter <andrewca...@gmail.com> wrote:

I didn't suggest setting PHP-7 as a minimum requirement?

"Furthemore it's not like moving them from docblock to actual code will actually bring some tangible value to it." <- That's ridiculous. Of course they bring value.

As has already been mentioned, this group is about making standards that last. By the time this PSR has gone through the review stage PHP 7 will have been released, it makes sense for it to accommodate those wanting to use PHP 7 features.

On top of this, there is absolutely no cost to doing it this way. Composer selects the version of the interfaces based on your environment - that way if PHP can enforce the specification (as written), it does.

I think that's fair, PHP7 return types being written added shouldn't change the compatibility of the class as long as the implementors are following the doc blocks.

Unfortunately that isn't the case for the issue at hand. Adding the type hint for php 5.5 when the 5.4 version has none triggers a fatal error no?

I honestly think we should just require PHP 5.5+.

 

On Tuesday, November 10, 2015 at 5:12:29 PM UTC, Dracony wrote:

the PSRs have to stay in the field of practicality. Setting PHP7 as a minimum requirement is imparctical at this time. Furthemore it's not like moving them from docblock to actual code will actually bring some tangible value to it.

On Tuesday, November 3, 2015 at 9:28:45 PM UTC+1, Larry Garfield wrote:

As long as we're not yet back in Review, there's one more minor point
that I realized.  We have a method (expiresAt()) that accepts either a
DateTime or DateTimeImmutable, and so its docblock specifies
DateTimeInterface.  However, since DateTimeInterface was introduced in
PHP 5.5 the code itself doesn't specify a type.  It's left technically
untyped, which means the interface is compatible all the way back to PHP
5.3.

However, PHP 5.5 is already the legacy, security-only version of PHP.  
Does that mean we should go ahead and include DateTimeInterface in the
interface?  That would make PSR-6 require PHP 5.5.  W3Techs reports that
as being only 13% of the market[1], but most major projects with
releases this year have moved to 5.5 anyway (Symfony3, Zend 3, Drupal 8,
Guzzle 6, many others) so it's likely a done-deal for anyone that would
bother using it. http://phpversions.info/ also indicates that 5.5 is not
exactly hard to come by.

I am not going to delay the PSR too long on it, so if this is a
controversial suggestion I will drop it and move on as is.  But I figure
it's worth throwing it out there.  Are we comfortable requiring 5.5 for
a PSR interface in a case where it makes sense for the spec?

--
--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 php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/cbd28b28-6395-4e08-88e5-b3d5540e2c0d%40googlegroups.com.

[Matteo Beccati]

On 10/11/2015 18:25, Andrew Carter wrote:
> As has already been mentioned, this group is about making standards that
> last. By the time this PSR has gone through the review stage PHP 7 will
> have been released, it makes sense for it to accommodate those wanting
> to use PHP 7 features.
>
> On top of this, there is absolutely no cost to doing it this way.
> Composer selects the version of the interfaces based on your environment
> - that way if PHP can enforce the specification (as written), it does.

What about those implementing the interface? Would they need to maintain
multiple different versions of the project just to cope with t the
various interface versions?

A docblock, yeah maybe you could simply ignore it... method signatures
are a different beast though.

[Dracony]

When PHP7 becomes widely accepted (in a year maybe) and PHP 5 goes EOL imho nobody will really have a problem to update to a newer superceding PSR, especially since the change will be trivial.

It is obviously not perfect, but if PSR-6 gets released with PHP7 typehints it will alienate practically every implementation, since people would still want PHP 5 support 

[Larry Garfield]

No one is talking about PHP 7 type hints. We're talking about a PHP 5.5
type to apply in a parameter. No more, no less. There are no PHP 7 type
hints in PSR-6, nor will there be at this time.

> --
> 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 php-fig+u...@googlegroups.com

> <mailto:php-fig+u...@googlegroups.com>.

> To post to this group, send email to php...@googlegroups.com

> <mailto:php...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/e1e81020-dd1f-4df6-b74a-7f7ed9adc41e%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/e1e81020-dd1f-4df6-b74a-7f7ed9adc41e%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--
--Larry Garfield

[Dracony]

I was replying to the "By the time this PSR has gone through the review stage PHP 7 will have been released, it makes sense for it to accommodate those wanting to use PHP 7 features" part. 

[Attila Szeremi]

About PHP 5 vs 7:

Would it not be possible to maintain a version for both 5 and 7 under different version tags?

If you specify in one that the version is <7.0.0 and in another that the version ~7.0, and just having people requiring the latest possible, wouldn't composer automatically provide you with the version your PHP supports?

[Navarr Barnier]

I don't have PHP7 to test on but I'm assuming you'll get funky errors if the class extending the PSR doesn't have static type hints where the PSR does.

[Matteo Beccati]

On 12/11/2015 23:41, Attila Szeremi wrote:
> Would it not be possible to maintain a version for both 5 and 7 under
> different version tags?
> If you specify in one that the version is <7.0.0 and in another that the
> version ~7.0, and just having people requiring the latest possible,
> wouldn't composer automatically provide you with the version your PHP
> supports?

I think this has already been suggested, please check the archives.

I believe it would force everyone who has a public PSR-6 implementation
to maintain two separate versions too.

[Korvin Szanto]

PHP 7 is a bike shed, I meant to bring it up only to point out that we'll at some point need to drop support for PHP 5 all together so we might want to set up some structure around what versions we target for future PSR's. That is a topic for a separate thread.

We need to be discussing what PHP version PSR-6 will require and not what we're going to do with PHP 7. I say we should require PHP 5.5+ so that we can use the proper type hints, others say that we need to keep support for PHP 5.4 due to adoption concerns. Lets find a solution for this so that we can be done with PSR-6.

--
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 php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5645D226.4000309%40beccati.com.

[Navarr Barnier]

I think the only appropriate way to go with this is to support the lowest common denominator - 5.4 for better framework interop.

That said, while I know at least one person voiced opposition to it, PSRs can be created to replace it for newer versions of PHP, similar to how there are multiple autoloading PSRs.

I personally can't think of any way around that.

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/bzLR5bgk2Ug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWU9eHt20tCWYDG3hr40tGT%2BO1UmFmc9xpeAyq748%3DgXqQ%40mail.gmail.com.

[Alessandro Pellizzari]

On Fri, 13 Nov 2015 13:05:58 +0100
Matteo Beccati <mat...@beccati.com> wrote:

> On 12/11/2015 23:41, Attila Szeremi wrote:
> > Would it not be possible to maintain a version for both 5 and 7
> > under different version tags?

> I think this has already been suggested, please check the archives.
>
> I believe it would force everyone who has a public PSR-6
> implementation to maintain two separate versions too.

I think versioning the PSR is not a bad idea, especially for the
typehints. What are the cases?

1- I want my lib to be compatible with PHP <=5.4: I depend on PSR-6
v5.4 and only support DateTime. The user will convert DateTimeImmutable
to DateTime before calling the function.

2- I want my lib to support DateTimeInterface: I depend on PHP 5.5 and
PSR-6 v5.5

3- I want my lib to support both AND comply with PSR-6: I maintain 2
versions of my lib: one for PHP <=5.4 and one for >=5.5, each depending
on a different version of PSR-6.

Not having a versioned PSR-6 makes supporting it and PHP >=5.5
(DateTimeInterface) impossible/cumbersome.

The alternative is to remove DateTime from the spec and leave it as a
suggestion, and the result will be that libs will implement DateTime,
DateTimeImmutable, DateTimeInterface, integers and date-formatted
strings.

Bye.

[Jonathan Eskew]

Opting not to typehint against DateTimeInterface makes this a much worse spec. Either the method will need to have no typehint, which means that individual implementations must take care of type safety on their own, or the interface will have to typehint against what's available to PHP 5.4, which would mean that up-to-date installations wouldn't be able to use DateTimeImmutable or any other DateTimeInterface implementation.

I wrote a shim package to hopefully address the concern with typehinting against DateTimeInterface. If you take a look at the package on github, you'll notice how little code is necessary to shim this interface. Pointing users who are stuck on an outdated PHP version to this or a similar shim seems like a better idea than watering down the spec.

-Jonathan 

[Matt Kynaston]

Short-time lurker here. I've got a work-in-progress ::plug:: implementation for Zend Cache over here: https://github.com/kynx/zend-cache-psr6. It's my own thing - no affiliation to ZF.

 

Opting not to typehint against DateTimeInterface makes this a much worse spec.

Agree.

 

On Friday, November 13, 2015 at 11:17:10 AM UTC-8, Navarr Barnier wrote:

I think the only appropriate way to go with this is to support the lowest common denominator - 5.4 for better framework interop.

I had no qualms setting "requires" : {"php" : ">=5.5"). PSR-6 compatibility is going to be new for every framework. No one can complain if their EOL'd version of PHP isn't supported. OK, they will, but the framework hasn't broken anything for them by introducing a new adapter. It's not like they're forced to use it.

Matt

[Anthony Ferrara]

The prime problem here is that you'd need two copies of everything.
Because the dependency is chosen not just by the library, but by the
consumer as well. So you'd need two copies of all of the libraries
that implement the interface.

The problem with dependencies could be solved with a conditional
autoloader, but even that gets messy quickly.

I'd suggest sticking to one version. But therin lies the deepest
problem. So I don't know...

I don't envy this position, because you're stuck between two sucky
alternatives: hold back adoption of features or not be used. Either
end sucks.

Anthony

> --
> 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 php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/d62c1f48-09dd-4361-a8d0-0800f3a4240b%40googlegroups.com.

[Dracony]

To me the only viable choice seems to be removing the typehint. PHP has a long history of libraries used without typehinting, so this will really not hurt anyone. If anything its only an esthetic hindrance. While supporting multiple versions is a very practical hindrance for both developers and users. The typehint can be added in a future PSR that can be released when 5 reaches EOL. It is basically an idealism vs practicality dilemma, and being an interpolation group I think practical use should be a priority.

[will.g...@couchbase.com]

100% agreed. The additional cognitive workload to understand the tagging/versioning far outweighs the benefits of having the typehints..

[Alex Bowers]

Dracony, are all the versions that do not implement the datetime interface not EOL now anyway? So what would be different in a year or 2 down the line. People will still want to support outdated versions. Either it gets done now, or it won't get done is how I think this will end up going.

Also. Updating it with a different PSR down the line will add more confusion than versioning this one I think, because then there will be either 2 competing PSRs, or a PSR that is now EOL with many projects supporting a now unsupported PSR.

--
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 php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f0ec49f8-3915-4a47-9b39-8489b34423a6%40googlegroups.com.

[Roman Tsjupa]

Well 5.4 is still widely used, it only went EOL about 2 months ago. But taking into the account the pace at which this PSR is going it is probably a safe bet to assume PHP 5.4 will be gone by the time its is finally voted for.

On the other hand if you look from a framework context, a framework relying on PSR-6 will also have to drop support for PHP 5.4. And some frameworks (e.g. ZF 2.4 and my PHPixie) still advertise themselves as 5.3 compatible.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/bzLR5bgk2Ug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAn%3DCzVpESQmcXBenGFbGA3r1A3oZgj1p7_m%3D5kqG2fk5zRsCQ%40mail.gmail.com.

[Matthew Weier O'Phinney]

On Tuesday, November 17, 2015 at 6:51:47 PM UTC-6, Dracony wrote:
> Well 5.4 is still widely used, it only went EOL about 2 months ago. But taking into the account the pace at which this PSR is going it is probably a safe bet to assume PHP 5.4 will be gone by the time its is finally voted for.
>
>
> On the other hand if you look from a framework context, a framework relying on PSR-6 will also have to drop support for PHP 5.4. And some frameworks (e.g. ZF 2.4 and my PHPixie) still advertise themselves as 5.3 compatible.

We wouldn't add PSR-6 support to an existing minor version, much less an LTS, which makes the point moot. We'll add it in a later 2.x or 3.x version, which are all at 5.5+.

[Matteo Beccati]

Hi,

On 18/11/2015 03:45, Matthew Weier O'Phinney wrote:
> On Tuesday, November 17, 2015 at 6:51:47 PM UTC-6, Dracony wrote:
>> Well 5.4 is still widely used, it only went EOL about 2 months ago.
>> But taking into the account the pace at which this PSR is going it
>> is probably a safe bet to assume PHP 5.4 will be gone by the time
>> its is finally voted for.
>>
>> On the other hand if you look from a framework context, a framework
>> relying on PSR-6 will also have to drop support for PHP 5.4. And
>> some frameworks (e.g. ZF 2.4 and my PHPixie) still advertise
>> themselves as 5.3 compatible.
>
> We wouldn't add PSR-6 support to an existing minor version, much less
> an LTS, which makes the point moot. We'll add it in a later 2.x or
> 3.x version, which are all at 5.5+.

I agree. I don't think many projects are going to retrofit PSR-6 into
the current stable versions. I think it is safe enough to assume that by
the time PSR-6 is adopted, PHP 5.4 compatibility most likely won't be a
requirement anymore.

There might be a few exceptions that can roll out PSR-6 compatibility
sooner than that, but then again \DateTimeInterface is just in the
phpdoc @param, so there is no error being triggered on PHP 5.4.

[Stefano Torresi]

Personally, I'm all up for pushing the outside of the envelope rather than holding back fearing lack of adoption, but I also understand why someone wouldn't want to do that.

Il giorno mer 18 nov 2015 alle ore 08:01 Matteo Beccati <mat...@beccati.com> ha scritto:

I think it is safe enough to assume that by
the time PSR-6 is adopted, PHP 5.4 compatibility most likely won't be a
requirement anymore.

Fair point.

It is worth noting that one of the reasons that made PSR-7 resonate the most is the new paradigm it introduced, rather than the similarities with existing HTTP components, so the whole point about FIG having to be conservative is a bit moot.

 

There might be a few exceptions that can roll out PSR-6 compatibility
sooner than that, but then again \DateTimeInterface is just in the
phpdoc @param, so there is no error being triggered on PHP 5.4.

I think Larry was suggesting the actual parameter type hint, not just the docblock.

Also, imho versioning is a convoluted solution that introduces more problems than it solves.

Ultimately, I guess a straight forward vote on this issue could be the only way to make a decision.

[Dracony]

Well, I'm actually convinced now. After reading through the replies again I'm switching teams to join the minimum 5.5 camp =)

[Paul Dragoonis]

Is the consensus here 5.5+? 

I'm about to announce REVIEW over and give an opportunity to clarify things, like PHP Min Versions, before moving to VOTE?

--
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 php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/323c5286-4f98-4fd2-a953-21ffdf9c1bff%40googlegroups.com.

[will.g...@couchbase.com]

I don't think shifting to PHP5.5+ would be review safe as you'd change the api.

[Larry Garfield]

I disagree that it's an API change. As is, if you pass anything but a DateTime or DateTimeImmutable to expiresAt(), you're wrong and the code must break.  That's implied by the @param.  The only consideration is whether to also specify that in the method signature itself, thus removing the need for implementers to check that themselves.

At the moment I am leaning toward not doing so, largely to avoid one more controvercial point in PSR-6 (we have enough <g>).  There's a FIG meeting tomorrow here at php[world] where I welcome those who wish to try and convince me otherwise.

--Larry Garfield

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f3b7737a-a1c2-4c4e-b16c-9c0ae975006d%40googlegroups.com.

[Roman Tsjupa]

What is that controversial point? For those not attending php[world] tomorrow

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/bzLR5bgk2Ug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/564CF637.3080005%40garfieldtech.com.

[Larry Garfield]

Do we make the type check explicit in the method signature, thus simplifying work for implementers at the cost of making a PHP 5.4 or lower implementation of PSR-6 impossible: Y/N.

--Larry Garfield

[Jeroen De Dauw]

PHP >= 5.5 is fine for me.

[Roman Tsjupa]

Ultimately the libraries can provide a PSR-ish compatibility layer for 5.4 and below.  And also its a slight convincing nudge to upgrade to 5.5 in a sort of GoPHP5.5 kind of way

On Wed, Nov 18, 2015, 23:17 Jeroen De Dauw <jeroen...@gmail.com> wrote:

PHP >= 5.5 is fine for me.

--

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/bzLR5bgk2Ug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0def4b19-57f5-4aee-8ad6-51c45b84c61a%40googlegroups.com.

[Korvin Szanto]

So PSR-6 seems to be in review, I believe if we decide NOT to go with php 5.5 we can just open a vote today. I think someone on the PSR-6 working group should make a decision in here so that we can get on with it.

Thanks,

Korvin

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 php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANamvv1tvnXDq9X0_YeQp6FcWzki8x9AtsFLZTBQdBRGXPgJcw%40mail.gmail.com.