[PHP-DEV] Wiki account request: ondrejmirtes

[Ondřej Mirtes]

The main reason is to be able to vote on PHP RFCs. I've created and have
been maintaining PHPStan, a popular open-source static analyser.

This submission is endorsed by Gabriel Caruso, a current release manager of
PHP 8.

My wiki.php.net username is: ondrejmirtes

Thank you.

Ondřej Mirtes

[PHP-DEV] Re: VCS Account Request: gandung

[PHP Group]

VCS Account Rejected: gandung rejected by kalle /o\

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] VCS Account Request: ondrejmirtes

[Kalle Sommer Nielsen]

Hi

Den lør. 11. jul. 2020 kl. 08.55 skrev Ondřej Mirtes :
> Oh, thank you. Should I fill out this form? https://wiki.php.net/?do=register

Yes that is the one. Someone with wiki admin karma needs to grant you
the right write permission once that is done. When you have
registered, then send off an email similar to the VCS from this thread
(state your wiki username and intentions) to the internals mailing
list.

> What email should I use for the "To which email address do you have to send 
> an email to now?" field?

This should be the internals mailing list address. The information to
fill out this spam challenge seems to have been lost sometime when we
upgraded the wiki software but never fixed.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: nusphere

[PHP Group]

VCS Account Rejected: nusphere rejected by kalle /o\

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] VCS Account Request: ondrejmirtes

[Kalle Sommer Nielsen]

Hi

Den lør. 11. jul. 2020 kl. 08.43 skrev Ondřej Mirtes :
>
> The main reason is to be able to vote on PHP RFCs. I\'ve created 
> PHPStan, a popular open-source static analyser.
>
> This submission is endorsed by Gabriel Caruso, a current release manager of 
> PHP 8.

You do not need a VCS account for that, but rather a Wiki account if
that is your sole purpose (similar to fatpot from Symfony).

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] VCS Account Request: ondrejmirtes

[Ondřej Mirtes]

The main reason is to be able to vote on PHP RFCs. I\'ve created PHPStan, 
a popular open-source static analyser.

This submission is endorsed by Gabriel Caruso, a current release manager of PHP 
8.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Named arguments

[Chuck Adams]

> Then the question becomes, do we rename parameters a lot? I doubt it's a
> large problem, and even then the variadics support makes it very easy to
> handle in a backwards compatible way. In addition libraries are always open
> to declare they don't consider named parameters as part of their API.

Python supports the notion of "keyword-only arguments".  If that was
supported, and the renamed argument had a default, an API could rename
parameters in a backward-compatible manner by introducing a kw-only
arg with the same name.   One could also consider an aliasing syntax
such that more than one keyword could correspond to a named argument.
Perhaps using an annotation?
--c

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Kalle Sommer Nielsen]

Hello Internals

The voting has closed with 44 for and 30 against. The RFC has not been
accepted as it did not meet the 2/3 requirement to be approved, thank
you to everyone for joining the discussions and turned out to vote.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Microsoft Support of PHP on Windows

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Fri, 10 Jul 2020 18:52:06 +0200):
>? Good Guy ? in php.windows (Fri, 10 Jul 2020 17:39:54 +0100):
>>On 10/07/2020 17:09, Trevor Holyoak via php-windows wrote:
>>> What does this mean? PHP 8 and forward will not be available for 
>>> Windows? Or is just won't be supported by Microsoft?
>>
>>It's means that Microsoft won't be spending time to create Windows 
>>binaries;  Jan Ehrhardt  is developing for private 
>>consumption so perhaps he should volunteer to upload them on the 
>>official website.  Alternatively, Microsoft could create a document for 
>>users to compile their own binaries using Visual Studio.  Personally, I 
>>would like to compile my own binaries but when I once tried it, it 
>>didn't work correctly because I didn't have all the extensions.  I just 
>>gave up but I would like to try again as Microsoft has given us enough 
>>time to prepare for the future.
>
>For many of the libs for extensions I am also dependent on
>https://windows.php.net/downloads/php-sdk/deps/
>Some of them I am also building them my self, using (sometimes patched)
>versions of the repo's on https://github.com/winlibs

And do not forget that the Windows build environment since PHP 7.2 is
also maintained by Microsoft:
https://github.com/microsoft/php-sdk-binary-tools

If they also stop supporting the build environment they will be really
shooting themselves in the foot.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Mark Randall]

On 10/07/2020 09:54, Nikita Popov wrote:

For me, dealing with PHP <-> PECL moves is an important part of adopting
namespaces in php-src, and I don't think the current proposal addresses
this issue sufficiently. (One way to address it would be to drop the PHP\
prefix, and use unvendored namespace names for php-src.)


There is another option that we reserve \Ext as well (not \PHP\Ext)

\PHP stays for engine level classes (core, collections etc)

\PHP\Annotations\JIT
\PHP\Tokenizer\Token
...

\Ext gets used for extensions, including bundled extensions. Anyone with 
good standing can request an \Ext (or could use one without requesting 
it, but it wouldn't be a BC break if an officially approved extension 
took its name).


\Ext\Mysqli\Connection
\Ext\Mysqli\Result
\Ext\Gd\Image
\Ext\Curl\Handle
...

This would also solve the long-problem of an ever-increasing number of 
classes and symbols placed into the root namespace.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Microsoft Support of PHP on Windows

[Jan Ehrhardt]

Chase Peeler in php.internals (Fri, 10 Jul 2020 12:43:00 -0400):
>My other fear is that if official support for windows is dropped, PHP
>itself will no longer be developed with windows in mind. One reason
>building it is pretty easy is because it was developed to be built on
>Windows. If that stops happening, then building it myself, with or without
>PGO, will become pretty much impossible as well.

Exactly my thoughts. In the long run it will mark the end of PHP on
Windows Server and on Windows Azure. Microsoft is shooting itself in the
foot.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Microsoft Support of PHP on Windows

[Jan Ehrhardt]

? Good Guy ? in php.windows (Fri, 10 Jul 2020 17:39:54 +0100):
>On 10/07/2020 17:09, Trevor Holyoak via php-windows wrote:
>> What does this mean? PHP 8 and forward will not be available for 
>> Windows? Or is just won't be supported by Microsoft?
>>
>>
>It's means that Microsoft won't be spending time to create Windows 
>binaries;  Jan Ehrhardt  is developing for private 
>consumption so perhaps he should volunteer to upload them on the 
>official website.  Alternatively, Microsoft could create a document for 
>users to compile their own binaries using Visual Studio.  Personally, I 
>would like to compile my own binaries but when I once tried it, it 
>didn't work correctly because I didn't have all the extensions.  I just 
>gave up but I would like to try again as Microsoft has given us enough 
>time to prepare for the future.

For many of the libs for extensions I am also dependent on
https://windows.php.net/downloads/php-sdk/deps/
Some of them I am also building them my self, using (sometimes patched)
versions of the repo's on https://github.com/winlibs

>I believe Jan also creates apache binaries on his official website 
>apachelounge.com but I might be wrong about it as I have seen the name 
>of Steffan or something like that often crops up on some forums.

Apachelounge is not my official website. I am just a 'member' that make
his builds available on https://www.apachelounge.com/viewforum.php?f=6
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Microsoft Support of PHP on Windows

[Chase Peeler]

On Fri, Jul 10, 2020 at 12:32 PM Jan Ehrhardt  wrote:

> ? Good Guy ? in php.internals (Fri, 10 Jul 2020 17:16:07 +0100):
> >On 10/07/2020 17:01, Jan Ehrhardt wrote:
> >> I am building PHP for Windows myself, but I know from the questions I am
> >> getting that a lot of corporate customers of Microsoft are running PHP
> >> on Windows Server 2016 or 2019. They are only allowed to use the
> >> official binaries that are supplied on windows.php.net or pecl.php.net.
> >> These corporate customers surely will not be amused by dropping
> >> Microsoft's support for PHP 8.
> >
> >Have you thought of uploading your binaries on php.net AFTER Microsoft
> >has quit the php support?  Windows binaries were very useful for
> >developing websites on windows system which is still the dominant
> >operating system though, web developers will adapt the workload on
> >ubuntu and Mint.  I still use Windows and I regularly  download Apache
> >from apachelounge and php from the official website.
>
> No. And I will not do that, because I do not want to be liable for any
> consequences of using my builds. I am providing them AS IS through links
> on Apachelounge: https://www.apachelounge.com/viewforum.php?f=6
>
> Many extensions I am building from git head, not from the official
> releases by the extension developers. Sometimes I have to patch them a
> little to get them building. The Solr extension for instance does not
> build yet for PHP 7.4.
>
> >> Besides that, SMB customers are often using Microsoft Azure for their
> >> Windows Server needs. Windows Azure will loose a lot of selling points
> >> without supported PHP binaries. A quick search on Azure marketplace
> >> revealed as well that some Azure partners will also be left in the cold:
> >>
> https://azuremarketplace.microsoft.com/en-us/marketplace/apps?search=windows+php
> >> Are the Azure Sales people already informed about your decision?
> >
> >I suspect Microsoft wants to market its own product called Blazor
> >
>
> Microsoft's future is in services like Azure. Development tools are much
> less important.
> --
> Jan
>
>
I work on an app that is almost 20 years old. It has always been hosted on
windows and a lot of the early development (which is still at the core of
the app) was very windows specific. Since this is an internal app used by
our company, and not something that is redistributed, the fact that it was
not OS agnostic wasn't an issue. With the development plans we have over
the next few years for our app, we don't have the luxury of being able to
devote time to making it run on a linux host. I'm OK if Microsoft decides
to not officially support it, but, I'm hoping something can be done to make
sure builds are still produced. I can (and have) built PHP myself on
windows. That actually isn't that hard. What makes the official builds
valuable is the inclusion of PGO.

My other fear is that if official support for windows is dropped, PHP
itself will no longer be developed with windows in mind. One reason
building it is pretty easy is because it was developed to be built on
Windows. If that stops happening, then building it myself, with or without
PGO, will become pretty much impossible as well.



> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Re: Microsoft Support of PHP on Windows

[Jan Ehrhardt]

? Good Guy ? in php.internals (Fri, 10 Jul 2020 17:16:07 +0100):
>On 10/07/2020 17:01, Jan Ehrhardt wrote:
>> I am building PHP for Windows myself, but I know from the questions I am
>> getting that a lot of corporate customers of Microsoft are running PHP
>> on Windows Server 2016 or 2019. They are only allowed to use the
>> official binaries that are supplied on windows.php.net or pecl.php.net.
>> These corporate customers surely will not be amused by dropping
>> Microsoft's support for PHP 8.
>
>Have you thought of uploading your binaries on php.net AFTER Microsoft 
>has quit the php support?  Windows binaries were very useful for 
>developing websites on windows system which is still the dominant 
>operating system though, web developers will adapt the workload on 
>ubuntu and Mint.  I still use Windows and I regularly  download Apache 
>from apachelounge and php from the official website.

No. And I will not do that, because I do not want to be liable for any
consequences of using my builds. I am providing them AS IS through links
on Apachelounge: https://www.apachelounge.com/viewforum.php?f=6

Many extensions I am building from git head, not from the official
releases by the extension developers. Sometimes I have to patch them a
little to get them building. The Solr extension for instance does not
build yet for PHP 7.4.

>> Besides that, SMB customers are often using Microsoft Azure for their
>> Windows Server needs. Windows Azure will loose a lot of selling points
>> without supported PHP binaries. A quick search on Azure marketplace
>> revealed as well that some Azure partners will also be left in the cold:
>> https://azuremarketplace.microsoft.com/en-us/marketplace/apps?search=windows+php
>> Are the Azure Sales people already informed about your decision?
>
>I suspect Microsoft wants to market its own product called Blazor 
>

Microsoft's future is in services like Azure. Development tools are much
less important.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Microsoft Support of PHP on Windows

[😉 Good Guy 😉]

On 10/07/2020 17:01, Jan Ehrhardt wrote:



I am building PHP for Windows myself, but I know from the questions I am
getting that a lot of corporate customers of Microsoft are running PHP
on Windows Server 2016 or 2019. They are only allowed to use the
official binaries that are supplied on windows.php.net or pecl.php.net.
These corporate customers surely will not be amused by dropping
Microsoft's support for PHP 8.



Have you thought of uploading your binaries on php.net AFTER Microsoft 
has quit the php support?  Windows binaries were very useful for 
developing websites on windows system which is still the dominant 
operating system though, web developers will adapt the workload on 
ubuntu and Mint.  I still use Windows and I regularly  download Apache 
from apachelounge and php from the official website.





Besides that, SMB customers are often using Microsoft Azure for their
Windows Server needs. Windows Azure will loose a lot of selling points
without supported PHP binaries. A quick search on Azure marketplace
revealed as well that some Azure partners will also be left in the cold:
https://azuremarketplace.microsoft.com/en-us/marketplace/apps?search=windows+php
Are the Azure Sales people already informed about your decision?


I suspect Microsoft wants to market its own product called Blazor 



--
With over 1.2 billion devices now running Windows 10, customer 
satisfaction is higher than any previous version of windows.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Microsoft Support of PHP on Windows

[Jan Ehrhardt]

Hi Dale,

"Dale Hirt via internals" in php.internals (Thu, 9 Jul 2020 18:48:44
+):
>My name is Dale Hirt and I am the project manager for PHP inside
>Microsoft.
>
>We currently support PHP with development and build efforts for PHP 7.3,
>and PHP 7.4.  In addition, we help with building PHP 7.2 on Windows
>when security fixes are required..
>
>However, as PHP 8.0 is now ramping up, we wanted to let the community
>know what our current plans are going forward.
>
>We know that the current cadence is 2 years from release for bug fixes,
>and 1 year after that for security fixes.  This means that PHP 7.2 will
>be going out of support in November.  PHP 7.3 will be going into
>security fix mode only in November.  PHP 7.4 will continue to have
>another year of bug fix and then one year of security fixes.  We are
>committed to maintaining development and building of PHP on Windows for
>7.2, 7.3 and 7.4 as long as they are officially supported.
>
>We are not, however, going to be supporting PHP for Windows in any
>capacity for version 8.0 and beyond.

This decision took me by surprise, to say the least. Microsoft's
involvement in developing (thanks, Anatol) and building PHP for Windows
was a huge boost for the PHP on Windows community.

I am building PHP for Windows myself, but I know from the questions I am
getting that a lot of corporate customers of Microsoft are running PHP
on Windows Server 2016 or 2019. They are only allowed to use the
official binaries that are supplied on windows.php.net or pecl.php.net.
These corporate customers surely will not be amused by dropping
Microsoft's support for PHP 8.

Besides that, SMB customers are often using Microsoft Azure for their
Windows Server needs. Windows Azure will loose a lot of selling points
without supported PHP binaries. A quick search on Azure marketplace
revealed as well that some Azure partners will also be left in the cold:
https://azuremarketplace.microsoft.com/en-us/marketplace/apps?search=windows+php
Are the Azure Sales people already informed about your decision?

Please rethink if your decision is really in line with Micrsoft's long
term policy.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

[Josh Bruce]

>>> 
>>> Frankly this is something subject to personal opinions and will change
>>> over time according to community shifts.
>>> 
>> 
>> Not sure what's "subject to personal opinions" in the objective bug exposed 
>> in the snippet above?
>> 
> 
> So there is a bug in a contrived code snippet therefore casting is a
> universal bad practice?
> It's at least a huge stretch. Some might say your bad practice was
> actually using `null` ;)


Good stuff - very helpful (and I’m grateful), thank you both.

This might actually be an interesting (possibly the) use case for what we’re 
talking about.

Updated: https://bit.ly/php-0001 

Added pre-roll section on perceived roadblocks as I’m experiencing one.

Added “Usage” section.

Renamed code sample header to “Rationale"

***

I didn’t have a chance to look at the code linked before and tend to agree:

1. Avoid null (I’m a bit extreme with this one)
2. I tend to avoid casting as well and, if the first is followed, a casting 
problem could become moot. PHP doesn’t like to halt - most primitives when cast 
to bool either effectively return the result of an empty check or a not-zero 
check - an object, if instantiated, is always true. __toBool would give us a 
way of saying it’s not true (it’s not empty, it's not zero, but it's not okay 
for some reason - maybe we need to do some follow-on configuration method 
calls…just making stuff up). :)

Cheers,
Josh

Re: [PHP-DEV] [VOTE] Named arguments

[Benjamin Eberlei]

On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta  wrote:

> Hi Nikita,
>
> I kept my "NO" stance here, as per discussion in
> https://externals.io/message/110004#110005, where I provided (in my
> opinion) good/safe alternatives to arrays as input parameters.
>

> The BC implications on this RFC still largely outweigh any advantages that
> it brings, from my perspective.
>

Are there alternatives to named parameters? Of course. Are they as simple?
Not really.

1. You can use an array, but array values cannot be typed, so you completly
loose typing of the language.
2. You can use an object with builder pattern, but that requires a lot of
code to write, and increases the mental capacity of understanding something
for developers.
3. your example of an api to convert named params to a sequence is not
discoverable, you don't know looking or using method A() that it comes with
an additional NamedParamsA() helper.

I see PHP as a language to get up and running quickly. So builder pattern
is really more an advanced approach, should be used by not many use-cases.
We have seen
arrays of $options and $params to no end in framework and library APIs,
with all their problems.

So named params are a real improvement that feels like supporting "the php
way(tm)".

Lastly we need to consider internal APIs, which are usually about adding
more parameters (htmlentities, json_decode, ...). These APIs are going to
stay and benefit hugely from named params.

Then the question becomes, do we rename parameters a lot? I doubt it's a
large problem, and even then the variadics support makes it very easy to
handle in a backwards compatible way. In addition libraries are always open
to declare they don't consider named parameters as part of their API.



> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Fri, Jul 10, 2020 at 10:42 AM Nikita Popov 
> wrote:
>
> > Hi internals,
> >
> > I have opened voting on the named arguments RFC:
> > https://wiki.php.net/rfc/named_params
> >
> > Voting will close on 2020-07-24.
> >
> > Regards,
> > Nikita
> >
>

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Dan Ackroyd]

On Thu, 9 Jul 2020 at 18:04, Larry Garfield  wrote:
>
> I've no idea what the rules are around new version numbers
> of RFCs that haven't been up for a vote yet.

I pretty strongly recommend people against re-using documents. If it's
going to change significantly, using a new doc makes it easier to see
it's a different idea.

Alternatively summarising the changes might be more appropriate for
smaller changes.

Larry wrote:
> Which guidelines in particular bug you, and why?

Just to note, my problem isn't just with the details, but to pick out a few.

RFC text:
> Any namespaced code provided by PHP-SRC will use a sub-namespace of \PHP.
> That is, no PHP\Foo class may be defined,

That seems like something that will have reasonable exceptions to.

RFC text:
> Classes that are part of a disable-able extension
> Eg, \PHP\Sodium.

I don't believe extensions should necessarily be under a PHP
namespace. Instead that should be thought about case-by-case. Also,
extensions can move from being one that can be disabled to not being
disable-able.

RFC text:
> Upgrade path for existing classes
> That is, a rename introduced in PHP 8.2 is not eligible to have its
> old name removed until at least 10.0.

The reason for having aliases is mostly to allow easier upgrading. i.e.

i) User code runs on version x.y of PHP.
ii) User code runs on version x.(y+1) of PHP.
iii) The user changes any use of old names on x.(y+1).
iv) Old names can be remove in version x.(y+2)

Keeping aliases of old names around for longer than that isn't that
useful. But again, this should be thought about case-by-case.

Rowan Tommins wrote:
> This is pure whataboutery; the idea that reading a few
> naming conventions will be such a burden that somebody
> would have no time to review a feature is frankly ridiculous.

That's getting pretty close to just name-calling.

It's fine to think that there is a problem here, and that adopting
this RFC is an appropriate solution to that problem.

But I think that there isn't really a problem to solve here, and that
even if there is, solving it through an RFC is worse than just
ignoring the problem.

This difference in approach possibly comes from a difference in
philosophy. aka I think we're both making sensible arguments, but
based on different values of what is important, and so coming to
different conclusions.

I've recommended the book Systemantics before:
https://en.wikipedia.org/wiki/Systemantics It has lots of very useful
advice about the counter-intuitive results that emerge from decisions.
And it's from that approach to systems design that I'm basing my
thinking. One of the most simplest pieces of advice it gives is:
"First rule of systems design: do without out one if possible"

And one of the few pieces of advice that I give to people, that I'm
pretty sure is right is: "Accept you're going to be wrong - Make it
easier to correct mistakes." which was part of a whole talk I gave at
DPC*

I don't think this RFC provides much benefit now, and I don't think it
makes it easier to name things in the future. In fact it makes things
more difficult as any exceptions to the rules laid down in this RFC
now become "DEVIATIONS FROM OUR ALREADY DECIDED RULES!!1!" rather than
things that can be thought about as code, coding standards, and
people's personal preferences all evolve.

cheers
Dan
Ack

* Video: https://www.youtube.com/watch?v=TS9BNa1MDW0
Slides: http://docs.basereality.com/GoodOrBad_DPC/

Apologies for the quality of my voice which made the presentation
quality not as high as I had hoped. But it does lead to the 2nd piece
of advice I'm pretty sure is correct, which is "wear a seatbelt so you
don't damage your spine in a car crash" which might seem kind of
obvious advice in retrospect.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Larry Garfield]

On Fri, Jul 10, 2020, at 3:54 AM, Nikita Popov wrote:
> On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield 
> wrote:
> 
> > On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> > > Greetings, Internalians.
> > >
> > > There has been much talk of the \PHP namespace of late, including one
> > > unsuccessful RFC.  In the discussion, the pushback broke down into two
> > > main camps:
> > >
> > > * We should never namespace anything ever.
> > > * We can namespace things but we need something more concrete than
> > > "RFCs can namespace things if they feel like it."
> > >
> > > I can't do much about the former, but the latter is a solvable problem.
> > >  To that end, Mark Randall and I have put together a new RFC on the
> > > topic, based on a fruitful discussion in Room 11 a few weeks ago to
> > > brainstorm what actual guidelines should be for what goes where.
> > >
> > > https://wiki.php.net/rfc/php_namespace_policy
> > >
> > > This proposal provides guidance to short circuit future subjective
> > > bikeshedding, while still leaving some wiggle room for case-by-case
> > > evaluation as needed.  That makes it different from prior attempts that
> > > did not provide clear guidance for future RFC authors.
> > >
> > > The specific guidelines offered may or may not appeal to you; those are
> > > open to discussion (within reason; we don't want to end up back in "do
> > > whatever" land as we know that won't help), but the more important
> > > point is that clear guidelines are provided.
> > >
> > > Also of note, although it uses existing code to demonstrate where
> > > classes *would* go under this plan it does not immediately move
> > > anything.  Those are left for future RFCs that would have to stand or
> > > fall on their own merit.  It also provides for a very long grace period
> > > for any such transitions to minimize disruption.
> > >
> > > The intent is to bring this proposal to a vote in time for 8.0's freeze
> > > one way or another, even though it's unlikely to have any impact on 8.0
> > > itself.  It's still a convenient deadline.
> > >
> > > *dons flame retardant suit*
> > >
> > > --
> > >   Larry Garfield
> > >   la...@garfieldtech.com
> >
> > This has reached the 2 week mark, but there's not been much discussion.
> > Anyone else want to weigh in?
> >
> > I want to give it a few more days and possibly revise it to include a Wiki
> > page as suggested, but probably will bring it to a vote within the next
> > week or so.
> >
> 
> Hey Larry,
> 
> As far as I can see, this RFC still doesn't address a primary concern from
> previous discussions: Extensions may get moved between PHP and PECL. The
> only discussion of this issue seems to be this bullet point:
> 
> > If a feature is removed from PHP-SRC (either to PECL or dropped entirely)
> its previously claimed component namespace remains reserved. It MAY be
> released by a subsequent RFC, following the standard RFC procedure, at
> least one minor version after the feature is removed. That delay is to
> minimize backward compatibility impact and allow userland code to migrate
> if appropriate.
> 
> To reiterate what the problem is: If the "PHP" namespace is only used by
> extensions bundled with php-src, then any time we import an extension from
> PECL, that means all the symbols in that extension must get renamed. This
> is disruptive to any existing users of the extension, who now have to deal
> with different symbol names depending on which PHP version they use.
> 
> Similarly, when extensions get unbundled and moved to PECL, my current
> reading of your RFC is that the extension would initially retain the PHP\
> namespace prefix, even though it is no longer vendored by PHP, but the
> extension namespace may get reused at a later point in time (which seems
> counter-productive to the goal of avoiding naming collisions).
> 
> For me, dealing with PHP <-> PECL moves is an important part of adopting
> namespaces in php-src, and I don't think the current proposal addresses
> this issue sufficiently. (One way to address it would be to drop the PHP\
> prefix, and use unvendored namespace names for php-src.)
> 
> Regards,
> Nikita

Hi Nikita.

I'm open to ways of handling that.  As written right now, yes, a hypothetical 
\PHP\Foo extension getting moved to PECL should get renamed to \MyCorp\Foo (or 
whatever).  However, it should be reasonably straightforward in most cases to 
include a user-space shim that does:

namespace \PHP\Fop {
  class Service extends \MyCorp\Foo\Service {}
}

(Or similar.)

And the same for an extension moving into core.

I don't really see any alternative that doesn't either:

1) Essentially boil down to that.
2) Allow arbitrary extensions to share a namespace with core code.

Eg, one could say that core-packaged extensions and PECL both use \Ext, and 
\PHP is reserved for the engine proper.  However, there's not a great deal in 
the engine proper, and stuff still sometimes moves from the engine to an 
extension or vice versa, so i

Re: [PHP-DEV][RFC] Saner numeric strings

[G. P. B.]

Good afternoon Internals,

I rewrote the RFC to improve clarity but the content is mostly identical
with one small change is that the warning change from 'Illegal offset type'
to 'String cast occurred' for string offsets such as '5.5' will be a
secondary
implementation vote as it adds some boilerplate code in the engine.

https://wiki.php.net/rfc/saner-numeric-strings

This email also serves as a reminder that voting is expected to start
next Monday (13th of July).

Best regards

George P. Banyard

Re: [PHP-DEV] [VOTE] Named arguments

[Rowan Tommins]

On Fri, 10 Jul 2020 at 11:24, Marco Pivetta  wrote:

> If "array" is all you have to pass on  as input, `fromArray` is what you
> can certainly use: that's useful when de-serializing from JSON input, DB,
> serialized state, etc.
>
> It certainly isn't meant to pass in the array via hand-crafted map: that's
> what other (additional) named ctors would be for.
>


As I said in my previous response, I think this comes down to an
unfortunate example - if what you actually have is an array, then yes,
fromArray makes sense.

One of the use cases for named parameters happens to look superficially
similar to that, because it can be worked around by first creating an
array, and then passing it somewhere. But the input you actually have is
not an array, it is a set of variables from multiple sources, or a set of
hard-coded parameters of different types that configure the functionality.

One aspect I'd like to highlight is that named parameters aren't just
useful for large numbers of individual parameters, but large numbers of
_valid combinations_.

For instance, with two optional parameters, you can quite easily have named
methods to omit one or the other:

function fromFoo($foo)
function fromBar($bar)
function fromFooAndBar($foo, $bar)

You could even skip the third method by having optional parameters on one
or both of the other two.

But this list would increase exponentially; with only three parameters, you
would need:

function fromFoo($foo)
function fromBar($bar)
function fromBaz($baz)
function fromFooAndBar($foo, $bar)
function fromFooAndBaz($foo, $baz)
function fromBarAndBaz($bar, $baz)
function fromFooAndBarAndBaz($foo, $bar, $baz)

Right now, there is no elegant way to combine these into one function
signature.

Named parameters are one solution, because they let you specify defaults
for all parameters:

function fromFooAndOrBarAndOrBaz($foo=42, $bar=true, $baz=[])

Another solution is parameter skipping, which was declined largely because
people preferred named params: https://wiki.php.net/rfc/skipparams

The only other alternative I know of is the builder pattern
($builder->withFoo($foo)->withBar($bar)->withBaz($baz)->build()), which at
least makes the boilerplate scale linearly rather than exponentially, but
is still going to require dozens of lines of code to achieve what named
parameters can do with one.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [VOTE] Named arguments

[Marco Pivetta]

Hey Rowan,



On Fri, Jul 10, 2020 at 12:11 PM Rowan Tommins 
wrote:

> On Fri, 10 Jul 2020 at 10:21, Marco Pivetta  wrote:
>
> > I kept my "NO" stance here, as per discussion in
> > https://externals.io/message/110004#110005, where I provided (in my
> > opinion) good/safe alternatives to arrays as input parameters.
> >
>
>
> For the record, I maintain my reaction from
> https://externals.io/message/110004#110010 that the example you give
> "cheats" by including a "fromArray" method which simply emulates named
> parameters, but without any assistance from the language would require a
> large amount of boiler-plate to do so.
>

If "array" is all you have to pass on  as input, `fromArray` is what you
can certainly use: that's useful when de-serializing from JSON input, DB,
serialized state, etc.

It certainly isn't meant to pass in the array via hand-crafted map: that's
what other (additional) named ctors would be for.


> Would you be more open to a version of the feature that was opt-in at the
> definition site?


Most certainly: as mentioned elsewhere (can't find it), having an attribute
to demarcate whether an API can be used via named arguments would make the
BC surface and BC promise explicit and clear.


> Then your example could swap the hand-rolled documentation
> and validation in "fromArray" for a fully typed signature in
> "fromNamedParams", and the only compatibility promises would be ones
> already made by "fromArray" anyway.


The idea of multiple named ctors is to keep BC compatibility whilst
allowing for multiple input formats that fit the current use-case.
Data format changes? New ctor! Not a problem, unless internal invariants
change massively.

For example, in event-sourcing, you can likely never update past data
(never, really!), so as you move forward, your de-serialization endpoints
may be appropriately versioned: a `MyEvent::fromSerializedData(array)` must
be designed to support all possible past representations of `MyEvent` (even
if no longer complying with current domain rules), whereas
`MyEvent::fromInput(PSR7Request)` can actively refuse invalid information
(context matters a lot).

```php
MyEvent::fromArray([
'hand' => 'crafted',
'set' => 'of',
'parameters' => 'is',
'certainly' => 'not',
'how' => 'this',
'is' => supposed',
'to' => 'be',
'used',
'and' => 'causes',
'only' => 'trouble'
]);
```

The above is just complexity, and a lot of moving parts to keep track of.
When coding with a defined data-set, you use `MyEvent::raise($with,
$relevant, $typed, $information, $only);`

I feel like I'm repeating myself though: this was already explained before.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [VOTE] Named arguments

[Rowan Tommins]

On Fri, 10 Jul 2020 at 10:21, Marco Pivetta  wrote:

> I kept my "NO" stance here, as per discussion in
> https://externals.io/message/110004#110005, where I provided (in my
> opinion) good/safe alternatives to arrays as input parameters.
>


For the record, I maintain my reaction from
https://externals.io/message/110004#110010 that the example you give
"cheats" by including a "fromArray" method which simply emulates named
parameters, but without any assistance from the language would require a
large amount of boiler-plate to do so.

Would you be more open to a version of the feature that was opt-in at the
definition site? Then your example could swap the hand-rolled documentation
and validation in "fromArray" for a fully typed signature in
"fromNamedParams", and the only compatibility promises would be ones
already made by "fromArray" anyway.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [VOTE] Named arguments

[Marco Pivetta]

Hi Nikita,

I kept my "NO" stance here, as per discussion in
https://externals.io/message/110004#110005, where I provided (in my
opinion) good/safe alternatives to arrays as input parameters.

The BC implications on this RFC still largely outweigh any advantages that
it brings, from my perspective.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Fri, Jul 10, 2020 at 10:42 AM Nikita Popov  wrote:

> Hi internals,
>
> I have opened voting on the named arguments RFC:
> https://wiki.php.net/rfc/named_params
>
> Voting will close on 2020-07-24.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Nikita Popov]

On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield 
wrote:

> On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> > Greetings, Internalians.
> >
> > There has been much talk of the \PHP namespace of late, including one
> > unsuccessful RFC.  In the discussion, the pushback broke down into two
> > main camps:
> >
> > * We should never namespace anything ever.
> > * We can namespace things but we need something more concrete than
> > "RFCs can namespace things if they feel like it."
> >
> > I can't do much about the former, but the latter is a solvable problem.
> >  To that end, Mark Randall and I have put together a new RFC on the
> > topic, based on a fruitful discussion in Room 11 a few weeks ago to
> > brainstorm what actual guidelines should be for what goes where.
> >
> > https://wiki.php.net/rfc/php_namespace_policy
> >
> > This proposal provides guidance to short circuit future subjective
> > bikeshedding, while still leaving some wiggle room for case-by-case
> > evaluation as needed.  That makes it different from prior attempts that
> > did not provide clear guidance for future RFC authors.
> >
> > The specific guidelines offered may or may not appeal to you; those are
> > open to discussion (within reason; we don't want to end up back in "do
> > whatever" land as we know that won't help), but the more important
> > point is that clear guidelines are provided.
> >
> > Also of note, although it uses existing code to demonstrate where
> > classes *would* go under this plan it does not immediately move
> > anything.  Those are left for future RFCs that would have to stand or
> > fall on their own merit.  It also provides for a very long grace period
> > for any such transitions to minimize disruption.
> >
> > The intent is to bring this proposal to a vote in time for 8.0's freeze
> > one way or another, even though it's unlikely to have any impact on 8.0
> > itself.  It's still a convenient deadline.
> >
> > *dons flame retardant suit*
> >
> > --
> >   Larry Garfield
> >   la...@garfieldtech.com
>
> This has reached the 2 week mark, but there's not been much discussion.
> Anyone else want to weigh in?
>
> I want to give it a few more days and possibly revise it to include a Wiki
> page as suggested, but probably will bring it to a vote within the next
> week or so.
>

Hey Larry,

As far as I can see, this RFC still doesn't address a primary concern from
previous discussions: Extensions may get moved between PHP and PECL. The
only discussion of this issue seems to be this bullet point:

> If a feature is removed from PHP-SRC (either to PECL or dropped entirely)
its previously claimed component namespace remains reserved. It MAY be
released by a subsequent RFC, following the standard RFC procedure, at
least one minor version after the feature is removed. That delay is to
minimize backward compatibility impact and allow userland code to migrate
if appropriate.

To reiterate what the problem is: If the "PHP" namespace is only used by
extensions bundled with php-src, then any time we import an extension from
PECL, that means all the symbols in that extension must get renamed. This
is disruptive to any existing users of the extension, who now have to deal
with different symbol names depending on which PHP version they use.

Similarly, when extensions get unbundled and moved to PECL, my current
reading of your RFC is that the extension would initially retain the PHP\
namespace prefix, even though it is no longer vendored by PHP, but the
extension namespace may get reused at a later point in time (which seems
counter-productive to the goal of avoiding naming collisions).

For me, dealing with PHP <-> PECL moves is an important part of adopting
namespaces in php-src, and I don't think the current proposal addresses
this issue sufficiently. (One way to address it would be to drop the PHP\
prefix, and use unvendored namespace names for php-src.)

Regards,
Nikita

[PHP-DEV] [VOTE] Named arguments

[Nikita Popov]

Hi internals,

I have opened voting on the named arguments RFC:
https://wiki.php.net/rfc/named_params

Voting will close on 2020-07-24.

Regards,
Nikita