steve wrote: > Like a founder of a company that sets the corporate culture, don't > count Rasmus out so easily. Founders earn such power. Until they are > booted. It is not going to, nor should it, happen here.
I don't think PHP has an Ulrich Drepper or a Linus Torvalds. When I read this list, I see Rasmus arguing on equal terms with other developers, he doesn't arrogantly pull rank. I think that's good, because Rasmus is very conservative, and I think PHP has a lot of potential that he doesn't see. Rasmus Lerdorf wrote: > This isn't about server costs. It is about choosing the right tool for > the right part of the job. A Javascript library for the client-side > frontend, PHP for the server-side frontend, C/C++ for your middle-layer > and an appropriate datastore behind it all and you can build amazing > things with PHP. The largest destinations on the Web today are written > exactly like this. > That's not the world I live in. I work on a pure-PHP application which is widely used on servers where the installing user does not have the ability to change their php.ini or to install extensions or middleware. The same application (with a few small extensions in C/C++) is used to run one of the largest destinations on the Web. It all works just fine, and you sell PHP short when you imply that it can't do this. We're not going to fork MediaWiki just because you think it can't be done: it can be done and we're doing it. It all works beautifully: we have volunteers from the Wikimedia side, and volunteers from the external installation side, and they work together to develop features that are usable by both. The small amount of money Wikimedia has comes mostly from individual donors interested in seeing Wikipedia continue. It would be imprudent to spend it all on software development without at least trying to attract volunteers who, instead of donating money, can donate their time. > And yes, there are obviously ways to reduce the overhead > with custom datatypes, but it makes things more complicated because, as > I said, PHP is glue. By having a single datatype that all the > extensions understand, everything can talk to everything. Once you > start moving away from the single zval approach towards different > datatypes for different purposes, you have to retrofit all existing > extensions to teach them how to treat these new datatypes and it makes > the already too-complicated extension API even more complicated which > would hurt the glue aspect of PHP. > > Quite so, but I didn't actually suggest anything which would break source compatibility with the bulk of extensions. * I suggested having a vector-like mode for hashtables. This could be implemented while maintaining compatibility with the usual insert, find and iteration macros and functions. Only extensions which access the HashTable structure directly, such as ext/standard/array.c, would need changes. * I suggested having a more compact, variable-length zend_op. There are very few extensions that access zend_op, just things like reflection, APC and parsekit. * I suggested compact object storage for objects which have the same set of member variables as their class declaration. This could probably be implemented in the default handlers without touching the rest of the code. The original poster suggested an optimisation pass post-compile, which obviously doesn't break anything because there's extensions that do it already. So I don't know who you're arguing against. -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
