[Internals] Reminder of CC nomination deadline

[Michael Cullum]

Hi all,

*Just a reminder that any CC nominations must be in by 23:59 UTC on 
Wednesday 7th December.*

I will also, around this time (when nominations close), post up a 
preliminary list of community members who are eligible to vote (in addition 
to all project representatives who have automatic voting rights) however 
this will not be complete and you can email the secretaries up until the 
14th December to ask if you are also eligible at which point we'll assess 
this and get back to you by the 16th December at the latest (we'll assess 
people in order of them asking us).

Voting begins on the 9th December.
Voting ends on the 23rd December.
Results are announced on the 24th December.
The new Core Committee comes into place on 25th December (Christmas Day).

Many thanks,
Michael

-- 
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/f8d94d71-0571-413a-969c-c1007475ae04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Larry Garfield]

I think you misunderstand.

PSR-6 *does* meet some developer needs.  PSR-16 is to optimize for a 
narrower-but-common use case.  They complement each other. That's fine.


Neither PSR-6 nor PSR-16 (nor PSR-7 for that matter) have 
implementations included in the spec or in the Packagist package. That's 
fine.  For basic implementations for which there's no reason for 
everyone to re-implement them (eg, Null cache), or portions therein, we 
offer -util packages.  It currently doesn't include a null 
implementation of PSR-6 or PSR-16.  Adding one would not be difficult 
and (speaking as the nominal maintainer of the cache-util package) would 
be very welcome.


--Larry Garfield

On 12/05/2016 01:12 PM, Устименко Александр wrote:

Larry, this approach is overcomplicated.

NullObject of any interface can be implemented in single simple way.

My PRs in OverComplexCache are still open and I dont' believe it would 
be merged.


So let complex things will be in complex PSRs and simple ones in simple.

As I understand current PSR/Cache is not meet developers needs, so 
that we have SimpleCache PSR here.






__
Alexander Ustimenko
+7 (952) 918-02-20

2016-12-06 1:02 GMT+07:00 Larry Garfield >:


We've decided since PSR-3 that such "stock implementations" do not
belong in the spec, but can live in -util libraries.  A NullCache
implementation of PSR-6 / PSR-16 would be very welcome for
cache-util.


On 12/05/2016 11:47 AM, Alexander Ustimenko wrote:

Another issue that we have now in current cache and cache-util is
complete missing of null-object.

In Psr/Log we have NullLogger, why we can't have NullCache?

There are situations, when we dont' know 100%, that there or here
we need cache. Or we know, that we need cache there, but for some
time we can live without it.

Cache could be an optional dependency. It's a bitter thought, but
it's a truth. So I suggest to add to Psr/Simple cache default
NullCache as just /dev/null or BlackWhole implementation.

Examples:

  * https://github.com/symfony/cache/blob/master/Adapter/NullAdapter.php

  * 
https://github.com/tedious/Stash/blob/master/src/Stash/Driver/BlackHole.php



Same as
https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.php




Use case

Cache as an optional injectable dependency. When class user not
provides it -- we take ready NullCache and use it.


среда, 16 ноября 2016 г., 21:22:20 UTC+7 пользователь Jordi
Boggiano написал:

Heya,

We believe PSR-16, Simple Cache, is now ready for final
review. As
coordinator, I hereby open the mandatory review period prior
to a formal
acceptance vote; voting will begin no earlier than December
1st, 2016.

Here are links to the most current version and its meta
document:


https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md





https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md





The package containing the interfaces is there:

https://github.com/php-fig/simplecache



The latest important changes to the interfaces can be found at:

https://github.com/php-fig/simplecache/releases/tag/0.2.0



And FWIW, Scrapbook already provides a PSR-16 implementation
in its
upcoming release:

https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php





Thanks for your time reviewing!

Cheers

-- 
Jordi Boggiano

@seldaek - http://seld.be



--
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/0807a451-4055-2645-f77f-2bd668222566%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12]

[Woody Gilk]

On Mon, Dec 5, 2016 at 12:30 PM, Larry Garfield 
wrote:

> I'd say the opposite: My brain is already trained to ignore the  as noise, so anything added to that line WOULD be missed.
>

Exactly this.

--
Woody Gilk
http://about.me/shadowhand

-- 
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/CAGOJM6%2B_i-VXu1jtu_kj8pO2TonyKKdGmddXCA-U8-n-7FG75g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Устименко Александр]

Larry, this approach is overcomplicated.

NullObject of any interface can be implemented in single simple way.

My PRs in OverComplexCache are still open and I dont' believe it would be
merged.

So let complex things will be in complex PSRs and simple ones in simple.

As I understand current PSR/Cache is not meet developers needs, so that we
have SimpleCache PSR here.





__
Alexander Ustimenko
+7 (952) 918-02-20

2016-12-06 1:02 GMT+07:00 Larry Garfield :

> We've decided since PSR-3 that such "stock implementations" do not belong
> in the spec, but can live in -util libraries.  A NullCache implementation
> of PSR-6 / PSR-16 would be very welcome for cache-util.
>
>
> On 12/05/2016 11:47 AM, Alexander Ustimenko wrote:
>
> Another issue that we have now in current cache and cache-util is complete
> missing of null-object.
>
> In Psr/Log we have NullLogger, why we can't have NullCache?
>
> There are situations, when we dont' know 100%, that there or here we need
> cache. Or we know, that we need cache there, but for some time we can live
> without it.
>
> Cache could be an optional dependency. It's a bitter thought, but it's a
> truth. So I suggest to add to Psr/Simple cache default NullCache as just
> /dev/null or BlackWhole implementation.
>
> Examples:
>
>- https://github.com/symfony/cache/blob/master/Adapter/NullAdapter.php
>- https://github.com/tedious/Stash/blob/master/src/Stash/
>Driver/BlackHole.php
>
> Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.php
>
> Use case
>
> Cache as an optional injectable dependency. When class user not provides
> it -- we take ready NullCache and use it.
>
> среда, 16 ноября 2016 г., 21:22:20 UTC+7 пользователь Jordi Boggiano
> написал:
>>
>> Heya,
>>
>> We believe PSR-16, Simple Cache, is now ready for final review. As
>> coordinator, I hereby open the mandatory review period prior to a formal
>> acceptance vote; voting will begin no earlier than December 1st, 2016.
>>
>> Here are links to the most current version and its meta document:
>>
>> https://github.com/php-fig/fig-standards/blob/1cf169c6674764
>> 0c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>>
>> https://github.com/php-fig/fig-standards/blob/1cf169c6674764
>> 0c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md
>>
>>
>> The package containing the interfaces is there:
>>
>> https://github.com/php-fig/simplecache
>>
>>
>> The latest important changes to the interfaces can be found at:
>>
>> https://github.com/php-fig/simplecache/releases/tag/0.2.0
>>
>>
>> And FWIW, Scrapbook already provides a PSR-16 implementation in its
>> upcoming release:
>> https://github.com/matthiasmullie/scrapbook/blob/master/src/
>> Psr16/SimpleCache.php
>>
>>
>> Thanks for your time reviewing!
>>
>> Cheers
>>
>> --
>> Jordi Boggiano
>> @seldaek - http://seld.be
>>
> --
> 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/b67406ac-5227-456d-a7c3-f65523bf527d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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/614af58c-322c-2620-7a49-51e9eac15cb4%40garfieldtech.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/CANYF1s83AQpapNamiwANAg2%2BiVCP9zf4o6eo49swYnh7WJ5Fbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12]

[Larry Garfield]

On 12/05/2016 12:03 PM, Jordi Boggiano wrote:

On 05/12/2016 17:55, Sara Golemon wrote:

I was initially on the "keep it on the same line" side, largely as
that's how I've been writing it since before 7.0 was released, but the
arguments on this thread have convinced me that as recommended styles
go, separate lines is better.


I am still not really sold as I have never seen declare(encoding) 
being used and ticks' only use (AFAIK, and especially as far as I've 
seen in the wild) was signals handling and that is not needed anymore 
in 7.1+.


the one liner!


Cheers


I'd say the opposite: My brain is already trained to ignore the line as noise, so anything added to that line WOULD be missed.


We also need to bear in mind implementation needs.  It's going to be 
much easier for the spec definition to define "these things, with one 
line between them" than "these things, with one line between them, 
except in this case where it's inlined, or this case where there's no 
blank line, or this case..."  And it's going to be much, much easier for 
linters and auto-formatters to handle, too, I'd imagine.


I don't have a strong feeling about whether the file docblock or the 
declares should come first.  But I do favor the status quo of "one line 
between each set of things" as it's less complex to define, read, and 
parse than the alternatives.


--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 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/76d4eee4-9e46-7834-96d0-ac885ac072b6%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12]

[Jordi Boggiano]

On 05/12/2016 17:55, Sara Golemon wrote:

I was initially on the "keep it on the same line" side, largely as
that's how I've been writing it since before 7.0 was released, but the
arguments on this thread have convinced me that as recommended styles
go, separate lines is better.


I am still not really sold as I have never seen declare(encoding) being 
used and ticks' only use (AFAIK, and especially as far as I've seen in 
the wild) was signals handling and that is not needed anymore in 7.1+.


the one liner!


Cheers

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

--
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/e7a823db-d5a7-046d-5430-767f5c7b836b%40seld.be.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Larry Garfield]

We've decided since PSR-3 that such "stock implementations" do not 
belong in the spec, but can live in -util libraries.  A NullCache 
implementation of PSR-6 / PSR-16 would be very welcome for cache-util.


On 12/05/2016 11:47 AM, Alexander Ustimenko wrote:
Another issue that we have now in current cache and cache-util is 
complete missing of null-object.


In Psr/Log we have NullLogger, why we can't have NullCache?

There are situations, when we dont' know 100%, that there or here we 
need cache. Or we know, that we need cache there, but for some time we 
can live without it.


Cache could be an optional dependency. It's a bitter thought, but it's 
a truth. So I suggest to add to Psr/Simple cache default NullCache as 
just /dev/null or BlackWhole implementation.


Examples:

  * https://github.com/symfony/cache/blob/master/Adapter/NullAdapter.php
  * https://github.com/tedious/Stash/blob/master/src/Stash/Driver/BlackHole.php

Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.php



Use case

Cache as an optional injectable dependency. When class user not 
provides it -- we take ready NullCache and use it.



среда, 16 ноября 2016 г., 21:22:20 UTC+7 пользователь Jordi Boggiano 
написал:


Heya,

We believe PSR-16, Simple Cache, is now ready for final review. As
coordinator, I hereby open the mandatory review period prior to a
formal
acceptance vote; voting will begin no earlier than December 1st,
2016.

Here are links to the most current version and its meta document:


https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md





https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md





The package containing the interfaces is there:

https://github.com/php-fig/simplecache



The latest important changes to the interfaces can be found at:

https://github.com/php-fig/simplecache/releases/tag/0.2.0



And FWIW, Scrapbook already provides a PSR-16 implementation in its
upcoming release:

https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php





Thanks for your time reviewing!

Cheers

-- 
Jordi Boggiano

@seldaek - http://seld.be

--
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/b67406ac-5227-456d-a7c3-f65523bf527d%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/614af58c-322c-2620-7a49-51e9eac15cb4%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Alexander Ustimenko]

Another issue that we have now in current cache and cache-util is complete 
missing of null-object.

In Psr/Log we have NullLogger, why we can't have NullCache?

There are situations, when we dont' know 100%, that there or here we need 
cache. Or we know, that we need cache there, but for some time we can live 
without it.

Cache could be an optional dependency. It's a bitter thought, but it's a 
truth. So I suggest to add to Psr/Simple cache default NullCache as just 
/dev/null or BlackWhole implementation.

Examples:

   - https://github.com/symfony/cache/blob/master/Adapter/NullAdapter.php
   - 
   https://github.com/tedious/Stash/blob/master/src/Stash/Driver/BlackHole.php

Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.php

Use case

Cache as an optional injectable dependency. When class user not provides it 
-- we take ready NullCache and use it.

среда, 16 ноября 2016 г., 21:22:20 UTC+7 пользователь Jordi Boggiano 
написал:
>
> Heya, 
>
> We believe PSR-16, Simple Cache, is now ready for final review. As 
> coordinator, I hereby open the mandatory review period prior to a formal 
> acceptance vote; voting will begin no earlier than December 1st, 2016. 
>
> Here are links to the most current version and its meta document: 
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>  
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md
>  
>
>
> The package containing the interfaces is there: 
>
> https://github.com/php-fig/simplecache 
>
>
> The latest important changes to the interfaces can be found at: 
>
> https://github.com/php-fig/simplecache/releases/tag/0.2.0 
>
>
> And FWIW, Scrapbook already provides a PSR-16 implementation in its 
> upcoming release: 
>
> https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php
>  
>
>
> Thanks for your time reviewing! 
>
> Cheers 
>
> -- 
> Jordi Boggiano 
> @seldaek - http://seld.be 
>

-- 
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/b67406ac-5227-456d-a7c3-f65523bf527d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Alexander Ustimenko]

Hi Jordi!

I will reply one message per issue.

First that I see in current CacheInterface is `blaMultiple` methods, that 
seems strange and far-fetched in *simple* cache interface.

Why do I need to think about blaMultiple when I have `CacheInterface 
$cache`? It's a simlpe cache with get/set and more complex usage patterns 
are already in current Cache PSR.

So I suggest to remote remove blaMultiple from CacheInterface into 
MultipleCacheInterface. Or just remove it from SimpleCache at all.

среда, 16 ноября 2016 г., 21:22:20 UTC+7 пользователь Jordi Boggiano 
написал:
>
> Heya, 
>
> We believe PSR-16, Simple Cache, is now ready for final review. As 
> coordinator, I hereby open the mandatory review period prior to a formal 
> acceptance vote; voting will begin no earlier than December 1st, 2016. 
>
> Here are links to the most current version and its meta document: 
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>  
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md
>  
>
>
> The package containing the interfaces is there: 
>
> https://github.com/php-fig/simplecache 
>
>
> The latest important changes to the interfaces can be found at: 
>
> https://github.com/php-fig/simplecache/releases/tag/0.2.0 
>
>
> And FWIW, Scrapbook already provides a PSR-16 implementation in its 
> upcoming release: 
>
> https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php
>  
>
>
> Thanks for your time reviewing! 
>
> Cheers 
>
> -- 
> Jordi Boggiano 
> @seldaek - http://seld.be 
>

-- 
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/3a529209-5409-47fe-9bb4-7e2bd05bb182%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12]

[Michael Sheakoski]

Sara, I also favor alphabetical order, but when I was making my example, 
PhpStorm complained when strict_types came after encoding. Upon further 
research, it looks like PHP doesn't care about the order of declare() 
statements, only that they come before other non-declare() statements.


On Monday, December 5, 2016 at 11:55:02 AM UTC-5, Sara Golemon wrote:
>
> I was initially on the "keep it on the same line" side, largely as that's 
> how I've been writing it since before 7.0 was released, but the arguments 
> on this thread have convinced me that as recommended styles go, separate 
> lines is better.
>  
> The one very minor item I would suggest to add to that recommendation is 
> that when multiple declare directives are present, they should prefer 
> alphabetical ordering.  e.g. 'encoding' comes before 'strict_types', which 
> in turn comes before 'ticks'.  Similarly with include/use directives.  This 
> may be outside the scope of this discussion though so feel free to ignore 
> 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...@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/1bd215cc-e91b-45ec-9d54-d6702b433d30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12]

[Sara Golemon]

I was initially on the "keep it on the same line" side, largely as that's 
how I've been writing it since before 7.0 was released, but the arguments 
on this thread have convinced me that as recommended styles go, separate 
lines is better.
 
The one very minor item I would suggest to add to that recommendation is 
that when multiple declare directives are present, they should prefer 
alphabetical ordering.  e.g. 'encoding' comes before 'strict_types', which 
in turn comes before 'ticks'.  Similarly with include/use directives.  This 
may be outside the scope of this discussion though so feel free to ignore 
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...@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/c9cdd36d-ff36-4aa8-b4bc-1e3cd1018f5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC Nomination Request] Michael Heap

[Michael Heap]

To all FIG project representatives:

Like those who have posted before me, I too am writing to the list today to 
request a nomination to the FIG 3.0 Core Committee. I'm asking for a 
nomination on the mailing list as I do not have a strong personal 
relationship with any voting members.

For the many of you that don't know me, allow me to introduce myself - I'm 
Michael, a polyglot developer based in the UK. I've been writing code 
professionally for about a decade for all kinds of clients, from tiny one 
person companies to code that processes 100% of the Facebook firehose 
(see http://blog.datasift.com/2015/03/10/datasift-and-facebook-partnership/). 
Over the last few years I've really doubled down on conference speaking, 
presenting on topics as varied as application profiling to deploying 
WordPress (see https://michaelheap.com/talks/). I've also made some 
contributions to open source projects, but not as many as I'd like.

So, why vote for me as a member of the core committee? The answer lies in 
what I'm not, rather than what I am. I'm not deeply involved in various 
open source projects. I've not been vocal on this list (though I have read 
this and internals for years). In short, I'm not your typical FIG member. 
Instead, I've spent time working with companies that want to standardise 
and adopt new technology, but don't know where to start. These companies 
cover both ends of the spectrum - from monolithic projects to dozens of 
microservices, from deploying with FTP to immutable infrastructure. The one 
thing they all have in common is that they want to adopt the standards that 
the FIG are producing - both to improve their own code base and to reduce 
the learning curve for new hires. By joining the core committee, I believe 
that I can help by providing practical input that will help everyday 
companies adopt new PSRs.

If you ask those that I've worked with to describe my working style, they'd 
tell you that it's "strong beliefs, loosely held". The end result, whilst 
important, isn't the only thing that we should consider. The journey 
towards any solution is one of the most important parts. Making sure that 
every edge case has been considered (even if it's been considered and 
discounted) is imperative to arrving at solutions that are robust and 
applicable for all.

Thanks for reading this far, and I'm more than happy to answer any 
questions that you may have.

Cheers, Michael



-- 
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/89f794b9-d3f5-4d5e-92d3-d0389aaf2d0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12]

[Rudolph Gottesheim]

So the section will be updated to enforce one specific style? I still would 
have liked the same-line style better then the other, but I think any 
recommendation is better than none at all.

Am Montag, 5. Dezember 2016 00:27:51 UTC+1 schrieb Korvin Szanto:
>
> Hi All,
> This is something that we polled with the survey. At this point we are 
> still waiting for some member replies but I can tell you that by and large 
> things were pretty unanimous. As far as this specific issue, it looks like 
> 94% responded with no objections and 2/3rds of responses preferred the 
> status quo of declare on the next line. Because of that data and because of 
> the subjective nature of this issue, we're probably unlikely to take 
> further discussion into serious consideration unless there's a new argument 
> that we haven't discussed before.
>
> Thank you all for paying such close attention, I really appreciate you 
> keeping the discussion and excitement going while we work to get this 
> wrapped up. I plan to collect the remaining member replies and post some 
> results with a plan moving forward sometime this week.
>
> Best wishes,
> Korvin
>
> On Sun, Dec 4, 2016 at 2:52 PM Michael Sheakoski  > wrote:
>
>> Michael Mayer, I think your suggestion sounds like a good idea. My main 
>> point originally was to keep the declare() statements close to the > because they change how the language works. An example of what your 
>> suggestion might look like:
>>
>> > declare(strict_types=1);
>> declare(encoding='ISO-8859-1');
>> declare(ticks=1);
>>
>> /**
>>  * Hello. I am a file-level DocBlock.
>>  * I hope you are enjoying the example.
>>  */
>>
>> use Foo\Bar\Baz;
>> use InvalidArgumentException;
>>
>> /**
>>  * Class Thing is a wonderful class,
>>  * the best class.
>>  */
>> class Thing extends Baz
>> {
>> ...
>> }
>>
>> I left the > they're closely related, but a blank line between other blocks should still 
>> remain. What does everyone think?
>>
>> -Michael
>>
>>
>> On Sunday, December 4, 2016 at 2:01:09 PM UTC-5, Michael Mayer wrote:
>>>
>>> But we already have today:
>>>
>>> declare(encoding='ISO-8859-1');
>>> declare(ticks=1);
>>>
>>> And for both holds: *the file is running a special mode of PHP, not the 
>>> usual one.*
>>> – Should I write all of them in the first line, or is strict_types such 
>>> special?
>>> – And, if so, what makes it such special?
>>>
>>> Furthermore, at least for ticks, I see valid multi-line use cases:
>>>
>>> Block declare statements are allowed and MUST be formatted as below. 
 Note position of braces and spacing:
 declare(ticks=1) {
 //some code
 }

>>>
>>> Moreover:
>>>
>>>  Each block MUST be in the order listed below, although blocks that are 
 not relevant may be omitted.

- File-level docblock.


- One or more declare statements.


- The namespace declaration of the file.


- …

 Hence, I know where they are, and *I don't need to scan around doc 
>>> blocks and namespace declarations.*
>>>
>>> Sorry, but I cannot see at the moment, how a consistent style 
>>> recommendation may look like with that change.
>>> However, I understand that declare statements are more important than 
>>> the *File-level docblock –* thus why
>>> not move them to the top of the list instead?
>>>
>>> Best regards,
>>> Michael Mayer
>>>
>>> Am Sonntag, 4. Dezember 2016 18:50:55 UTC+1 schrieb Jordi Boggiano:

 I'm with Rudolph on this one, as I replied in the survey that was sent 
 a 
 while back. IMO it should be on the first line to make sure it's 
 visible 
 and not missed because it is such a meaningful line. It completely 
 changes the way the engine works, it's not php anymore, but strict php, 
 and you better be aware of it. 

 As for the fear that more flags will be added, well of course it's 
 possible but IMO unlikely. In any case we can revisit that topic if 
 needed when we have more flags, I don't think we need to set the rule 
 of 
 today based on future unknowns. 

 Cheers 

 On 04/12/2016 14:48, Michael Mayer wrote: 
 > I disagree too. 
 > 
 > What, if PHP8 will introduce a new execution directive and PHP9 as 
 well 
 > etc. And all of these are considered as good practice. 
 > Where should I put them? All in the same line? 
 > 
 > | 
 > >>> > 
 declare(strict_types=1);declare(php8_directive=1);declare(php9_directive=1);
  

 > 
 > useFoo\Bar\Baz; 
 > 
 > classThingextendsBaz 
 > { 
 > } 
 > | 
 > 
 > Ewww! 
 > 
 > Best regards, 
 > Michael Mayer 
 > 
 > -- 
 > 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

Re: PSR Idea: Messaging API

[Maksim Kotlyar]

We at FormaPro open sourced our messaging solution. It is based on JMS like 
interfaces https://github.com/formapro/fms. We tried to keep it as close as 
possible to JMS. Could be used as foundation for the standard. 

there are two 
implementations: https://github.com/formapro/amqp-ext-transport, 
https://github.com/formapro/stomp-transport

Here's the 
doc: https://github.com/formapro/message-queue-dev/blob/master/docs/index.md

On Monday, March 28, 2016 at 6:38:20 PM UTC+3, Larry Garfield wrote:
>
> On 3/28/16 4:53 AM, Márk Sági-Kazár wrote: 
> > Hi all, 
> > 
> > For quite a few years now, the world goes towards distributed systems. 
> > It became very important for these systems to communicate with each 
> > other in an efficient way. 
> > 
> > Also, with domain driven design, CQS, CQRS, etc it became important to 
> > exchange messages within the application as well. 
> > 
> > Whether the message's destination is another software component or 
> > another external service, it doesn't matter. 
> > 
> > Therefore, I am suggesting to create a PSR for such messaging API. 
> > 
> > Java's JMS is quite impressing from my point of view: 
> > https://en.wikipedia.org/wiki/Java_Message_Service 
> > (although I am not sure whether it can easily be adopted to PHP) 
> > 
> > Existing PHP examples for some kind of messaging: 
> > Bernard also does some sort of messaging: 
> > https://github.com/bernardphp/bernard 
> > Simple Bus: https://github.com/SimpleBus/ 
> > Prooph: https://github.com/prooph 
> > 
> > What do you think? I have a fear that this topic is too big to be 
> > standardized, so I would really love to hear any ideas on this topic. 
> > 
> > Kind regards, 
> > Mark 
>
> My initial thought is that "message passing" is indeed too big of a 
> topic for a single standard to address.  It's too general, much like 
> "DI" or "ORM".  A specific, focused subset of messages, maybe.  Eg, 
> would queue services be standardizable?  (Common interface for 
> Beanstalk, Amazon SQS, *MQ, etc.)  Not being an expert in that area I've 
> no idea, but that's more the level that a good PSR would work, IMO. 
>
> Focus on "as a consumer of some other service, can I abstract how I talk 
> to that service?" 
>
>
> -- 
> --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 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/7793b292-e5fe-412e-8b16-c86af029c57f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.