Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64801 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8338 invoked from network); 10 Jan 2013 06:49:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jan 2013 06:49:37 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 173.203.6.147 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 173.203.6.147 smtp147.ord.emailsrvr.com Linux 2.6 Received: from [173.203.6.147] ([173.203.6.147:44575] helo=smtp147.ord.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 30/81-02684-C746EE05 for ; Thu, 10 Jan 2013 01:49:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id A14EF270106; Thu, 10 Jan 2013 01:49:29 -0500 (EST) X-Virus-Scanned: OK Received: by smtp15.relay.ord1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 2E7B42700CC; Thu, 10 Jan 2013 01:49:29 -0500 (EST) Message-ID: <50EE6478.6010006@sugarcrm.com> Date: Wed, 09 Jan 2013 22:49:28 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "guilhermeblanco@gmail.com" CC: "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about > acceptance of new features. I can answer only for myself of course, but I don't have any single "criteria". I look at the feature, how it can be used, how it can be abused, how it would be seen by experienced PHP developer, how it can be seen by novice PHP developer, how easy is to understand what's going on, how much impact it would make on performance and robustness of the language, how easy or hard would be for tools to support it, etc. etc. - and then discuss with authors and decide if I'd like to have such thing or not. > I wonder how Annotations is different from Traits or Aspects. I'm not sure what you mean by Aspects, but traits are different from what was proposed as annotations because they are much simpler both conceptually (you just put a couple of methods from one class to another, same thing you do with inheritance but without full-blown OO "is-a" contract) and syntactically. If annotations were at the same level, I'd not have much problem with them, not at all. However, what is proposed is more akin to sub-language, with its own syntax, complex expressions, nested object instantiations and all this has to happen in some weird space which is both code and not code. And of course it should also have syntax that is both different from any other language that does the same, looks like completely different syntax in at least two other popular programming languages and two popular markup languages, and is chosen by principle of "which symbol didn't we use yet?". This seems to me a wrong way to do it. Not because I'm opposed to the idea in principle, but because I'm opposed to how it is done. > Or will you guys claim that Traits will be vastly used? I have no idea. We will see. How can I know what a million of people will be doing? > Also talking about widely used support, I wonder about how > SplDoubleLinkedList, SplInt, SplMaxHeap and all these classes that have > very specific usages, just like also data structure readers like > json_decode, parse_ini_file are part of the core while others also used as > much as these ones like yaml_file are out. I'm not sure what you're getting at here. If you think we need to add YAML extension to core packages, please write an RFC, explain why is this extension good enough and required, have a vote and we'll see. I'm not sure why you're bringing it in this topic. > You guys may now know, but 9 out of 10 most used frameworks are entirely > OO. It's a shame that because Yahoo code is procedural (worked at Yahoo > already), SugarCRM code has terrible OO decisions (I've seen its code), > adopting exceptions handling !!!in July 2012!!! that makes you guys say > there's no need to improve on OO features that community is claiming. And I can't even begin to understand what you are talking about here. Nobody ever said there's no need to improve on OO features, and how SugarCRM code has anything to do with anything it's just beyond my comprehension. That doesn't mean we need to get anything any OO language has into PHP. Some of it is good for PHP, some of it would be better done differently. > 10 times. Isn't it a sign of a feature demand? I know that some folks want to have syntax like this: @MyApp\Acl({ "allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}), "deny"=@OtherApp\Acl\Deny(default="*", log=true) }) and even more complex to be part of PHP function and property definitions. I think it is misguided on multiple levels. That does not mean some metadata support won't be useful - it probably would be. But not this way. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227