[PHP-DEV] [Discussion] `ifset()` language construct

[Kosit Supanyo]

Hi Internals

I don't have permission to create RFCs but I would like to propose/discuss
new language construct called `ifset()` which is syntactic sugar to null
coalescing operator with rhs value `null`. The goal of this proposal is
similar to Andrea Fauld's proposal (
https://wiki.php.net/rfc/unary_null_coalescing_operator), and the chosen
keyword is similar to historical discussion `ifsetor()`. Here's an example.

$result = $a ?? null;
vs
$result = ifset($a);

$result = $a ?? $b ?? $c ?? $d ?? $e ?? null;
vs
$result = ifset($a, $b, $c, $d, $e);

As you can see `ifset()` does not make code much shorter but the main goal
of this syntax is expressiveness not shortness.

someFunc(
$arg1,
$arg2,
$longVariableName1 ?? $longVariableName2 ?? $longVariableName3 ?? null,
$arg4,
);

vs

someFunc(
$arg1,
$arg2,
ifset(
$longVariableName1,
$longVariableName2,
$longVariableName3,
),
$arg4,
);

I know that this proposal is highly unlikely to be accepted because it just
does same as `??` but in different way and it introduces new keyword (we
don't have any new keyword since `yield` in 5.5) and, furthermore, I did
search through github and found some projects using `ifset` as function
name (https://github.com/search?l=PHP=ifset=Code).

Here's the patch: https://github.com/webdevxp/php-src

Cheers

Re: [PHP-DEV] Defining the PHP Group

[Kalle Sommer Nielsen]

Hi Joe

Den søn. 15. sep. 2019 kl. 08.48 skrev Joe Watkins :
>
> Morning internals,
>
> There is confusion among the community, and contained in the documented
> history of PHP on the wider internet.
>
> The Wikipedia states that PHP is developed by the PHP Group, in saying this
> it is (must be) referring to internals as a whole, but our own
> documentation names members of the group - who aren't even around mostly.
>
> I think we need to clarify what exactly is the purpose of the PHP Group
> today, does anyone want to attempt to do that ?

This is speculation/my interpretation, so take this with a grain of
salt; I think The PHP Group was the project governance back in the
day, but with PHP's ever so vastness and expansion, new developers
come in, old developers go all the time, I don't think this ever got
to be what it was meant to be. Now a days it mostly seems to serve as
a legacy of the past.

Given the recent clarification from Rasmus, I do not think the name
has any meaning anymore besides being a fancy name that holds the
copyright, whereas the copyright probably should be updated to be:
"Copyright (C) The PHP Project", on the PHP.net website, license et
al. Besides this I cannot think of a place where I have seen a
definition of "The PHP Group" or seen it active besides its recent
mention of being an "authoritative" power (which clearly is not the
case as there is no legal ramification to hold this statement true).

(I picked "The PHP Project" over "The PHP Development Team" which is
also commonly used to include everyone who contributes time and
resources to PHP).

> Whatever it's purpose, if it has one, we need to make clear at this time
> that there are no vetos: As Rasmus clarified, PHP is driven by the people
> who write PHP: No member of any group or company, historical or otherwise,
> has any veto powers, they cannot, and they must not behave as if they do.
>
> I would like to update the introduction to the Voting RFC:
>
> The development of PHP is community driven by the RFC process described in
> this document. Anyone may initiate an RFC for any subject. At the end of
> the RFC process a vote is held among PHP developers to determine if the
> proposal is to be accepted.
>
> Should a proposal be accepted, the developers of PHP are committed to
> making the change.
>
> In some circumstances, merging an implementation into the source code of
> PHP may be delayed because of shortcomings in that implementation. In these
> cases, resolution of these shortcomings is the responsibility of the
> proposer.
>
> Should a proposal be accepted without an implementation, it is the
> responsibility of the proposer to provide one.
>
> Does anyone object to any of those words ?
>
> Do we need to vote on changing the introduction (I'm happy to start an rfc
> for this, if necessary) ?

I got no objection to adding it, but perhaps an RFC should be more in
the direction of a "Mission statement" of sorts, stating what the
project is, what our goals are, who steers the direction etc. This
could be a decent start to sorting out the strings.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

[PHP-DEV] Features related to Object Initializers

[Mike Schinkel]

> On Sep 14, 2019, at 4:47 PM, Rowan Tommins  wrote:
> I think that's only true because you've actually proposed a number of related 
> but different features.


See my other email to the list asking about what is in-bounds and what it 
out-of-bounds regarding RFC discussion.

I seemed logical to me to discuss how to improve an RFC, but maybe what you are 
saying is that we are only suppose to discuss RFC as it exists today in order 
to give a black and white, up or down vote on the entire RFC?  That seems 
counter-productive, but if that is the case and others concur then so be it.

So to be safe, I have started a new thread for this reply.


> other than initializing additional objects. And if these are additional 
> objects, then named parameters work just as well in the nested case as in the 
> non-nested one:
> 
> $car = new Car(
>   yearOfProduction => 1975,
>   vin => "12345678",
>   engine => new Engine(
>  type => "v8",
>  capacity => "270ci",
>   ),
> );


Obviously that can be done. However, in practice I often see arrays used 
instead of objects because it is so much easier. I doubt that this enhancement 
will remove the other reasons developers might continue to use arrays instead:

1. Arrays do not require a developer to name a class, where naming is one of 
the 2 or 3 hardest parts of computer science

2. Anonymous classes  are more tedious than just creating an array literal so I 
see most PHP developers using arrays instead.

3. Defining a class in PHP best practice means creating another file that is 
physically separate from the code for said class that must also be 
(auto-)loaded.

So are you arguing that in all cases where people want structured information 
they should create a new class, and if so, what about the three points I just 
made?


> This already works:
> 
> $stats = new class {
>var int $total   = 0;
>var int $mean= 0;
>var int $average = 0;
>var int $median  = 0;
> };
> 
> What doesn't currently work is using variables from lexical scope in the 
> definition:
> 
> $stats = new class {
>var int $total   = $a + $b;
>var int $mean= $c;
>var int $average = $d;
>var int $median  = $e;
> };


In the USA we have a saying:

"Besides that Mrs. Lincoln, how was the play?"

But for those  unfamiliar with US history leading up to the revolutionary war, 
what it means in this context is:

"Yes your point is correct, but ignores the most relevant concern."

> However, initializer syntax on its own doesn't solve this, because you 
> wouldn't be able to specify the types for the properties; just combining 
> existing syntax with initializers would give something like this:
> 
> $stats = new class {
>var int $total;
>var int $mean;
>var int $average;
>var int $median;
> }{
>total => $a + $a,
>mean => $c,
>average => $d,
>median => $e
> }

You probably missed that I wrote that I was using an alternate initialization 
syntax that I would propose instead, which I will illustrate again below. If we 
allow typing i

$stats = new class {
   int $total   = $a + $b;
   int $mean= $c;
   int $average = $d;
   int $median  = $e;
};


> You could certainly make the syntax of initializers and anonymous class 
> definitions similar, but they're not really the same thing.

Noted.  To me them being the same or not is not as concerning as the outcome of 
the features that may become available in userland.

> The QueryBuilder class in this example has not benefited from object 
> initializers at all; passing the Query object rather than separate parameters 
> is a refactoring you can (and probably should) do right now.

But many PHP developers are unlikely to do that refactoring initially. They 
will just fall back to using arrays, because they are easy, comfortable, less 
pedantic and less tedious to use.

I would far prefer to have find developers using untyped anonymous objects than 
arrays because the former is much easier to refactor to better code than the 
latter, and this is painfully obvious to me because of numerous PHP codebases I 
have been brought in to fix.

Would it be better to introduce a simple-to-use object instantiation syntax so 
userland PHP developers would start using it, or would it be better to leave 
them only one easy option such that they continue to use arrays?

> As before, the definition of the class itself is simpler, but I think a 
> short-hand syntax for constructors would be a better compromise than a syntax 
> that only worked with public properties and parameterless constructors.

My problem with short-hand syntax for constructors is they only work in context 
of constructors.  

What about other functions or methods that userland PHP developers currently 
pass structured arrays too? 

> This is an interesting additional proposal, which I admit would be awkward to 
> implement without initializer syntax. One limitation is that it only works if 
> dependencies are declared as concrete 

Re: [PHP-DEV] Changing PECL signup flow.

[Johannes Schlüter]

On Sun, 2019-09-15 at 18:11 +0100, Dan Ackroyd wrote:
> HI internals,
> 
> Currently, it is quite difficult to signup to get a PECL account.
> 
> We have a somewhat deliberately obtuse form to signup through, which
> then needs to be manually approved by someone with the appropriate
> karma.

I think we should clarify what PECL actually is. Classically, in the
pre-GitHub days, PECL was not only a distribution channel for PHP
extensions, but part of the PHP project. This meant that "we" (php.net
community) as owners of the content could handle passing maintenance
over to other people, had the commit list for doing passive code
reviews and could do mass edits as in 
http://svn.php.net/viewvc?view=revision=297236 on API changes.

PECL was also incubator where extensions could be developed before
being merged. By already being on php.net this was easy from license
and similar things. Nowadays we're less likely to bundle extensions,
but from php-src point of view PECL is the graveyard where extensions
go for their final rest.

With splitting from the single svn repo to multiple git repos and with
rising popularity of GitHub this changes and PECL merely becomes a
distribution platform ... 

However we recently deprecated the distribution tool (pecl installer
aka. pear installer)  without having a replacement. Without such a tool
the need for a central distribution site goes away and common code
ownership already went away in practice.

Also many recent extensions don't use our Docbook based docs for their
documentation but use Markdown or something in the GitHub repo.

Also mind that in the current model we have global package names with
no vendor prefix or similar. Thus names could conflict. A review by a
"trusted" person therefore could be worthwhile.

Thus questions are:

- What is PECL? (directory? platform? community? incubator? siberia?)
- What is the extension install process in future? (clone repo and go
from there? Right now `pecl install foo` will go to our server, fetch
the tgz with pregenerated autoconf configure)
- how do we transition old packages to new way (whatever that new way
is)


> # Change voting rights
> 
> Getting a pecl account would explicitly no longer give or require a
> php.net account, and wouldn't confer voting karma. To be clear, I am
> actually unsure whether it's intended for people with PECL accounts
> should get voting karma; I know some people did but apparently not
> all
> have.

PECK account doesn't give voting rights. But in the old model users
registered on PECL and on php.net at the same time to put the code into
PHP's VCS (CVS, svn, git), add docs and use bugs.php.net (see the
checkbox "do you need VCS account?) that account is separated and
requires independent approval via master.php.net.

Before voting impact was low ... a rogue contributor had little writing
permission in VCS and worst they could do was manipulating bug status
etc. which we never had to recover, yet ... but could if it came to it.

johannes

P.S. If somebody I know pings me I typically approve accounts, both for
PECL and php.net but we could spread the powers to other, more active,
people.

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

[PHP-DEV] The RFC discussion process?

[Mike Schinkel]

Hi all,

I am relatively new to discussions on the list, and so I have tried to 
understand the ethos of the community to stay within bounds that the community 
generally considers acceptable.  

However I am realizing those the bound of acceptability may be fluid at times 
so I am asking explicitly for clarification.

1. What is acceptable to discuss in an RFC discussion thread?  

Recently while discussing object initializers I was told "I think that's only 
true because you've actually proposed a number of related but different 
features," "This is an interesting additional proposal," and "This again is an 
interesting proposal, but completely unrelated to object initializer syntax."  

But I was replying to a message where a frequent and I believe a respected 
contributor wrote the following, also unrelated to the RFC: "My strong 
preference over this feature would be named parameters, which can provide the 
same abbreviated initializations, but works more consistently with the 
language, e.g. for all of the use-cases I cited above."

I am not naming names because I am not trying to make this about those people 
but instead to understand what is appropriate to discuss during an RFC.  So Is 
it is appropriate to discuss:

1. Alternatives to the RFC?
2. Enhancements to the RFC?
3. Modifications to the RFC?
4. Other features that are a pre-requisite for the RFC's feature?
5. Other features that would add value to the RFC's feature?


2. Are "amendments" acceptable for RFC discussions?

I am thinking of Congress in the USA, Parliament in the UK, and other political 
governing bodies. My understanding is that bills are introduced and they have 
the possibility of being amended by other members of the political body.  

Comparing that to the RFC process it seems RFCs are like bills; is there an 
amendment process, and if so how does it work?  From what I can to amend an RFC 
requires getting the original submitter to modify it, which if that is the 
process that is understandable.

However, what seems strange is that I also understand there is a 6 month 
moratorium on revisiting a topic that did not pass by RFC, but an RFC could 
potentially not pass because of details in the RFC and not because the overall 
idea is bad. 

If I understand correctly, this means others cannot restart a topic for 6 
months because the person who first drafted the failed RFC did not or would not 
incorporate aspects that might have allowed it to pass?

3. Why is there not more transparency for why RFCs pass or do not pass?

Looking in from the outside I see is almost no transparency related to reasons 
why RFCs pass vs. don't pass. When I visit the RFCs of past I see lots of votes 
but almost no rationale why those votes passed or failed.

There are a few active members on the list, but many more people who have a 
vote who I think rarely if ever comment on the list.  So it seems impossible to 
determine what the objections are from the people who vote against an RFC.  
Which means it will be hard to address their concerns as time goes on and other 
languages evolve because of userland demand to add the features that PHP voted 
down.

Unlike the US Supreme Court and I assume many other nation's supreme courts, 
the people with an RFC vote are not required to write or join an opinion as to 
the reason for or against an RFC. 

This unfortunate state means the rationale for the PHP group voting for or 
against an RFC is lost to the mists of time, except for the history left by the 
few vocal people who have the free time to participate on the list in 
discussions. Most of the people with a vote rarely opine on the list, or that 
is the impression I am getting.

--

Thanks in advance for reading and responding to these questions. And based on 
the replies, I may have a few more follow up questions.

-Mike

[PHP-DEV] Re: [RFC] DOM Living Standard API

[Benjamin Eberlei]

On Fri, Mar 22, 2019 at 9:14 PM Benjamin Eberlei 
wrote:

> Hi Internals,
>
> Thomas and I are working on updating the ext/dom to add support for the
> current DOM Living Standard API as standardized here:
> https://dom.spec.whatwg.org/
>
> https://wiki.php.net/rfc/dom_living_standard_api
>
> This RFC is targeting 7.4 and contains three independent changes:
>
> - a set of new methods and interfaces that can be implemented BC as
> addition to the existing ext/dom.
> - a removal of a few "dead" classes that are exposed to userland, but
> neither documented nor containing implementation code.
> - a compatibility layer to switch the implementation between DOM Level 1-3
> and the Living Standard in places where BC is not possible.
>
> A pull request includes a nearly complete implementation of the new
> methods, but nothing of the cleanup/compatibility yet:
> https://github.com/beberlei/php-src/pull/1
>
> We are looking forward for your feedback.
>
> greetings
> Benjamin
>

Hi internals,

a few month have gone by and I came back to revisit this RFC and simplify
to get something shipped.

i have updated the RFC to only include the set of new methods and
interfaces that the DOM Living Standard has implemented.

https://wiki.php.net/rfc/dom_living_standard_api

I am asking about feedback especially on the section "Implementation
Details", that explains some key differences to "PHPify" the DOM Living
Standard API to PHP and ext/dom. Do you have any comments about the
reasonability of the choices?

Also the section on "Not adopting Nodes for now" is new and I need some
feedback on this issue: To keep the proposal slim with respect to changing
existing behavior, the improved behavior of the DOM Living Standard over
Level 1-2 tof automatically adopting nodes instead of throwing a WRONG
DOCUMENT DOMexception is not considered for now. Do you think this is a
reasonable approach to go forward with?

As for the implementation, it is now in this PR
https://github.com/php/php-src/pull/4709

Looking forward for further input.

Benjamin

List of Changes to RFC:

- The RFC has been updated to include a few more details about what each
new property or method does.
- The new behavior of the Living Standard of automatically adopting nodes
is skipped in implementation for now to keep the existing behavior of other
manipulation methods to throw WRONG document. Workaround is still to
importNode first. Adopting nodes can be implemented as improvement later,
because it has no backwards compatibility impact.
- I removed all sections on trying to achieve compatibility between old DOM
level 1-3 and the living standard, especially w.r.t. to DOMHtmlDocument
(uppercase nodeName, body property, ...). I think we can live with not 100%
compliant, ext/dom never was fully compliant. helpful would be a new
section in the docs that explains our existing differences to the spec to
users. Specifically the spec itself says that users should test existance
of features by checking for properties or methods.
- The cleanup of dead / unimplemented classes is not RFC worthy and can be
done without making the RFC more complex.

Re: [PHP-DEV] Changing PECL signup flow.

[Thomas Hruska]

On 9/15/2019 10:11 AM, Dan Ackroyd wrote:

HI internals,

Currently, it is quite difficult to signup to get a PECL account.

We have a somewhat deliberately obtuse form to signup through, which
then needs to be manually approved by someone with the appropriate
karma.

Over the past year two people who I know from the community have
reached out to me to ask "we've submitted our account application, how
do we get approved now", after their application has sat un-actioned
for weeks. And only after I spoke to someone with the appropriate
karma was their account approved.

I would like to suggest the following changes both to allow it easier
to publish PECL extensions, and also prevent that causing problems.

# Allow a new signup method

Allow people who want a PECL account to submit a link to github repo
(or alternative VCS provider) that contains a 'ready-to-ship' PHP
extension repo.

We (or probably, I) will provide a tool that allows people to check
that their repo is ready to be submitted to PECL, including all the
appropriate things like buildconf works, the name of the project is
set in the appropriate place.

On signup, when someone submits a 'ready-to-ship' extension we will
have code that checks the extension for conformance, and if the
extension looks ready to go, their application is listed on a page
where anyone with PECL karma can approve or reject the application.

This would remove the bottleneck of only a few people being able to
approve the PECL accounts, while still blocking most inappropriate
signup attempts.

# Change voting rights

Getting a pecl account would explicitly no longer give or require a
php.net account, and wouldn't confer voting karma. To be clear, I am
actually unsure whether it's intended for people with PECL accounts
should get voting karma; I know some people did but apparently not all
have.

Although giving those a php.net account and voting karma is
appropriate for extensions that are widely used, it is not appropriate
for extensions that belong to a company and don't represent a wider
community interest to automatically get a php.net account and/or
voting rights.

For example, there are multiple extensions that allow Application
Performance Monitoring. Those extensions are not 'owned' by the
community, but instead represent a commercial interest.

Those two changes should allow extensions to be listed on PECL much
more easily, without being too disruptive to the PECL site.

Thoughts?


Sounds good to me.

I thought the php.net account was for incorporating new documentation?

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

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

[PHP-DEV] Re: [RFC] Reclassifying engine warnings

[Mark Randall]

On 28/08/2019 10:33, Nikita Popov wrote:

https://wiki.php.net/rfc/engine_warnings


I am 100% behind the exception proposals, however I did want to discuss 
the warnings.


I am personally of the belief that there should be a distinction made 
between notices / warnings issued by the engine, and those issued by 
extensions, including standard.


I am one of a large number of developers that enforces a "No notice or 
warning" requirement on their codebases. To this end I use a global 
error handler that converts ANY notice or error to an \Error exception 
(within our specific code, so excluding anything in /vendor and the likes).


This does however, effect function calls as well, and it's less ideal to 
have function calls throwing Error, something derived from Exception 
would make more sense. The issue is which is which.


If this does pass, I was wondering if there would be any appetite for 
re-using the E_CORE_XXX error error codes specifically to refer to ALL 
engine warnings, not just those at startup.


Alternatively, the passing of a bitflag to indicate they came from the 
engine while still preserving the original bit, although that may be 
more of a BC break due to requiring bitwise mask comparison in existing 
handlers.


Either way, this this would allow easily differentiating engine warnings 
that will become more prominent in this RFC, with those contained in 
PHP_FUNCTION scope.




--
Mark Randall

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

Re: [PHP-DEV] Defining the PHP Group

[Mike Schinkel]

>   >  On Sep 15, 2019 at 8:57 AM,wrote:  >   >  
Anyone may initiate an RFC for any subject.  >  For example, this phrasing 
means the RFC system itself can be put up to vote, to be removed and replaced 
with something entirely non-democratic. I do not want dive too deep into this 
debate though I do want to point out the irony of the above statement. 

  
But I start by saying I have been paying a lot of attention recently to the 
concept of governance because — well — I live in the USA and given our current 
President many of us are asking ourselves the same questions.   
  

  
Paul warns against replacing the RFC system with something "non-democratic." To 
me hat is an ironic statement because PHP is not a democracy, it is an 
oligarchy[1]. A more correct statement would have been "For example, this 
phrasing means the RFC system itself can be put up to vote, to be removed and 
replaced with something that denies those currently in control their current 
level of control, whether moving more towards a dictatorship or towards a more 
open democracy, such as a representative one."   
  

  
To be clear, I am not arguing whether oligarchy is good or bad for PHP in this 
message, just pointing out that PHP governances is in fact not democratic if 
you consider the interests and concerns of all of userland. #justsaying -Mike 
[1] https://en.m.wikipedia.org/wiki/Oligarchy  

   

Re: [PHP-DEV] Defining the PHP Group

[Olumide Samson]

On Sun, Sep 15, 2019, 11:41 PM Olumide Samson  wrote:

>
>
> On Sun, Sep 15, 2019, 8:33 PM Stanislav Malyshev 
> wrote:
>
>> Hi!
>>
>> > Does anyone object to any of those words ?
>>
>> Yes. I do not think precommitting to implement anything that has been
>> put on wiki and passed the vote is a good thing. Its a good conflict
>> resolution mechanism when we're talking about where or not to implement
>> certain technical feature. But IMO it would be terrible as a sole
>> governance mechanism for the whole project.
>>
>> > Do we need to vote on changing the introduction (I'm happy to start an
>> rfc
>> > for this, if necessary) ?
>>
>> I don't think RFCs were meant to essentially remake all project
>> governance structure.
>
>
> Hi Stanislav, I would expect you to reply with what can be done, not
> saying the RFC is not meant to do this and that, my common sense is telling
> me you are either deliberately omitting some details on what the process
> would be, if not the RFC.
>
> Everyone else - what was the process that brought about the RFC?
>
> If its mails through the mailing list(that brought about the RFC), then
> mails with majority agreed on signify the changes required to change the
> RFC itself.
>
> I don't like it when people say parliament was created by constitution yet
> the parliament can't still change constitution; then what else can change
> the constitution, maybe voice vote?
>
> The RFC was created years ago and IMO can't be there forever, so what
> would change it? The RFC itself recently changed some scope of itself.
>
> GCC would call this bootstrapping
>
> They were meant for solving technical questions,
>> not governance model.
>> I am not sure which way would be the best (haven't thought about it) but
>> certainly neither just putting some words on wiki nor voting on it
>> within the RFC process looks like a good way to do it.
>>
>> --
>> Stas Malyshev
>> smalys...@gmail.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

[Aegir Leet]

Not super familiar with building PHP, but this should be a reasonable
starting point, tested on a fresh install of Ubuntu 18.04.3:

apt install -y autoconf gcc bison re2c libxml2-dev libssl-dev
libsqlite3-dev libcurl4-openssl-dev libpng-dev libwebp-dev libjpeg-dev
vflib3-dev libc-client-dev libkrb5-dev libonig-dev libreadline-dev
libsodium-dev libargon2-0-dev libzip-dev ./buildconf ./configure
--enable-fpm --with-openssl --with-kerberos --with-imap-ssl
--with-pcre-jit --with-zlib --enable-bcmath --with-curl --enable-exif
--enable-ftp --enable-gd --with-webp --with-jpeg --with-freetype
--with-gettext --with-imap --enable-intl --enable-mbstring --with-mysqli
--enable-pcntl --with-pdo-mysql --with-readline --enable-sockets
--with-sodium --with-password-argon2 --with-zip --enable-zts


On 15.09.2019 20:49, Nikita Popov wrote:
> Hi,
>
> Our build instructions in
> https://github.com/php/php-src#building-php-source-code are currently a bit
> bare... they show the basic "./buildconf && ./configure && make" cycle, but
> everyone who actually tries this will quickly find out that there is a lot
> more to building PHP...
>
> Every time I compile PHP on a new system, I have to go through a pretty
> long cycle of ./configure --xxx, wait until there is an error, "sudo apt
> install libxxx-dev" and so on.
>
> It would be great if someone could write up the required "apt get" and
> "./configure" line to get a "reasonably large" build of PHP on a popular
> Linux distro like Ubuntu 18.04, so this can be included in the README.
> Something similar for MacOS would probably also be useful, where things are
> even more complicated.
>
> Bonus points for also including how to set up MySQL and Postgres in a way
> that you can run mysqli/pdo_mysql and pgsql/pdo_pgsql tests. I think I lose
> a couple of hours every time I try to get this working.
>
> Anyone interested in doing this?
>
> Regards,
> Nikita
>

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

[Mark Randall]

On 15/09/2019 21:53, Gabriel Caruso wrote:

The main problem with Docker and php-src is that we need to touch the OS in
order to make sure the new features and bugfixes will be compatible.


What in particular needs to be adjusted at OS level to make testing 
work? If there's a list we can probably find a way around it, at least 
when running containerised.


Are you referring to installing shared libraries on the host?

--
Mark Randall

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

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

[Dik Takken]

On 15-09-19 22:53, Gabriel Caruso wrote:
> 
> 
> The main problem with Docker and php-src is that we need to touch the OS in
> order to make sure the new features and bugfixes will be compatible.
> 
> Docker create a layer on top of that, right?
> 

Correct. Honestly I was not considering the use case of testing
interactions with OS-specific features as one might do using a CI/CD
setup. Providing instructions that will work for every supported target
environment is not an easy thing to do.

I was thinking about the use case of local development where the
developer needs to build the sources on whatever OS he / she happens to
be using. Then, Docker makes much more sense as it provides a single
consistent environment that will work the same way for anyone.

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

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

[Stanislav Malyshev]

Hi!

> May I suggest to provide instructions to build using Docker? This has a
> number of advantages:
> 
> * Same instructions will work on Linux, MacOS and Windows
> * No need to install build dependencies on your host
> * Spin up a MySQL container by running 'docker run mysql:version'

This is certainly a good idea to have Docker build instructions as an
option, but would not be good as the only or primary option. There are
lots of situations where installing the whole docket setup on a host is
either hard or an overkill for just building PHP. But as an option it's
good.

> I took this route a while ago when I needed to setup a dev environment
> and it works nicely. I could do a write-up of this route if desired.

I think having good docker-based build instructions would certainly be
appreciated.

> Part of the instructions could be cast into a Docker image that can be
> published on Github and Docker Hub. This image could even have the
> command to run the tests baked into the image itself. Then, anyone can
> just run
> 
> docker run php-tests:7.4
> 
> to build the sources and run the tests. For development you can mount
> your local git clone in the container.

Sounds like a nice idea.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

[Gabriel Caruso]

Hello Dik

On Sun, Sep 15, 2019, 22:42 Dik Takken  wrote:

> On 15-09-19 20:49, Nikita Popov wrote:
> >
> > Anyone interested in doing this?
> >
>
> Hi Nikita,
>
> May I suggest to provide instructions to build using Docker? This has a
> number of advantages:
>
> * Same instructions will work on Linux, MacOS and Windows
> * No need to install build dependencies on your host
> * Spin up a MySQL container by running 'docker run mysql:version'
>
> I took this route a while ago when I needed to setup a dev environment
> and it works nicely. I could do a write-up of this route if desired.
>
> Part of the instructions could be cast into a Docker image that can be
> published on Github and Docker Hub. This image could even have the
> command to run the tests baked into the image itself. Then, anyone can
> just run
>
> docker run php-tests:7.4
>
> to build the sources and run the tests. For development you can mount
> your local git clone in the container.
>
> Regards,
> Dik Takken
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


The main problem with Docker and php-src is that we need to touch the OS in
order to make sure the new features and bugfixes will be compatible.

Docker create a layer on top of that, right?

Best regards,

>
>

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

[Dik Takken]

On 15-09-19 20:49, Nikita Popov wrote:
> 
> Anyone interested in doing this?
> 

Hi Nikita,

May I suggest to provide instructions to build using Docker? This has a
number of advantages:

* Same instructions will work on Linux, MacOS and Windows
* No need to install build dependencies on your host
* Spin up a MySQL container by running 'docker run mysql:version'

I took this route a while ago when I needed to setup a dev environment
and it works nicely. I could do a write-up of this route if desired.

Part of the instructions could be cast into a Docker image that can be
published on Github and Docker Hub. This image could even have the
command to run the tests baked into the image itself. Then, anyone can
just run

docker run php-tests:7.4

to build the sources and run the tests. For development you can mount
your local git clone in the container.

Regards,
Dik Takken

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

Re: [PHP-DEV] Defining the PHP Group

[Stanislav Malyshev]

Hi!

> Then we should undo all changes (as far as possible) caused by the RFCs
> listed in the Process and Policy section[1], probably starting with the
> Voting (aka. RFC) process RFC itself, which by the way, states as
> introduction since its very first version from 2011 (emphasis mine):
> 
> | This document describes the procedure to propose an *idea* for
> | adoption by the PHP community and decide if the community accepts or
> | rejects the idea.

Proposing an idea for adoption is not the same as precommitting on
implementing anything that has been voted on, including whole governance
of the project.

I did not suggest undoing anything, and there's really no need to put
words in my mouth, I can speak for myself.

Thanks,
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Defining the PHP Group

[Christoph M. Becker]

On 15.09.2019 at 21:33, Stanislav Malyshev wrote:

>> Do we need to vote on changing the introduction (I'm happy to start an rfc
>> for this, if necessary) ?
>
> I don't think RFCs were meant to essentially remake all project
> governance structure. They were meant for solving technical questions,
> not governance model.

Then we should undo all changes (as far as possible) caused by the RFCs
listed in the Process and Policy section[1], probably starting with the
Voting (aka. RFC) process RFC itself, which by the way, states as
introduction since its very first version from 2011 (emphasis mine):

| This document describes the procedure to propose an *idea* for
| adoption by the PHP community and decide if the community accepts or
| rejects the idea.

Thanks,
Christoph

[1] 

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

Re: [PHP-DEV] Defining the PHP Group

[Stanislav Malyshev]

Hi!

> Does anyone object to any of those words ?

Yes. I do not think precommitting to implement anything that has been
put on wiki and passed the vote is a good thing. Its a good conflict
resolution mechanism when we're talking about where or not to implement
certain technical feature. But IMO it would be terrible as a sole
governance mechanism for the whole project.

> Do we need to vote on changing the introduction (I'm happy to start an rfc
> for this, if necessary) ?

I don't think RFCs were meant to essentially remake all project
governance structure. They were meant for solving technical questions,
not governance model.
I am not sure which way would be the best (haven't thought about it) but
certainly neither just putting some words on wiki nor voting on it
within the RFC process looks like a good way to do it.

-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

[Nikita Popov]

Hi,

Our build instructions in
https://github.com/php/php-src#building-php-source-code are currently a bit
bare... they show the basic "./buildconf && ./configure && make" cycle, but
everyone who actually tries this will quickly find out that there is a lot
more to building PHP...

Every time I compile PHP on a new system, I have to go through a pretty
long cycle of ./configure --xxx, wait until there is an error, "sudo apt
install libxxx-dev" and so on.

It would be great if someone could write up the required "apt get" and
"./configure" line to get a "reasonably large" build of PHP on a popular
Linux distro like Ubuntu 18.04, so this can be included in the README.
Something similar for MacOS would probably also be useful, where things are
even more complicated.

Bonus points for also including how to set up MySQL and Postgres in a way
that you can run mysqli/pdo_mysql and pgsql/pdo_pgsql tests. I think I lose
a couple of hours every time I try to get this working.

Anyone interested in doing this?

Regards,
Nikita

Re: [PHP-DEV] Computing code coverage on Azure Pipelines

[Nikita Popov]

On Sun, Sep 15, 2019 at 7:39 PM Gabriel Caruso 
wrote:

> Hello Nikita,
>
> Em dom, 15 de set de 2019 às 19:29, Nikita Popov 
> escreveu:
>
>> Hi,
>>
>> gcov.php.net used to provide valgrind reports and code coverage for
>> php-src. It no longer works with 7.4/8.0, because the OS is very old, and
>> building new versions of PHP there gets very hard. The valgrind reports
>> have essentially been subsumed by asan/ubsan on Azure Pipelines, but we're
>> still missing a replacement for code coverage.
>>
>> I think it should be possible to set up an Azure Pipelines job that runs
>> tests with coverage and publishes it, preferably on Azure Pipelines
>> itself,
>> or if that doesn't work something like codecov.io.
>>
>> Maybe someone is interested in giving this a try?
>>
>> Regards,
>> Nikita
>>
>
> I'm, as I've also reported this a while ago:
> https://bugs.php.net/bug.php?id=78288.
>
> Do you have something in mind how/what to set up?
>

The first step is probably to get code coverage working locally. We have a
./configure --enable-gcov option and there's some extra make targets in
build/Makefile.gcov. Maybe taking a look at what
https://github.com/php/web-gcov/blob/master/cron/cron.sh does would help.

Second step is to add a new job in azure by copying
https://github.com/php/php-src/blob/master/azure/job.yml and adding the
necessary gcov/lcov magic there.

The hard part if how to get those results published on Azure under the
"Code coverage" tab. There is a PublishCodeCoverageResults task for this
purpose, but I don't know how one would use that with lcov in particular.
It seems to me that part of it requires a coverage overview in a specific
format and part is just a directory with HTML, so maybe the result from ltp
genhtml can just be used there? Figuring out how to make this work is
likely going to be "fun" ;)

Nikita

>

Re: [PHP-DEV] Computing code coverage on Azure Pipelines

[Gabriel Caruso]

Hello Nikita,

Em dom, 15 de set de 2019 às 19:29, Nikita Popov 
escreveu:

> Hi,
>
> gcov.php.net used to provide valgrind reports and code coverage for
> php-src. It no longer works with 7.4/8.0, because the OS is very old, and
> building new versions of PHP there gets very hard. The valgrind reports
> have essentially been subsumed by asan/ubsan on Azure Pipelines, but we're
> still missing a replacement for code coverage.
>
> I think it should be possible to set up an Azure Pipelines job that runs
> tests with coverage and publishes it, preferably on Azure Pipelines itself,
> or if that doesn't work something like codecov.io.
>
> Maybe someone is interested in giving this a try?
>
> Regards,
> Nikita
>

I'm, as I've also reported this a while ago:
https://bugs.php.net/bug.php?id=78288.

Do you have something in mind how/what to set up?

Best regards,

-- Gabriel Caruso

[PHP-DEV] Computing code coverage on Azure Pipelines

[Nikita Popov]

Hi,

gcov.php.net used to provide valgrind reports and code coverage for
php-src. It no longer works with 7.4/8.0, because the OS is very old, and
building new versions of PHP there gets very hard. The valgrind reports
have essentially been subsumed by asan/ubsan on Azure Pipelines, but we're
still missing a replacement for code coverage.

I think it should be possible to set up an Azure Pipelines job that runs
tests with coverage and publishes it, preferably on Azure Pipelines itself,
or if that doesn't work something like codecov.io.

Maybe someone is interested in giving this a try?

Regards,
Nikita

[PHP-DEV] Changing PECL signup flow.

[Dan Ackroyd]

HI internals,

Currently, it is quite difficult to signup to get a PECL account.

We have a somewhat deliberately obtuse form to signup through, which
then needs to be manually approved by someone with the appropriate
karma.

Over the past year two people who I know from the community have
reached out to me to ask "we've submitted our account application, how
do we get approved now", after their application has sat un-actioned
for weeks. And only after I spoke to someone with the appropriate
karma was their account approved.

I would like to suggest the following changes both to allow it easier
to publish PECL extensions, and also prevent that causing problems.

# Allow a new signup method

Allow people who want a PECL account to submit a link to github repo
(or alternative VCS provider) that contains a 'ready-to-ship' PHP
extension repo.

We (or probably, I) will provide a tool that allows people to check
that their repo is ready to be submitted to PECL, including all the
appropriate things like buildconf works, the name of the project is
set in the appropriate place.

On signup, when someone submits a 'ready-to-ship' extension we will
have code that checks the extension for conformance, and if the
extension looks ready to go, their application is listed on a page
where anyone with PECL karma can approve or reject the application.

This would remove the bottleneck of only a few people being able to
approve the PECL accounts, while still blocking most inappropriate
signup attempts.

# Change voting rights

Getting a pecl account would explicitly no longer give or require a
php.net account, and wouldn't confer voting karma. To be clear, I am
actually unsure whether it's intended for people with PECL accounts
should get voting karma; I know some people did but apparently not all
have.

Although giving those a php.net account and voting karma is
appropriate for extensions that are widely used, it is not appropriate
for extensions that belong to a company and don't represent a wider
community interest to automatically get a php.net account and/or
voting rights.

For example, there are multiple extensions that allow Application
Performance Monitoring. Those extensions are not 'owned' by the
community, but instead represent a commercial interest.

Those two changes should allow extensions to be listed on PECL much
more easily, without being too disruptive to the PECL site.

Thoughts?

cheers
Dan
Ack

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

Re: [PHP-DEV] Defining the PHP Group

[Marco Pivetta]

On Sun, Sep 15, 2019, 17:28 Zeev Suraski  wrote:

> I think it's clear you don't realize how rude you are, no surprises there.
> I'm not going to continue discussing this topic with you.  You seem to
> think my words carry no weight, I'm absolutely sure yours don't carry any
> weight - let's save everyone some time mental strain.
>

Your words carry weight which is mostly a burden. Your discussions in the
last month(s) have been detrimental to actually improving the language, by
distracting, driving away and annoying contributors that are otherwise very
much interested in discussing improvements.

Dan's words do carry weight too, and it's the  the weight of frustration of
having to continuously deal with this unnecessary friction.

>
>

Re: [PHP-DEV] Defining the PHP Group

[Zeev Suraski]

I think it's clear you don't realize how rude you are, no surprises there.
I'm not going to continue discussing this topic with you.  You seem to
think my words carry no weight, I'm absolutely sure yours don't carry any
weight - let's save everyone some time mental strain.

To everyone else - I stand 100% behind everything I wrote in my reply to
Peter.

Zeev

On Sun, Sep 15, 2019 at 5:19 PM Dan Ackroyd  wrote:

> Please only email me through the list.
>
> I do not believe it is rude to point out when other people are trying
> to force their will on a large community. It's very awkward, but it's
> not rude.
>
> cheers
> Dan
> Ack
>

Re: [PHP-DEV] Defining the PHP Group

[Dan Ackroyd]

On Sun, 15 Sep 2019 at 15:08, Zeev Suraski  wrote:
> On Sun, Sep 15, 2019 at 4:44 PM Dan Ackroyd  wrote:
>>
>>
>> It is not appropriate.
>>
>> If it continues, we are going to have to look at bringing in a code of
>> conduct to prevent this disruptive behaviour from being such a
>> negative effect on other people.
>
>
> Stop threatening me or behaving as if you're my parent.  You're not in any 
> position to do the former and you're definitely not the latter.  I place zero 
> weight on what you have to say on these topics given your consistently rude 
> behavior towards me, save your keystrokes.
>
> I decided not to copy internals@ to save it some drama and wasted time, but 
> I'll absolutely stand publicly behind these statements if you decide to 
> publish them still.
>
> Zeev

Hi Zeev,

Please only email me through the list.

I do not believe it is rude to point out when other people are trying
to force their will on a large community. It's very awkward, but it's
not rude.

cheers
Dan
Ack

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

Re: [PHP-DEV] [RFC] Object Initializer

[Paul M. Jones]

> On Sep 12, 2019, at 09:00, Michał Brzuchalski  
> wrote:
> 
> Hi internals,
> 
> I'd like to open discussion about RFC: Object Initializer.
> 
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without required constructor arguments as
> a single expression with initializer block.
> 
> https://wiki.php.net/rfc/object-initializer

This reminds me of how Hack/HHVM would initialize object properties from 
constructor parameters; I remember finding it very appealing.

IIRC, you would provide the property signature as a constructor parameter to 
trigger the initialization:

```php
class Foo
{
protected int $bar;

public function __construct(protected int $bar)
{
}

public function getBar() : int
{
return $this->bar;
}
}

$foo = new Foo(1);
echo $foo->getBar(); // 1
```

Perhaps something like that is worth adopting here.



-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

Re: [PHP-DEV] Defining the PHP Group

[Dan Ackroyd]

On Sun, 15 Sep 2019 at 14:16, Zeev Suraski  wrote:
>
> We a new mechanism for deprecations/radical changes

The current maintainers are not bound by choices made by other people,
years ago.

No-one wants to break stuff just for the sake of it, but we are free
to correct mistakes that were made in the past, and also revisit
decisions that were correct at the time but are no longer appropriate
given current circumstances.

I ask you again, please stop trying to impose your will on how PHP is
maintained.

It is not appropriate.

If it continues, we are going to have to look at bringing in a code of
conduct to prevent this disruptive behaviour from being such a
negative effect on other people.

cheers
Dan
Ack

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

Re: [PHP-DEV] Defining the PHP Group

[Zeev Suraski]

On Sun, Sep 15, 2019 at 2:37 PM Peter Bowyer 
wrote:

> On Sun, 15 Sep 2019 at 06:48, Joe Watkins  wrote:
>
> > The Wikipedia states that PHP is developed by the PHP Group, in saying
> this
> > it is (must be) referring to internals as a whole, but our own
> > documentation names members of the group - who aren't even around mostly.
> >
> > I think we need to clarify what exactly is the purpose of the PHP Group
> > today, does anyone want to attempt to do that ?
> >
>
> Joe, I applaud this move.
>
> As a non-American and so used to a different legal system, I have a further
> point I would like clarified: the PHP website and PHP license say
> "Copyright the PHP Group" (https://www.php.net/copyright.php,
> https://www.php.net/license/3_01.txt).
>
> How can an undefined group have copyright vested in it?


It's very much well-defined.  And certainly not by Wikipedia, but in the
PHP source code and the php.net website itself.  Right at the top of the
Credit page:
https://www.php.net/credits.php


> And more
> importantly, how would it defend or deal with a copyright infringement if
> "The PHP Group" is not a recognised group or legal entity?
>

Thankfully, copyright infringements are practically irrelevant as far as
the PHP license is concerned.  License violations are also pretty much
irrelevant, with the only practical exception being someone breaking the
clause that requires them not to use the name 'PHP' to promote a derivative
product.  But we've been able to deal with this gracefully for the past ~20
years, and I don't see a reason that should change.

To the suggested proposal - it's quite obvious that you can't use a
mechanism to widen its own scope.  Changing the Voting RFC (either
unilaterally or by using the Voting RFC itself) to extend its jurisdiction
is meaningless.  It was never, ever designed to be a mechanism to radically
alter the language (which nobody even considered as an option at the time
of its introduction) - but as a way to extend it.  There are several
references in the text - both of the Voting RFC itself, the RFC template
and the RFC howto that make the scope of this mechanism quite clear.

Note that I'm not at all advocating that we defer deprecation/radical
changes to Group.  That's impractical and more importantly - makes no
sense.  But so is using the same threshold for adding a feature and
removing it - that too makes absolutely no sense at all.  The negative
end-user impact from taking away a feature that they've grown to rely on is
virtually always far greater than adding it in the first place.  In 20+
years of the project, there were 3 proactive major compatibility breakages
that we decided to go for - namely, register_globals, magic_quotes and
safe_mode.  The first two had super simple one liner workarounds, and were
disabled by default for many years before they were deprecated and
subsequently removed.  The 3rd was so inherently unsafe and complex to
maintain that we decided that the price of removing it was worth the impact
- which was limited almost exclusively to shared hosters (and there were
much more reliable alternatives emerging at the time).  We didn't have a
voting mechanism back then, these decisions passed in near-consensus (not
66/33, but an overwhelming support and very little opposition, IIRC a lot
closer to 10 to 1 vs. 2/3).

We a new mechanism for deprecations/radical changes - i.e., things that
break existing code (as opposed to make new code possible).  It can reuse
much of the process of the Voting RFC, but the threshold has to correlate
to the expect breakage impact (and we need to be able to measure that in a
reasonable way).  Simple things with limited impact can stick with 2/3,
which is still too low but has become a standard.  Things with far-reaching
impact should have a much higher, near-consensus bar.  Yes, it means that
proposals with a far-reaching effect on end users will need to be almost
unanimously agreed upon before they clear, much like they did in the past
when we've made similar decisions.  They'll have to have a super convincing
case and not one that's deemed controversial by a sizable number of
voters.  Which means they'll be uncommon, and when they do take place -
it'll be for very good reasons.

Zeev

Re: [PHP-DEV] Defining the PHP Group

[Dan Ackroyd]

On Sun, 15 Sep 2019 at 13:57, Paul M. Jones  wrote:

> Some things simply have to be off limits. What are those things?

PHP doesn't currently have a constitution, so currently voting is the
only way of  deciding things. Also how we vote is one of the things
that people are allowed to vote on.

Even if we had a constitution, like the US does there would still need
to be ways of changing it,
https://en.wikipedia.org/wiki/Constitutional_amendment

> This strikes me as yet another attempt at a power grab
> ...only the current passion of a mob.

Your opinion would have more weight if you contributed more to
internals, other than popping by occasionally to say nasty things to
people.

cheers
Dan
Ack

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

Re: [PHP-DEV] Defining the PHP Group

[Paul M. Jones]

Hi all,


> Does anyone object to any of those words ?

This strikes me as yet another attempt at a power grab, so many of the words 
are objectionable. However, this phrase will serve to show the weakness of the 
proposal:


> Anyone may initiate an RFC for any subject.

There needs to be an articulable limiting principle; without it, there can be 
no strong continuity, only the current passion of a mob. For example, this 
phrasing means the RFC system itself can be put up to vote, to be removed and 
replaced with something entirely non-democratic.

Some things simply have to be off limits. What are those things?


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

Re: [PHP-DEV] PHP's declining(?) popularity

[Zeev Suraski]

On Sun, Sep 15, 2019 at 1:15 PM Olumide Samson  wrote:

> I also don't agree with the index and all its statistics
>

I'm not sure what you mean by 'all its statistics'.  Mostly everything on
the methodology page is fluff, which may be purposely there to hide the
only part that really matters:


The ratings are calculated by counting hits of the most popular search
engines. The search query that is used is

+" programming"

 ---

It's a simplistic measure of an arbitrary search term in search engines -
nothing more.  It's completely, 100.0% meaningless.


> , yet I'm not invalidating it as it is a much-viewed index globally.
>

I am.  It's quite remarkable that people are paying any level of attention
to it whatsoever, and indeed it's saddening.  But the fact that many people
believe something doesn't make it true, if the evidence clearly suggest it
isn't.

According to the index :
>  "Till the end of 2009 everything went fine, but soon after that PHP was
> going downhill from 10% to 5% market share in 2 years’ time. In 2014 it
> halved again to 2.5%.
>

Trying to correlate the TIOBE index with anything that happened in the PHP
world is akin to trying to correlate the results of rand() with the weather
forecast.  The two aren't related at all.  Building any thesis on the
foundation of the TIOBE index is like trying to build a brick house on a
muddy soil.  Heck, like trying to build a brick house in the middle of the
ocean.  There's nothing to build on.

While it's extremely difficult to measure the popularity of languages,
RedMonk's slightly more relevant measurements (GitHub projects and Stack
Overflow questions) suggest it's been doing well over the last decade -
right up there in the top 5 with no meaningful decline.  What Mike and
others pointed out are areas where we should consider investing if we want
to *increase* the popularity beyond what it already is (which is what
happened with Python).

Zeev

Re: [PHP-DEV] Defining the PHP Group

[Peter Bowyer]

On Sun, 15 Sep 2019 at 06:48, Joe Watkins  wrote:

> The Wikipedia states that PHP is developed by the PHP Group, in saying this
> it is (must be) referring to internals as a whole, but our own
> documentation names members of the group - who aren't even around mostly.
>
> I think we need to clarify what exactly is the purpose of the PHP Group
> today, does anyone want to attempt to do that ?
>

Joe, I applaud this move.

As a non-American and so used to a different legal system, I have a further
point I would like clarified: the PHP website and PHP license say
"Copyright the PHP Group" (https://www.php.net/copyright.php,
https://www.php.net/license/3_01.txt).

How can an undefined group have copyright vested in it? And more
importantly, how would it defend or deal with a copyright infringement if
"The PHP Group" is not a recognised group or legal entity?

Peter

Re: [PHP-DEV] PHP's declining(?) popularity

[AllenJB]

I'm not going to go into my opinions on rankings - others have already 
done enough of that. I concur with them - most rankings are meaningless. 
PHP is also not, in my opinion, dead or dying. It doesn't enjoy the 
monopoly it once had on web-based development, but it's also still very 
popular.


PHP has been my primary language for a long time. I've recently been 
undertaking a small personal project in Python - namely because there's 
no well maintained PHP equivalent of the library I want to use 
(gmusicapi - Google Play Music has no official documented API).


In my opinion, Python is popular on the command-line / linux partly 
because it's become a replacement for Perl. Perl used to be king for 
doing a lot of scripting and anything remotely complex, then they went 
off on their Perl 6 voyage and now I don't think anyone knows what's 
going on with it or has the time to care.


Python also has a reputation for being a language for doing "big data" / 
"machine learning" / "AI" things, and since that's a big thing, it gets 
picked a lot for those reasons.


It's also used in places like Plex and XBMC/Kodi plugins where I think a 
number of people get their first "I want to program" itch. Wordpress 
(plugins) used to be a big draw for PHP here, but I think with the rise 
of alternatives (static site builders, use of other languages, increased 
capabilities on browsers) this has waned over the years.


Maybe it's coming from PHP and I was specifically trying to avoid having 
to deal with writing / using a Python HTTP server and getting a setup 
similar to PHP-FPM, but in my opinion setting up anything web-based in 
Python is kind of a mess - there's a lot of alternatives and no clear 
easy option. For me, PHP, with the simplicity of PHP-FPM is, in my 
opinion, clearly better here.


One area where I think Python really stands out compared to PHP tho is 
its "new user experience". Starting with the official tutorial ( 
https://docs.python.org/3/tutorial/ ): While I was obviously coming in 
with a lot of programming knowledge, I felt Python's tutorial is very 
well done. Its well laid out index means you can quickly skip around 
when you already know what you want to achieve (but not how to achieve it).


Compare this to the official PHP tutorial ( https://www.php.net/tutorial 
) which to me feels pretty much only covers a basic HTML form. The 
"What's Next" section directs you to http://talks.php.net/ which has 
very limited content from the past 5 years and a lot from before that. 
It also has a theme that hurts my eyes to look at (kind of ironic that 
the "PHP Presentations" site has horrible presentation =P ). The "What 
Can PHP Do" link takes you to a page that is pretty much a wall of text. 
It spends a lot of time talking about things (eg. listing supported 
operating systems) that probably 99% of users don't care about at this 
point as well as linking to effectively dead projects like PHP-GTK.


If you then try to proceed onwards, one of the next things people 
frequently want to do is storing information in Sessions ( 
https://www.php.net/manual/en/book.session.php ) (from my experience 
helping users in the likes of Freenode's ##php ). While I understand 
this section as a long time PHP developer and it does cover a lot of 
technical information, if you're coming into this as a newbie developer 
while you can sort of get some basic session code going on, many newer 
developers do hit / have questions on slightly more complex topics like 
session locks or session file management and are, I believe, quickly 
left with their head spinning.


Python also has a user editable wiki with the Beginners Guide ( 
https://wiki.python.org/moin/BeginnersGuide ) being practically the 
first link after the main documentation links on the Docs section of the 
Python site ( https://www.python.org/doc/ )


I think the entire "new user experience" of PHP could do with review. 
Some suggestions to start:


* Link directly to the tutorial from the front page of php.net
* Look at removing the https://www.php.net/docs.php page and replacing 
it by linking directly to the manual.
  * PHP 4 documentation, "More documentation" and downloads could be 
linked as an / from an appendix.
  * There's already a language switch on the top right of the page for 
swithcing to other languages
* Move contributors to an appendix - it unnecessarily takes up a 
significant amount of space at the top of the manual index forcing users 
to scroll down to the content they want. We're all very grateful to the 
manual contributors, but it's not what 99% of users are there for.
* Link directly to Language Reference ( 
https://www.php.net/manual/en/langref.php ) and Features ( 
https://www.php.net/manual/en/features.php ) from the tutorial


talks.php.net:
* Update links to use HTTPS (minor, but the "Not secure" is still ugly)
* Link from the front page of php.net
* Make it clear and easy for users to submit new talks and otherwise 
contribute 

Re: [PHP-DEV] PHP's declining(?) popularity

[Olumide Samson]

I also don't agree with the index and all its statistics, yet I'm not
invalidating it as it is a much-viewed index globally.

Though, what caught my eyes was this quote which I thought would be obvious
and Mike would have based those fact replies on(Yet I'm also not
invalidating his facts list and IMHO those as well would make sense in
PHP).

According to the index :
 "Till the end of 2009 everything went fine, but soon after that PHP was
going downhill from 10% to 5% market share in 2 years’ time. In 2014 it
halved again to 2.5%.

So what happened to PHP?
>From its start PHP was the Visual Basic for web design: easy to learn, easy
to deploy, but mainly used by web designers with a limited software
engineering background.

The downside of PHP’s simplicity was that it was relatively easy to shoot
security holes in it.

 PHP has been struggling with this for a long time. In 2014 PHP’s biggest
supporter Facebook launched Hack as an alternative for PHP because it was
not scalable.

And after that, JavaScript, TypeScript and Python became the linguas franca
for web development."


These lines caught my eye more than the rest of the quote :

"The downside of PHP’s simplicity was that it was relatively easy to shoot
security holes in it. PHP has been struggling with this for a long time."

These other quotes seems good to watch as it mention one of the biggest
supporters creating an alternative because PHP wasn't scalable at its
current growth stage, maybe we might have been bothering too much about the
past while not remembering the present and future(Which is 100s of years to
come, if PHP is still a thing on the top 50) matters most than the
past(which is just some 15-20 years gone) :

" In 2014 PHP’s biggest supporter Facebook launched Hack as an alternative
for PHP because it was not scalable. And after that, JavaScript, TypeScript
and Python became the linguas franca for web development"

On Sun, Sep 15, 2019, 8:18 AM Zeev Suraski  wrote:

>
>
> On Sun, Sep 15, 2019 at 6:33 AM Mike Schinkel 
> wrote:
>
>> > On Sep 14, 2019, at 5:18 PM, Olumide Samson 
>> wrote:
>> >
>> > https://jaxenter.com/php-tiobe-sept-2019-162096.html
>> > I think this is one of those things we get from voting no...
>> >
>> > I might be wrong anyways :-?
>>
>
> First of all, Olumide, this is in fact wrong, although the general topic
> (language popularity and the reasons to it) is definitely worthy of
> discussion.
>
> The reason it's wrong is that TIOBE is a meaningless 'index' with a
> methodology that's not only questionable - but is rather downright
> idiotic.  It's not just off or inaccurate - it's practically a random
> number generator.
> See for yourself:
> https://www.tiobe.com/tiobe-index/programming-languages-definition/
>
> The RedMonk Language Rankings has a much more reasonable methodology, is a
> lot more stable, and there, PHP is repeatedly at the top 5 languages and
> not losing any steam in both absolute and comparative measures:
> https://redmonk.com/sogrady/2019/07/18/language-rankings-6-19/
>
>
>> If those specific rankings are legitimately a cause for concern then it
>> would make sense to do some objective analysis to determine why the
>> languages that are growing marketshare are growing.
>>
>
> Mike - even though specifically the TIOBE index isn't a cause for
> virtually anything, the rest of your analysis is still relevant - as the
> key takeaway you're basing it on - Python's growth - is also reflected in
> RedMonk rankings.
>
> Thomas - I also wholeheartedly agree with your suggestion.  That's why we
> worked on FFI - to open the door for PHP to enter new areas.  Even JIT is,
> for the most part, not really relevant to the common Web case and would be
> a lot more impactful in other types of workloads.  And there may be other
> things we can do.  But you're right - if we don't find a way to position it
> for these use cases in people's minds - it won't move the needle.
>
> Zeev
>

Re: [PHP-DEV] PHP's declining(?) popularity

[Zeev Suraski]

On Sun, Sep 15, 2019 at 6:33 AM Mike Schinkel 
wrote:

> > On Sep 14, 2019, at 5:18 PM, Olumide Samson 
> wrote:
> >
> > https://jaxenter.com/php-tiobe-sept-2019-162096.html
> > I think this is one of those things we get from voting no...
> >
> > I might be wrong anyways :-?
>

First of all, Olumide, this is in fact wrong, although the general topic
(language popularity and the reasons to it) is definitely worthy of
discussion.

The reason it's wrong is that TIOBE is a meaningless 'index' with a
methodology that's not only questionable - but is rather downright
idiotic.  It's not just off or inaccurate - it's practically a random
number generator.
See for yourself:
https://www.tiobe.com/tiobe-index/programming-languages-definition/

The RedMonk Language Rankings has a much more reasonable methodology, is a
lot more stable, and there, PHP is repeatedly at the top 5 languages and
not losing any steam in both absolute and comparative measures:
https://redmonk.com/sogrady/2019/07/18/language-rankings-6-19/


> If those specific rankings are legitimately a cause for concern then it
> would make sense to do some objective analysis to determine why the
> languages that are growing marketshare are growing.
>

Mike - even though specifically the TIOBE index isn't a cause for virtually
anything, the rest of your analysis is still relevant - as the key takeaway
you're basing it on - Python's growth - is also reflected in RedMonk
rankings.

Thomas - I also wholeheartedly agree with your suggestion.  That's why we
worked on FFI - to open the door for PHP to enter new areas.  Even JIT is,
for the most part, not really relevant to the common Web case and would be
a lot more impactful in other types of workloads.  And there may be other
things we can do.  But you're right - if we don't find a way to position it
for these use cases in people's minds - it won't move the needle.

Zeev