Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63726 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58669 invoked from network); 30 Oct 2012 23:07:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Oct 2012 23:07:07 -0000 Authentication-Results: pb1.pair.com header.from=ekneuss@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ekneuss@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender) X-PHP-List-Original-Sender: ekneuss@gmail.com X-Host-Fingerprint: 209.85.220.42 mail-pa0-f42.google.com Received: from [209.85.220.42] ([209.85.220.42:57685] helo=mail-pa0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D7/30-56709-79D50905 for ; Tue, 30 Oct 2012 18:07:03 -0500 Received: by mail-pa0-f42.google.com with SMTP id fa1so513355pad.29 for ; Tue, 30 Oct 2012 16:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=64GlT4Gc6nRt7bKOoLvpw5qX3ajE1Cu1yqlQVEkh29Q=; b=F6UoFzw18QOyTByLLZW7nm99Gne79CZsjAegMYiFzfwU0P1BmhdF6+jj5Uufjhf9CK 4So3t+fNBkNSWYmnBvYE7UZXjKJgtVpDGtBxzImLLQd/3AkrUowi727I64X2XNsdmOe1 s2JaD2eR6ytHhqZyD47E0ji2R5Hxd+gBmFFOd9erlrM2k4BoLlJbNgdiM9VOcMSA30am BAIZOKS8hv06/DKwKfxDky8sMR3dupwB/QCIaCxfEFEDBks9j/KEjipRHT/QHDZObGP6 vq9F4aI8Ztf7BxrnA9zyXmkG1PcNUWF81pwp4ipSLvClJadb/uUtI1YMO0wYpU8Q4QHF QEow== Received: by 10.68.137.228 with SMTP id ql4mr107669135pbb.125.1351638419356; Tue, 30 Oct 2012 16:06:59 -0700 (PDT) MIME-Version: 1.0 Sender: ekneuss@gmail.com Received: by 10.68.144.42 with HTTP; Tue, 30 Oct 2012 16:06:39 -0700 (PDT) In-Reply-To: <50904C0C.8030207@sugarcrm.com> References: <508A67E6.2000405@zerocue.com> <508A9AC9.50200@sugarcrm.com> <508AF3E7.7020004@sugarcrm.com> <508B1EA2.8060203@sugarcrm.com> <508C249D.1000309@zerocue.com> <508C43ED.9000209@sugarcrm.com> <508C80C6.9000008@zerocue.com> <508CD916.1070509@sugarcrm.com> <508D5462.4070503@zerocue.com> <508EFB76.4080604@sugarcrm.com> <50904C0C.8030207@sugarcrm.com> Date: Wed, 31 Oct 2012 00:06:39 +0100 X-Google-Sender-Auth: wwrCsYDfMrBvxFQGRcKqubIAgAE Message-ID: To: Stas Malyshev Cc: Nikita Popov , Clint Priest , PHP Developers Mailing List Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability From: colder@php.net (Etienne Kneuss) On Tue, Oct 30, 2012 at 10:52 PM, Stas Malyshev wrote: > Hi! > >> Stas, you seem to have missed the point behind my mail. This wasn't >> about what the exact details of the implementation will be, the >> message was that the semantics of a dedicated accessors syntax and the >> semantics of a magic implementation can not match. > > I see your point now, thanks, but I don't think I agree. > >> >> E.g. assuming that magic accessors take priority over properties as >> you want it this time I can just turn the examples around: >> >> class A { >> public $foo { get() { ... } set($value) { ... } } >> } >> >> class B extends A { >> public $foo; >> } >> >> => Here I would expect that public $foo from class B overrides public >> $foo from class A. > > I'm not sure why you are expecting this, and also this is probably an > LSP violation, since such override would change semantics of the value > that A clients expect. It may be possible to implement, technically, but > I'm not sure it's the right thing to do. Why would it be not expected and/or a violation of LSP? Accessors impose stricly more restrictions than properties. This code is fine. Just like it is fine in theory to have interface A { public $foo { get(); set($v); } } class B implements A { public $foo; } > >> Basically any kind of interaction between properties and accessor >> properties will be broken and inherently so, simply because magic >> methods are not real properties (quite obviously...). > > Magic methods are not properties, they are implementation of properties. > But your properties aren't either - see discussion about interfaces, > etc. They simulate regular properties but they aren't regular > properties. E.g., what would happen if you serialize an object with > simulated property? > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Etienne Kneuss http://www.colder.ch