On Thu, Jan 10, 2013 at 10:17 AM, Nate Tuganov <i...@cloudmill.ru> wrote:
> Hello, > > Well, I've been reading internals for years and never replied. But I think > this time I have to share my thoughts. > > First of all I understand Rasmus and Stas position on holding PHP as simple > as it is. It's great and in the same way it's wrong. As Anthony mentioned > PHP evolves, and PHP is being used not only by designers who want to create > a simple corp site which by the way move to Rails, but mostly by thousands > of web agencies, developers and senior developers who constantly using > different languages and technologies. We have Ruby with all the sugar it > gives, we have Java with all enterprise mess it has. And we have PHP. > > I don't think I need to advocate OOP here, and I agree with Rasmus that we > need to stay simple. But we don't need to copy all those things from Java > for example, even Java world has Play! Framework which is great and gives > simpleness to the developer. We all know how annotations are being used by > Symfony or Doctrine and I don't think we need to create all the mess it has > in Java world. We all know the problems it give, why not to eliminate it > and create a new, PHP's vision of things. Right now all discussions are > being held like we will never implement annotations because we need to copy > it from Enterprise Java. But we don't need Java annotations, we need our > own. Constantly decline great futures just because some designer wouldn't > understand it is wrong by all means. > > PHP is great for web development, let's stick to it. Give us a chance to > create frameworks, which can use Annotations, DI, IoC, Factories, > Decorators and all others patterns to allow regular designer to create a > simple site with few lines of code. > > -- > Kind Regards, > > Ignat Tuganov > Chief Information Officer > > Office Phone: +7 (812) 640-8022 > > E-Mail \ Gtalk: i...@cloudmill.ru > > CloudMill LLC > 191015, 3 K Furazhnyi Lane, office #317, Saint-Petersburg, Russia > hi, another thing to keep in mind: most PHP frameworks out there has a faster development cycle and less of an userbase than us(as every PHP framework user is a PHP user ofc.), so if they make a bad design decision it is usually easier for them to fix it and it has less of an impact and they have more people with the ability to fix up any technical problems, as it is reasonably easy to find somebody with the neccessary skills and knowledge required to fix the problem. of course now that we introduced the new release process, hopefully we will have faster release cycles, and some of the popular frameworks started planning/introducing LTS releases with longer support cycle. but still, we have to be careful about what do we introduce to the language, because we have to support it for at least like minor 3 releases( we introduce it in 7.2, deprecate it in 7.3 and remove it in 8.0 for example). back in the early symfony days using Singletons everywhere seemed like a good idea, currently the general consensus is that it is an anti-pattern, and only in a handful of use-cases is it a good idea using it. similar thing happened with ORMs, first ORM meant pretty much using the activerecord pattern, now the general consensus seems to be to use the data mapper pattern instead. if we too eager to include new hip stuff, it can happen that we will get stuck with a half-baked solution which we have to support years after that the cool guys already moved to something else. the other thing that I mentioned is the difference between the required skills needed to fix up bad implementations: there aren't that many people familiar with the php-internals (and this isn't the easier skill to pick up, as we somehow lack in quality documentation on the internals part), even less people are familiar with the parser, ZendEngine, and APC. just some of the recent examples: - traits was a nice RFC, complete patch, has an active author, years of discussion, and it still needed a huge amount of work/refact to make it play nicely with some edge-cases and with APC. (kudos to Stefan and Dmitiry) - the finally feature: it was almost completely rewritten after the RFC with the initial patch was voted and accepted (kudos to Laruence and Dmitry) - introducing generators also needed some love (a few segfaults in edge-cases AFAIR and making it work together with finally kudos to Nikita and Dmitry). So I think the current problems are the following: - users won't migrate to new php version until some of the top pecl exts having issues with the new version (apc was a really obvious showstopper for the php5.4 adoptation for example). - currently voting is more about wanting the feature or not, and not about wanting/accepting the feature with the current implementation. this can result in situations when something is accepted and merged, but it has to be fixed/maintained, and that sucks when the work happens to require the help of those who voted no based on their understanding on the problems of the proposed rfc/patch. - we don't have enough QA exposure, so some of the problems will only surface after the first final release (the implementation problems of traits for example). - there are key areas where we lack active people (ZE, APC, etc.). - the previous (nonexistent) release process made us really slow on fixing/removing things: http://blog.roshambo.org/a-brief-unofficial-history-about-register_globals-in-php/(it was removed in 5.4.0 which was released 2012 Marc 01.) It took more than 10 years to remove it since the time it was first accepted as a bad decision to include. - the new release process allows/mandates planned and faster release cycles, but it also means that we can only remove features in major version jumps, which would either result in more frequent major feature bumps or long gaps between times when we can remove features. - and yeah, I think that php means a lot of different things to a lot of different people, so most of the times there can and will be arguments whether or not it is a good idea or the 'php way' to include something. but as long as we resolve those conflicts in civil manners and not using some kind of fallacy (or making intentionally confusing/incomplete RFCs and pushing through them the voting) it should be fine. Sorry for the wall-of-text: 'If I Had More Time, I Would Have Written a Shorter Letter' -- Ferenc Kovács @Tyr43l - http://tyrael.hu
