[PSR-16] Question about `set` and `setMultiple` methods on PSR-16

[Pedro Cordeiro]

Hi, very quick question. Couldn't find anything on either the spec or the meta doc.

The `set` and `setMultiple` methods define that an `InvalidArgumentException` MUST be thrown if $key is not a legal string value. However, shouldn't these methods specify that an InvalidArgumentException MUST also be thrown if the provided $ttl is neither an integer or a \DateInterval? The spec says a TTL is **normally** defined by either an amount of seconds or a \DateInterval object. However, if we let implementations dictate what TTLs can be, we can end up with incompatible implementations.

Implementation A only allows integers, where B only allows DateIntervals. C only allows some custom wrapper for a TTL value. A, B and C are now incompatible amongst themselves, and we have less INTEROPERABILITY (which is kind of the point of this standard).

Was this discussed?

[Paul Dragoonis]

Hello Pedro,

Invalid is primarily decided by the backend that is being used at the time. 

PSR-16 doesn't define what is or it not a valid TTL (yes we have said INT or DateInterval), however in the context of if it only wants INT or DateInterval only, that's not for us to decide. The PSR-16 standard says that in the event of an invalid passed TTL then this is the specific class typehint that will be thrown. Does this make more sense now?

Many thanks,

Paul

 

--
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+unsubscribe@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/dd2e5055-a45e-4cd9-afb7-196769e588fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pedro Cordeiro]

Hi, Paul! Thanks for replying. I'll reply inline.

> The PSR-16 standard says that in the event of an invalid passed TTL then this is the specific class typehint that will be thrown.

It doesn't, actually. It only says an InvalidArgumentException MUST be thrown if the provided $key is not a legal string. There is no reference to what it SHOULD/MUST do in case of an invalid TTL.

> in the context of if it only wants INT or DateInterval only, that's not for us to decide

In the context of interoperability, I believe it should be. By allowing each implementation to decide if they will work with ONLY int, ONLY \DateInterval or ONLY something else whatsoever, we end up with incompatible implementations. I find it odd that the spec implies that **normally** TTLs are ints or dateintervals, yet enforces neither and allows for each implementation to decide what kind of data it will get.

Since PSR-16 has been accepted, I'm not sure how much it can change, anyway. At this point, I don't think enforcing a minimum would break any of the very few implementations out there. But if I had the choice (and I deeply regret not seeing this before the vote), I'd have the spec force implementations to allow at least ints and dateintervals, while giving room for them to implement any other types they wish so.

Just out of curiosity, is it possible to ammend a PSR once it's live?

Invalid is primarily decided by the backend that is being used at the time. 

PSR-16 doesn't define what is or it not a valid TTL (yes we have said INT or DateInterval), however in the context of if it only wants INT or DateInterval only, that's not for us to decide. The PSR-16 standard says that in the event of an invalid passed TTL then this is the specific class typehint that will be thrown. Does this make more sense now?

Many thanks,

Paul

 

--
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.

[Larry Garfield]

On 01/03/2017 08:43 AM, Pedro Cordeiro wrote:
> Hi, Paul! Thanks for replying. I'll reply inline.
>
> > The PSR-16 standard says that in the event of an invalid passed TTL
> then this is the specific class typehint that will be thrown.
>
> It doesn't, actually. It only says an InvalidArgumentException MUST be
> thrown if the provided $key is not a legal string. There is no
> reference to what it SHOULD/MUST do in case of an invalid TTL.
>
> > in the context of if it only wants INT or DateInterval only, that's
> not for us to decide
>
> In the context of interoperability, I believe it should be. By
> allowing each implementation to decide if they will work with ONLY
> int, ONLY \DateInterval or ONLY something else whatsoever, we end up
> with incompatible implementations. I find it odd that the spec implies
> that **normally** TTLs are ints or dateintervals, yet enforces neither
> and allows for each implementation to decide what kind of data it will
> get.

That's not how I read the spec at all. An implementation that doesn't
accept an int in seconds and a DateInterval is Wrong(tm), per spec. Of
course, what happens when you pass something else is... not defined and
runs into the same issue that PSR-6 had where we docblock-specified
something but not typed it (in that case for PHP version reasons). Damn.

> Since PSR-16 has been accepted, I'm not sure how much it can change,
> anyway. At this point, I don't think enforcing a minimum would break
> any of the very few implementations out there. But if I had the choice
> (and I deeply regret not seeing this before the vote), I'd have the
> spec force implementations to allow at least ints and dateintervals,
> while giving room for them to implement any other types they wish so.
>
> Just out of curiosity, is it possible to ammend a PSR once it's live?

A PSR may not be amended ever. However, errata may be added to the
metadocument by vote of, I guess now the Core Committee, I think?

I need to call a new vote on the PSR-6 errata at some point soon anyway.

--Larry Garfield

[Pedro Cordeiro]

Hi, Larry! Thanks for replying :)

> An implementation that doesn't
> accept an int in seconds and a DateInterval is Wrong(tm), per spec.

I didn't read it like this. Nowhere I read in the entire spec (or in the metadoc) it specifies that integers or dateintervals MUST be accepted by the implementations. It just hints that people **normally** use ints or dateintervals.
I agree that the spec shouldn't specify what should happen in case of a non-int && non-dateinterval ttl, because implementations should be free to ALSO allow different types there.

In my interpretation (which could very well be wrong, and I'll ask you to point the to the specific section of the spec that could correct my interpretation here), the spec doesn't enforce a bare minimum of acceptance, which makes it impossible for me to code agnostically to this interface because I don't know what type to pass (there is no minimum type for all implementations). Do I use ints? Do I use DateIntervals?