Re: [REVIEW] PSR-16 Simple Cache

2016-11-29 Thread Adrien Crivelli 


> yes a bridge has been done 
> (
> https://github.com/php-fig/simplecache/commit/13f43ba7f6d5ce37c6c115c26a5f653c2d9c1e18).
>  
>
>

That commit doesn't mention why the bridge has been removed from the source 
tree. Would you please let us know the reason ? Is it considered out of 
scope ? Is it living in another package ?

To me it seems it could have been useful, but I may be missing something 
obvious.

-- 
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...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/552a2394-6702-4f62-8e7f-05eae002f69f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

2016-11-29 Thread Nicolas Grekas 
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 to be much more verbose (even more if `*Multiple` methods
are going to accept array|Traversable.)
And converting instances of CacheException (the interface) from one
namespace to another is even going to be impossible...

-- 
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...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAOWwgpnmbSLp7AHoBYkzHihe6BQ1S%3D57V4Q2egZMWe_x0QaOTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12] Survey for outstanding issues

2016-11-29 Thread Korvin Szanto 
We're still gathering responses from a few member projects unfortunately.
We will announce results once those are in.

Best wishes,
Korvin
On Fri, Nov 25, 2016 at 11:26 AM glen-84  wrote:

> What were the results?
>
>
> On Monday, 17 October 2016 19:22:09 UTC+2, Korvin Szanto wrote:
>
> Hi All,
> I've been dragging my feet a bit on getting this survey completed and put
> out there, but I think we're now ready to get some real feedback. We will
> be accepting responses to this survey for about the next two weeks. I'm not
> going to be super specific about the timing of it, but at some point after
> two weeks has passed we will disable responses and start reviewing the
> results.
>
> Q: Who can take this survey?
> A: Anyone who is familiar with PHP 7 and feels like they have a stake in
> this should add a response to this survey.
>
> Q: Should I research PHP 7 first?
> A: It's important that you know all of the syntax and features that we
> plan to be defining so you will do well by doing your research first.
>
> Q: Do I need to read through PSR-12 first?
> A: You certainly should. We do copy relevant text out directly from the
> PSR-12 documents into the survey so you can likely get through this survey
> without studying PSR-12 too hard.
>
> Q: Why do you ask for my full name?
> A: So that we can differentiate one reply from the next. A project
> representative may reply to the form twice, once for the project and once
> for themselves. If this makes you uncomfortable, feel free to put a handle
> in instead. Try to make it unique.
>
> Q: Why do you ask for my email?
> A: If we have any kind of misunderstanding or want to get more information
> we might shoot you an email. If this isn't something you want to share
> please do not share it.
>
> Q: I'm a jokester, wouldn't it be funny if I made a joke response?
> A: Please oh please do not make me sort through joke / fake replies :(
>
> We hope to get a good idea of what the public, projects, and
> representatives think about what we have put together. We ask that you
> respond only once unless you are also a representative of a project in the
> PHP-FIG and ask that you read all directions in the survey carefully.
>
> After we've had time to sift through the results, we will post a summary
> on the list and post an anonymized list of responses that can be seen by
> all.
>
> Please take this survey here: https://goo.gl/forms/SonvjwqicPoBBwwl1
>
>
> PSR-12:
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
> Meta:
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md
>
> Thanks for taking the time to respond!
> Korvin & the PSR-12 team
>
> --
> 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...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/77bde59b-1072-4607-9a73-cc222bff8d82%40googlegroups.com
> 
> .
> 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 php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANeXGWWECRC-qQhf8SdyA%3Du5ArMJpSJ%2Bg6maagvnG3s8T2UbMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

2016-11-29 Thread Rasmus Schultz 
ok, will try to put in a PR for that tomorrow :-)



On Tue, Nov 29, 2016 at 2:21 PM, Jordi Boggiano  wrote:

> 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). I agree it
> shouldn't sound like it depends on PSR-6 though. If you have ideas how to
> clarify the wording PRs are welcome :)
>
> Cheers
>
>
> On 29/11/2016 09:52, Rasmus Schultz wrote:
>
>> This is an application concern IMO, much like the management of
>>>
>> multiple cache pools, etc.
>>
>> Yeah, for some types of cache-servers, flushing expired entries
>> on-demand may not even be a thing - so this is likely outside the scope
>> of what should be interoperable, as this kind of functionality is
>> implementation-specific.
>>
>> Oh, and here's a simple flat-file cache-implementation:
>>
>> https://github.com/kodus/file-cache
>>
>> It's complete, but will of course change with the coming interface
>> updates.
>>
>> I don't know if there are any other flat implementations of PSR-16 cache
>> out there? I don't see any on Packagist. So this might be helpful as a
>> real-world case.
>>
>> One other thing, about the documentation and meta... it all sounds like
>> PSR-16 was designed to be a layer on top of PSR-6? It almost sounds as
>> though PSR-16 *depends* upon PSR-6?
>>
>> That seems really wrong. I mean, PSR-16 is complete within it's own
>> scope, and has no dependency on PSR-6 whatsoever - it's perfectly
>> feasible to make PSR-16 libraries stand alone.
>>
>> I think it's great if the meta/doc states that it was designed with
>> PSR-6 compatibility in mind, making it possible to bridge PSR-6 to
>> PSR-16, but both the doc and meta at the moment make it sound like
>> that's it's only purpose...
>>
>> I personally view it as a simple alternative to PSR-6, not a layer that
>> I'm going to put over it. (I don't want to hide complexity - I want to
>> remove it and simplify.)
>>
>> Has a PSR-6 to PSR-16 bridge been implemented?
>>
>>
>> On Mon, Nov 28, 2016 at 10:00 AM, Jordi Boggiano > > wrote:
>>
>> On 28/11/2016 09:51, Rasmus Schultz wrote:
>>
>> What about garbage collection?
>>
>> I know that some cache-servers may take care of this
>> automatically, but
>> for something like a file-based cache, it needs to get triggered.
>>
>> Is it just left up to each implementation to take care of this in
>> whatever way they need to?
>>
>>
>> Yes :) This is an application concern IMO, much like the management
>> of multiple cache pools, etc.
>>
>> If you read again my post from 4 years ago [1], PSRs I find are
>> largely beneficial for libraries and not for
>> frameworks/applications. Applications are in control, but libraries
>> have no control and are dropped in random contexts. It kinda bums me
>> out that many still don't seem to understand that (or just don't see
>> it that way?).
>>
>> It's unfortunate that FIG has framework in its name because it is
>> highly misleading, but down the line Framework-level
>> Interoperability means having interoperable libraries more than
>> frameworks being able to interact with each other.
>>
>> [1] https://seld.be/notes/one-logger-to-rule-them-all
>> 
>>
>> Cheers
>>
>> --
>> Jordi Boggiano
>> @seldaek - http://seld.be
>>
>> --
>> 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/kSj_yVbkwOw/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> php-fig+unsubscr...@googlegroups.com
>> .
>> To post to this group, send email to php-fig@googlegroups.com
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/13388408-c187-2738
>> -7940-1084f473be5b%40seld.be
>> > 8-7940-1084f473be5b%40seld.be>.
>>
>> 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 php-fig+unsubscr...@googlegroups.com
>> .
>> To post to this group, send email to php-fig@googlegroups.com
>> .
>> To view this discussion on the web visit
>> ht

Re: [REVIEW] PSR-16 Simple Cache

2016-11-29 Thread Jordi Boggiano 
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/simplecache/commit/13f43ba7f6d5ce37c6c115c26a5f653c2d9c1e18). 
I agree it shouldn't sound like it depends on PSR-6 though. If you have 
ideas how to clarify the wording PRs are welcome :)


Cheers

On 29/11/2016 09:52, Rasmus Schultz wrote:

This is an application concern IMO, much like the management of

multiple cache pools, etc.

Yeah, for some types of cache-servers, flushing expired entries
on-demand may not even be a thing - so this is likely outside the scope
of what should be interoperable, as this kind of functionality is
implementation-specific.

Oh, and here's a simple flat-file cache-implementation:

https://github.com/kodus/file-cache

It's complete, but will of course change with the coming interface updates.

I don't know if there are any other flat implementations of PSR-16 cache
out there? I don't see any on Packagist. So this might be helpful as a
real-world case.

One other thing, about the documentation and meta... it all sounds like
PSR-16 was designed to be a layer on top of PSR-6? It almost sounds as
though PSR-16 *depends* upon PSR-6?

That seems really wrong. I mean, PSR-16 is complete within it's own
scope, and has no dependency on PSR-6 whatsoever - it's perfectly
feasible to make PSR-16 libraries stand alone.

I think it's great if the meta/doc states that it was designed with
PSR-6 compatibility in mind, making it possible to bridge PSR-6 to
PSR-16, but both the doc and meta at the moment make it sound like
that's it's only purpose...

I personally view it as a simple alternative to PSR-6, not a layer that
I'm going to put over it. (I don't want to hide complexity - I want to
remove it and simplify.)

Has a PSR-6 to PSR-16 bridge been implemented?


On Mon, Nov 28, 2016 at 10:00 AM, Jordi Boggiano mailto:j.boggi...@seld.be>> wrote:

On 28/11/2016 09:51, Rasmus Schultz wrote:

What about garbage collection?

I know that some cache-servers may take care of this
automatically, but
for something like a file-based cache, it needs to get triggered.

Is it just left up to each implementation to take care of this in
whatever way they need to?


Yes :) This is an application concern IMO, much like the management
of multiple cache pools, etc.

If you read again my post from 4 years ago [1], PSRs I find are
largely beneficial for libraries and not for
frameworks/applications. Applications are in control, but libraries
have no control and are dropped in random contexts. It kinda bums me
out that many still don't seem to understand that (or just don't see
it that way?).

It's unfortunate that FIG has framework in its name because it is
highly misleading, but down the line Framework-level
Interoperability means having interoperable libraries more than
frameworks being able to interact with each other.

[1] https://seld.be/notes/one-logger-to-rule-them-all


Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

--
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/kSj_yVbkwOw/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/php-fig/13388408-c187-2738-7940-1084f473be5b%40seld.be

.

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 php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CADqTB_gx8bysGMiQ5uep7jWE4XS8rCiz9%2BjhypjKWqOPJurZ5A%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.



--
Jordi Boggiano
@seldaek - http://seld.be

--
You received this message because you are subscribed to

Re: [REVIEW] PSR-16 Simple Cache

2016-11-29 Thread Rasmus Schultz 
> This is an application concern IMO, much like the management of multiple
cache pools, etc.

Yeah, for some types of cache-servers, flushing expired entries on-demand
may not even be a thing - so this is likely outside the scope of what
should be interoperable, as this kind of functionality is
implementation-specific.

Oh, and here's a simple flat-file cache-implementation:

https://github.com/kodus/file-cache

It's complete, but will of course change with the coming interface updates.

I don't know if there are any other flat implementations of PSR-16 cache
out there? I don't see any on Packagist. So this might be helpful as a
real-world case.

One other thing, about the documentation and meta... it all sounds like
PSR-16 was designed to be a layer on top of PSR-6? It almost sounds as
though PSR-16 *depends* upon PSR-6?

That seems really wrong. I mean, PSR-16 is complete within it's own scope,
and has no dependency on PSR-6 whatsoever - it's perfectly feasible to make
PSR-16 libraries stand alone.

I think it's great if the meta/doc states that it was designed with PSR-6
compatibility in mind, making it possible to bridge PSR-6 to PSR-16, but
both the doc and meta at the moment make it sound like that's it's only
purpose...

I personally view it as a simple alternative to PSR-6, not a layer that I'm
going to put over it. (I don't want to hide complexity - I want to remove
it and simplify.)

Has a PSR-6 to PSR-16 bridge been implemented?


On Mon, Nov 28, 2016 at 10:00 AM, Jordi Boggiano  wrote:

> On 28/11/2016 09:51, Rasmus Schultz wrote:
>
>> What about garbage collection?
>>
>> I know that some cache-servers may take care of this automatically, but
>> for something like a file-based cache, it needs to get triggered.
>>
>> Is it just left up to each implementation to take care of this in
>> whatever way they need to?
>>
>
> Yes :) This is an application concern IMO, much like the management of
> multiple cache pools, etc.
>
> If you read again my post from 4 years ago [1], PSRs I find are largely
> beneficial for libraries and not for frameworks/applications. Applications
> are in control, but libraries have no control and are dropped in random
> contexts. It kinda bums me out that many still don't seem to understand
> that (or just don't see it that way?).
>
> It's unfortunate that FIG has framework in its name because it is highly
> misleading, but down the line Framework-level Interoperability means having
> interoperable libraries more than frameworks being able to interact with
> each other.
>
> [1] https://seld.be/notes/one-logger-to-rule-them-all
>
> Cheers
>
> --
> Jordi Boggiano
> @seldaek - http://seld.be
>
> --
> 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/to
> pic/php-fig/kSj_yVbkwOw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/php-fig/13388408-c187-2738-7940-1084f473be5b%40seld.be.
>
> 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 php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CADqTB_gx8bysGMiQ5uep7jWE4XS8rCiz9%2BjhypjKWqOPJurZ5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.