[PHP-DEV] Re: Wiki Access request
> > > Feel free to share this list here, on GitHub or otherwise. I'm > skeptical whether throwing partially outdated resources at people is > actually helpful. > > > - Add a new page in the Github repo with all these links and link to that > > page from the contributing page > > - Keep the list in the wiki and link to that page from the contributing > page > > One of the reasons I'd like to move off of the wiki for these things > is that there is no review process. We highly value volunteer work, > but trusting new contributors to blindly make changes to official > guides is obviously somewhat problematic. > > I'd prefer to make CONTRIBUTING.md the "official list" for now. This > file is allowed to be long. And as mentioned, I suspect that the list > of 20+ items may be trimmed. > > Ilija > > Ilija, I trimmed the list that I collected so that it only included the most significant items which have a lot of information. This list would be: - https://www.phpinternalsbook.com/ PHP Internals book - https://phpinternals.net/ PHP Internals web site with documentation about a lot of the structures and macros used in the code - https://www.npopov.com/ Nikita Popov's blog - http://blog.jpauli.tech/ Julien Pauli's blog - https://phpinternals.news/ Derick Rethans' podcast - https://www.zend.com/resources/writing-php-extensions Zend's guide about writing PHP extensions - https://wiki.php.net/internals The internals page in the wiki - https://www.informit.com/store/extending-and-embedding-php-9780672327049 Sara Golemon's printed book Do you think this sounds good? If you do, I will create the PR to update the contributing doc Cheers Carlos
[PHP-DEV] Re: Wiki Access request
> > > I can absolutely give you write access to these pages. Updating this > list to reflect more up-to-date resources certainly makes sense. > > As you probably know, there are a number of different places where php > internals are documented, and I think that, long-term, it makes sense > to try to consolidate these efforts. We briefly spoke about this in > the last foundation meeting. > > We have some documentation in the php-src repository itself, a > significant amount in the php internals book > (https://www.phpinternalsbook.com/), some in the wiki, some on blogs > of current or previous contributors, etc. There are a number of things > that are important when it comes to documentation, like convenience, > access, history, discoverability, etc. > > While not the worst, I don't think the wiki is the best place for this > work. Handling documentation directly through Git in PHPs main > repository (or at least a repository in the PHP organization) would > likely tick the most boxes. Providing documentation with PRs might > also improve the understanding of intention of the changes for > reviewers. > > As for links to other references, I believe the CONTRIBUTING.md file > is currently the most up-to-date. > > > https://github.com/php/php-src/blob/master/CONTRIBUTING.md#technical-resources > > Rather than duplicating this list on the wiki, it might make sense to > reference the CONTRIBUTING.md file, and extend it as necessary. > > Ilija > > Hi Ilija, I didn't know that there was a list of tech resources listed in the "CONTRIBUTING.md" file. I have been researching resources that have information about PHP internals and have found a lot, more than twenty. I can think of three possibilities: - List them all in the contributing document but this can be a bit overwhelming as, like I said, the number of resources available is big - Add a new page in the Github repo with all these links and link to that page from the contributing page - Keep the list in the wiki and link to that page from the contributing page Please let me know what you think would be the best way going forward. No matter what we do, we need to make sure that this info is collected in a single place and not duplicated. And no matter what we do, the wiki page needs to be cleaned so I'd be grateful if you could provide this access. Depending on what we decide to do, I will clean up the wiki and create a PR for the php-src repo with the related changes Cheers Carlos
[PHP-DEV] Wiki Access request
Hi My name is Carlos Granados and I have been a PHP developer for a long time, more than 15 years and I am quite interested in the PHP internals and trying to learn as much as I can about them This page in the Wiki https://wiki.php.net/internals/references has a lot of links which are outdated and should be removed or changed. If you can provide wiki edit access for me I can work on updating them and also try to find more recent links to add to that reference page (suggestions welcome!!) My username for the wiki site is "barelon" in case this is needed Cheers Carlos
Re: [PHP-DEV] Feature Proposal
This is handled in a more elegant way by the named arguments of PHP8 https://stitcher.io/blog/php-8-named-arguments With that feature you can just pass the parameters that you need and the others will get their default values Barel On Thu, 14 Jan 2021 at 18:12, Anna Filina wrote: > > So if some calling code wants to override a later parameter, it currently > needs to pass a value to the earlier optional parameters. > > I think that this is a code smell that should be addressed by a better > design. Here's a detailed explanation of why one should use default > parameters sparingly, along with alternatives: > https://afilina.com/null-hell > > I feel like such a feature would enable developers to dig themselves > a deeper hole towards unmaintainable code. That's just my 2 cents. > > Anna Filina > > On Thu, Jan 14, 2021 at 12:52 PM Andrew Brown wrote: > > > This is my first foray into PHP internals, so please let me know if I'm > > doing something wrong. Currently just following the instructions from > > https://wiki.php.net/rfc/howto. > > > > Currently this proposal is only a "concept". > > > > I propose we add a "default" keyword that can be passed as an argument > > into a function/method call. This would allow the calling code to defer > to > > the function signature for the value of a parameter. > > > > Traditionally, all optional parameters are placed towards the end of the > > function parameter list, but as we all know, sometimes this order can be > > tricky. So if some calling code wants to override a later parameter, it > > currently needs to pass a value to the earlier optional parameters. > > > > A current solution around this is to define all defaults in the body of > > the function rather than in the signature. > > > > [image: Screen-Shot-2021-01-14-at-11.45.09-AM.jpg] > > > > However, this adds some extra boilerplate, and we can't use default > > parameters as they were really intended. > > > > My proposal is to add a new `default` keyword to be passed as an > argument. > > > > [image: Screen-Shot-2021-01-14-at-11.44.57-AM.jpg] > > > > The first call of the function here is how we currently have to do > things. > > We have to explicitly pass `true` in as the second parameter. > > > > However, in the second call, we now use the new `default` keyword, which > > will defer to the function signature for the default value of `$param2`. > > > > Thanks all, looking forward to some feedback! > > > > -- > > Andrew M. Brown > > >
[PHP-DEV] What is the use of op_array_persist and op_array_persist_calc
Looking at the info for Zend Extensions I have noticed that there are two members in the zend_extension struct called "op_array_persist" and "op_array_persist_calc". Looking at the PHP source code I can see that these hooks are used to add some data in memory to the opcode array but I can't think of a use case for this. Could someone explain what these hooks are for? Is there any example that I could check? Cheers Barel
