On Wed, Sep 11, 2013 at 2:35 PM, Johannes Schlüter <johan...@schlueters.de> wrote: > On Wed, 2013-09-11 at 12:44 +0200, Florin Patan wrote: >> - having a RFC to make a language change requires to have a patch >> which if you don't know C and internals you got no chance of doing. > > Well, so what should happen? An RFC without patch is accepted and then? > Somebody has to write a patch at some time. Whom of the people spending > their free time do you want to force to do that even though they might > not be interested in the feature? > > Getting a patch first > > * proves feasibility (yes, I love saying "It's just software > everything is possible" ... but then there's always a "BUT") > * shows technical consequences of a feature > * shows that there is somebody who is interested in developing AND > probably maintaining the patch (if somebody with a good idea can > not convince a single developer how will this be maintained?) > * allows users to actually test a feature and find problems which > might not be that obvious from theoretical examples > > Yes writing a good patch can be lots of effort, and it might be dumped, > but for most features the initial patches aren't that big.
Agreed and I respect that but if PHP doesn't provide the framework to enable people to contribute to it then how do you expect to have someone to maintain it? If it's a pita to do something simple, as you say, then there's really no incentive for people to help out. And coding around like a headless chicken can and will result in potential bugs that might not be obvious even when people will review it then what? As a note, I've asked Sara and Nikita for help with the return type hinting for functions/methods patch before the official RFC, which I hope I'll be able to finish sometime soon but if a RFC like that would be approved and posted on a roadmap then a core dev or a newcomer (like me) pick it up and try to work on it. When deadline for feature freeze comes and some approved RFCs are not done then the devs should implement them then proceed with bug fixing and testing like usual. It would mean a larger feature freeze window and people willing to work on features that they don't propose. Look at the current PDO stack. Does anyone maintain it? Yes/No/Maybe... What will happen with the changes added by Anthony in 5.5 now that he left? Someone will assume the role of maintainer for them? In a good open-source way there should be a maintainer that's named by the group but everyone should be able to fix them given the right tools. 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.... >> And if you do know C, PHP internals will drain the soul out of you >> before doing something > > Comparing PHP with other C projects I've seen the code isn't as bad as > many people make it sound. Sure we have some "weird" macros, but for > many of those: What's the alternative? (C++11 would allow some > improvements here and there but create a whole lot of other issues) Sure > we have some creepy areas: That happens, when a project grows over more > than 15 years, when sometimes not so good developers add things, > sometimes people try to optimise things for performance and often try to > keep a good BC story (even on internal APIs) But overall PHP is a > modular quite structured code base. 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. 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. > > >> - there were patches proposed by Facebook, and others, that are / were >> rejected, delayed or ignored. Who heard of Facebook anyway, they have >> just one website with a billion users probably running on a a couple >> of Galaxy Note 3 and 2-3 iPhone 6 as a load balancers, my cat can do >> better I tell you. > > Facebook has active contributors who can push anything and know most > "core" people well enough. If anything they want is falling under the > floor they probably don't want it that much. Also mind: Facebook is > *one* usecase. Not everything which is good for them is necissarily good > for other users. And we have a multitude of users. Some want afast and > slick platform, some want many advanced features, some want it to be > simple. What we have to do is to find the "right" line ... oh, and mind > they are not using PHP but hipHop. Facebook is one example that quickly came to my mind. Indeed some of their use cases might not be applicable to the majority of users. >> 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. > >> They've added the opcode cache and that was the single biggest thing >> they've did in 7 years? Feel free to correct me if I'm wrong. > > They are active in fixing bugs and improving the performance and other > things. Sure they are not propose many new features but maybe (I'm an > outsider and can only speculate) they have noticed that with a fast > enough platform offering lots of language features you don't have to do > all things in the core but can build the environment around the core > language by building frameworks and tools and benefit the platform more > in that way. (while also making it simpler to develop and ease > participation as each framework user should now PHP and can therefore > help with the framework) but having said that: Ask Zend, not this list, > if you want something from Zend. I'm asking this list to consider either asking Zend or some other entity to be more involved in actual language decisions / roadmaps. 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? > > > This all said: I agree that some structures here are bad and might be > improved but mind one thing: This community is quite open (everybody can > subscribe to this list and participate, and often git accounts are > thrown out relatively fast) which leads to a quite heterogeneous field > of people all having different interests and aims (as I mentioned above > already), you criticize this as "missing vision", one can see the same > thing as "too many independent visions" - everybody here has a reason > and goal of some kind for his/her contributions. Aligning them all the > time is tough and requires compromises. Constantly. But you won't find a > single vision which a majority would support and which wouldn't drive > too many contributors away while still deserving to be called a vision. > > johannes > > 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? 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. Even with that list in mind, there's no clear way to do it. The core devs are so few that they are, for good reason, against a total redoing of PHP. The new people can't turn into core devs unless someone holds their hands for a while and then they either leave, see Anthony, @lsmith and others, either don't want to change anything anymore either start not to care. And just look how off-topic this went into discussing for the nth time if PHP should move to a forum instead of mailing list. If there should be moderation in that or not. If core devs would be happier if noobs wouldn't interfere with their work and so on. Having a clear structure, a good framework to enable people to contribute would solve maybe half of them only but would still be a good chunk of issues that wouldn't need to be addressed by core devs in the first place anyway. ---- Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
