> Granted, the majority of template engines use a template file-name and a
set of name/value pairs
Twig also doesn't reference templates by file name.
It references them by logical name instead, and uses loaders to resolve
that to whatever storage you'd like to use for the template strings.
--
Y
Le 26 sept. 2017 01:34, "David Lundgren" a écrit :
In the same way that http-interop did, I created an output-interp
organization on github, https://github.com/output-interop
The spec that is currently published was founded on the work that Giuseppe
Mazzapica started with Foil PHP https://github
Hi
sorry to come late in the story. I'm the author of the PSR-6 implementation
in Symfony Cache 3.1.
There are more grey zones on PSR-6 and maybe an errata should address them
also?
Below is the list I computed.
First, on the very matter of this topic, IMHO the best behavior is to
trigger an Inv
Thanks for the reply Larry,
I'd like to report that there has been great collaboration with the
php-cache implementers around the test suite, that is now used as a
reference by both php-cache and Symfony:
https://github.com/php-cache/integration-tests/
The good thing is that all these small impli
Hi,
PSR-6 makes it very clear that the expiration date/interval is really a
maximum and that implementations are free to make the actual item removal
happen anytime before.
Actually, memcached kind of proved that *for the cache use case*, it can be
verify effective to let the backend clean items u
Hi all,
Regarding TTL, I don't care much for DateInterval either but I think it
> carried over from PSR-6
>
I'm all for keeping DateInterval asis, because it will help writing PSR-6
bridges.
The 5-6 lines snippet you gave Rasmus is actually a one-liner in Symfony,
where we deal with absolute tim
On CacheInterface:
>
>- doesn't say what happens when $key is invalid. I guess the same
>exception as PSR-6. Should be written?
>
>
I missed adding one note here: the fact that getMultiple returns *all*
keys, even cache misses, makes it impossible to (efficiently) implement a
PSR-16 to PSR
Hi all,
as posted yesterday, I gave PSR-16 a try in Symfony Cache (
https://github.com/symfony/symfony/pull/20636).
This resulted is a number of comments that I summarized in a PR on the
FIG's github repo:
https://github.com/php-fig/fig-standards/pull/846
Here are the collected issues/questions:
Thanks for the answer Jordi,
I fine with your answers! Just a few notes:
IMO this kinda goes in the simplicity category, which is why I still think
> enforcing an array return value vs a traversable would also be simpler.
>
Understood.
Then I'd like to suggest to add a second `$default = null`
Yes PSR-16 is meant to live alongside PSR-6, so it has to be reasonably
> compatible and yes a bridge has been done (https://github.com/php-fig/si
> mplecache/commit/13f43ba7f6d5ce37c6c115c26a5f653c2d9c1e18).
>
Note that by not sharing the same namespace for exceptions, the actual
bridge is going
Lukas Kahwe Smith
Larry Garfield
Beau Simensen
Tobias Nyholm
Sara Golemon
Marc Alexander
Matthew Weier O’Phinney
Graham Daniels
Nicolas
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this grou
Hi all,
for the shake of trying (meaning I come here with no announcement at all
that this is going to be merged), here is what this currently looks like on
the Symfony container:
https://github.com/symfony/symfony/pull/21265
the exception part is really where things start to look like a zoo. Bec
Thanks for your answer Máté
Without ContainerInterface, I should have used an Adapter (e.g. the
> Acclimate package) or I could have hardwired a specific container into my
> framework to achieve so (I would have hated both solutions).
>
It looks like the only feature of PSR11 that this is using
Hi David,
let's drop any distinction between "entry not found" and "dependency
> missing". We don't need this because users of containers can anyway figure
> that out.
>
I'd like to propose the opposite alternative. That's no a rebuttal of yours
and I sincerely thank you for being so open to comm
Regarding you last suggestion I'm having trouble seeing the difference with
> the current version of the spec, could you pinpoint it more explicitly?
>
There are two differences:
The most important one is that the *wording* of the PSR need to be as clear
as possible. Finding a clear way to expre
No surprise, I 100% agree with Matthew's analysis. Option 2 also for me.
--
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+unsubscr
16 matches
Mail list logo
