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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/dd2e5055-a45e-4cd9-afb7-196769e588fc%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/dd2e5055-a45e-4cd9-afb7-196769e588fc%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/7fc0579e-42f4-4ad6-9ce1-1c69bfcc66e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
