On Fri, Jan 11, 2013 at 1:00 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi! > > > I have a question, maybe it is dumb: why not those opposed to using > > annotations just... refrain from using them? > > We've been there before. You seem to be thinking as a person who only > writes software for himself and has to deal with software only written > by you. However, not everybody has such luxury. Once you start dealing > with bigger projects, language environment and language ecosystem starts > to matter, complexity of the code and complexity of what is being done > with the code starts to matter. If some code is too complex to be > properly understood, it will contain hard to find bugs, it will be > misused, it will be routed around in weird ways due to the fact people > don't understand how it works, and in general it will be a pain to all > around. Basically, it will be a piece of closed source in an open-source > project. And people will hate us for imposing this onto them. > So while "don't use it" may work with isolated features (nobody objects > to mongodb extension because they don't use mongodb), for language > features it does not work. Once it is in, you're stuck with it as a part > of your ecosystem. And since PHP has deep BC traditions, you are stuck > with it next to forever. > > You make the wrong assumption on me, I'm not familiar on PHP's source, but I had assumed that horizontal reuse (Traits) would have been more complex. You make a very sane argument and I agree on the selective process, however, every time I read internals it seems that the general attitude is: "please don't add more to it" Is the PHP codebase in a bad place such that is hard to add to it?, I mean > > Also, to maybe put things in better perspective and discourage visceral > > vote (because the topic will keep arising until the end of times, I'd > bank > > on that) why not make a list of pros and cons to adding this to the > > language? > > Did you read the past discussions about the topic? There was a lot of > argument outlined about pros and cons. > But it is not documented on the RFC. New people that come into internals suggesting annotations because they've had a first world experience with them in other languages most probably wont sit and search for all mailing list discussions on the topic and spend hours going through them to make a detailed analysis on why yes or why no. I care for PHP, but I don't really have the luxury of spending that much time on reading heated debates with all sorts of arguments where no agreement seems to happen. > > > Finally, I remember the lack of support for development has been a > > problem... so why not call out for support to the community?, from GSoC > to > > PHP gurus litterate on Comp Sci and software engineering and > architecture? > > Please note that whoever you call out for will have to support this for > years to come. You probably can write an extension and then just drop it > out there and move on and let others deal with support. Even then > doesn't work that well but at least with extension the problem won't be > acute and will be localized. But with language core part you need > commitment for at least several years, otherwise it would just be piece > of buggy and clunky code that nobody can touch. > Why the pessimistic outlook?, I thought the intention of open source software was to have people to gravitate towards the code and add value to it (and adding to it also means cleaning) Again, I understand, but then again PHP is under version control, Git IIRC, you can have that live in a branch and not integrate it unless it meets certain standards, but why not give it a chance to fail? Class metadata and annotations definitely are not a bad idea and that can be factually proven. Whether or not they can get to a decent shape or gather enough support, that is another deal. What I'm saying is: don't reject a proposal on the suspicion that it might not get development support and that you don't want to support it, let it sit in a corner until someone picks it up, and if no one picks it up, no harm done. Who knows, you might get a long-term maintainer from one of those proposals because he/she lives that need every day and has the knowledge to execute it. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >
