Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63439 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13845 invoked from network); 16 Oct 2012 09:37:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Oct 2012 09:37:00 -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 207.97.245.203 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.203 smtp203.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.203] ([207.97.245.203:49175] helo=smtp203.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 84/37-10021-ABA2D705 for ; Tue, 16 Oct 2012 05:36:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp40.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B883E35029B; Tue, 16 Oct 2012 05:36:55 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp40.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D5E9335029D; Tue, 16 Oct 2012 05:36:54 -0400 (EDT) Message-ID: <507D2AB5.1000903@sugarcrm.com> Date: Tue, 16 Oct 2012 12:36:53 +0300 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Clint Priest CC: "Nikita Popov (nikita.ppv@gmail.com)" , "internals@lists.php.net" References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local> In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I think that accessors should be allowed with interfaces because an > interface really is a specification on how to communicate and while > accessors do pass messages, properties do not. "Communicate" is a loaded term. Property access is communication too, but properties aren't defined in the interfaces. In any case, if you're allowing accessors in interface, you should bring back automatic implementation of accessors, since if you're saying "you must provide property $a" I should be able to say "OK, here's property $a, working exactly as plain old PHP property". Either that or I'd have to write a boilerplate code (and make a couple of errors on the way such as breaking references and isset, which 99% of less-experienced PHP programmers would do). I think accessors in interfaces are a huge can of worms because of their potential of mixing function calls and property access, while the latter is traditionally not the domain of the interface. We should carefully consider if we really have use case for it. Especially given that PHP always has underlying default property access functionality that is always available - unlike methods which if not defined lead to fatal error. So while if you do $foo->bar() on wrong $foo it will break, if you do $foo->bar on wrong $foo yu just get default behavior. Given that, do we really need an interface there? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227