On Wed, 2013-09-11 at 16:15 +0200, Florin Patan wrote: > There's also little to no documentation on how to setup your work > environment for developing something for PHP, I've started to do > something about that but it's not like I'm a experienced user in > this....
Issue 1: There is no single work environment. People use different operating systems, compilers, debuggers, editors, ... http://php.net/git.php lists some things developers need, php.net/install tells how to compile it. Yes, that can be streamlined, but the tool choices above we can't make and a tutorial on gdb also is out of scope. I was once writing a few chapters for http://php.net/internals2 but that got somewhat stalled, this should be the place to document PHPisms though. > Funny thing is that I'm comparing the C code of PHP with code written > in PHP, take Symfony2 or Zend Framework 2 or all the other new > libraries and frameworks since 1-2 years ago. For most of them, anyone > can contribute to code in a couple of hours for minor / medium things > and for more complex ones it can take more. Yes that is funny ;-) PHP and C are different languages, they use different paradigms and have different approaches. If you have no experience in C it can be steep, if you have you will recognize many things. put in another way: For contributing to symfony you have to know the service container structures to contribute, for PHP you have to know your way around macros and function pointer tables. > In PHP you don't have a > clear structure, you don't have documentation in sources, there's no > documentation on how to follow the execution of PHP from where it > starts to parse a file to where it starts to write the output to the > webserver. You have to dig it out from various sources scattered over > the Internet and from some old articles from 2006. > > And yes, once you get to understand something about the architecture > of PHP itself then you can start to say it's ok but the learning curve > is very big. You have to know that the "Zend Engine" in Zend/ drives it and decipher SAPI as Server API. Within Zend/ most files give a good indication on what they do, as do the directory names in SAPI. And how steep the learning curve is, I don't know. It took me a night about 10 years ago from my first look at the engine source till I had operator overloading implemented in a simple way. (I was lucky so as zend_operators.h sounded quite lie a place I had to touch, and zend_lanuage_scanner.l/parser.y was easy enough too) I wouldn't expect anybody to come in and being able to directly implement anonymous classes or such. The learning path imo should be to first write an extension for some lib or something. doing this is relatively well documented in books and examples etc. but gives some entrance and from there dig further. > >> Where Zend | The PHP Company? It's their name, no? They are making > >> money out of PHP brand, certifications and training? > > > > So can you. So do others. > > I thought I can't use the PHP name without the PHP permission. Also > I'm making money out of it as programmer but the money was not the > point. It's complicated but PHP is no registered trademark. I also know that The PHP Group, which holds PHP's rights, approved different name usages. Not 100% matching but related: http://www.php.net/license/index.php#faq-lic http://www.php.net/download-logos.php > I'm asking this list to consider either asking Zend or some other > entity to be more involved in actual language decisions / roadmaps. Why should I ask a company with their business interest to do that? > Do you know what will PHP 5.6 have in it? How about 5.7? Will there > even be one? Or we'll finally start thinking of having Zend Engine 3 + > PHP 6? Well, a roadmap would be nice. But that requires that we can actually rely on it. Mind that most here are doing this (partly) besides their jobs. There are so many things that can happen that people promise to work on stuff but then change jobs, get a girl/boyfriend, a child, illness, ... Other projects make stronger promises by having companies which can "replace" people, but PHP is driven by people not companies (in my personal opinion for good reasons) And even with languages where companies are stronger involved roadmaps mean little already: Java modules were pushed from Java7 to Java 8, and now were pushed to Java 9. In C++ modules were dropped from C++0x (which became C++11) and won't be there for C++14 unlike, hopefully, Concepts which were planned for C++0x, too. > But maybe that's the point. We should have only one vision not none or > many. Look at GO, Python, Ruby, Java, C or whatever. They seem to be > fine with that, no? Go has the vision "Do what Google needs" Java has the vision "Do what Oracle wants" (yes, there is the JCP) C development is really slow and C99 is still barely available and used. For Python and Ruby I now too little to comment. > Look at the list here: > http://www.reddit.com/r/PHP/comments/1iw0cj/what_would_you_change_about_php_if_you_could/cb9rzw4 > I think all of them would be nice to have in PHP for us, the common > PHP programmers, and maybe for the core devs here as well. [...] A major issue we have is that our userbase and developer base are quite distinct groups. And this will always be the case due to language etc. reasons I mentioned above. To make this a it more subjective: As I mentioned in the Zend comment in my previous mail I think going to userland and innovate there is way more useful than doing everything in core. In Frameworks ever user has the required knowledge to innovate and contribute. PHP has to be a base foundation which is reliable and stable so people can easily update and use it. Things added to PHP should be clearly for performance or as it really enables something that otherwise can't be done. For everything else there are frameworks. And now you know my vision, for which I'd rather kick out things than add many of the recent RFCs. ;) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
