Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64854 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2418 invoked from network); 11 Jan 2013 09:06:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jan 2013 09:06:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=dukeofgaming@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=dukeofgaming@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender) X-PHP-List-Original-Sender: dukeofgaming@gmail.com X-Host-Fingerprint: 209.85.223.181 mail-ie0-f181.google.com Received: from [209.85.223.181] ([209.85.223.181:60923] helo=mail-ie0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C5/D8-02684-136DFE05 for ; Fri, 11 Jan 2013 04:06:58 -0500 Received: by mail-ie0-f181.google.com with SMTP id 16so2004006iea.26 for ; Fri, 11 Jan 2013 01:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LBgK3bp8cvRHQm0WaTLIGbnc/Ak/n2qrNOIaj1SqYMc=; b=NJi1m5WvbvTWmbtEaX8gVvJbP2qwT21d99pURM5eoexRQr0r2ISqn2lF7+84f4d1kX aFqZ1odKS/ACP+2dsYvM5l+0MHTDXxhitxFpmdr9lnIpQqwwPPFkPqumh49xAq+7zcW9 BIiVoVc2bZLjCvp/raZneNnBRi5vZj+x+awlDSNidvT28zDlkKKxG9dj8PGhckAYpofQ 6+ys/o0mfdulbbN/7Wu/2t7ky7glHag3lZMht7W1PlQ9f52FTptOxCblYJjb8X/IMG62 NaxKgCXgKl1ANw7IsMGZ8U5hOEjowWJLVYr0Vr1hgIRX/thzK0T2OhmHGVLca7FyfZqe re/g== Received: by 10.43.82.72 with SMTP id ab8mr47343887icc.33.1357895215759; Fri, 11 Jan 2013 01:06:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.46.225 with HTTP; Fri, 11 Jan 2013 01:06:35 -0800 (PST) In-Reply-To: <50EFB89B.5080202@sugarcrm.com> References: <50EDBEA5.1050201@sugarcrm.com> <50EE5DAF.2080901@sugarcrm.com> <50EF2195.3080907@sugarcrm.com> <50EF49AF.9050801@b1-systems.de> <48412E0A-3FCC-440D-8479-39B666EB7213@gmail.com> <50EFB89B.5080202@sugarcrm.com> Date: Fri, 11 Jan 2013 03:06:35 -0600 Message-ID: To: Stas Malyshev Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=bcaec51866d8fa423704d2ff9dd9 Subject: Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision From: dukeofgaming@gmail.com (dukeofgaming) --bcaec51866d8fa423704d2ff9dd9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 11, 2013 at 1:00 AM, Stas Malyshev 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 > --bcaec51866d8fa423704d2ff9dd9--