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? Em terça-feira, 3 de janeiro de 2017 21:10:04 UTC-2, Larry Garfield escreveu: > > 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 > -- 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/6c54fc87-e05a-4382-b6f4-d2eea6e89109%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
