Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67618 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31057 invoked from network); 3 Jun 2013 17:31:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jun 2013 17:31:01 -0000 Authentication-Results: pb1.pair.com header.from=rquadling@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rquadling@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.180 as permitted sender) X-PHP-List-Original-Sender: rquadling@gmail.com X-Host-Fingerprint: 209.85.223.180 mail-ie0-f180.google.com Received: from [209.85.223.180] ([209.85.223.180:38945] helo=mail-ie0-f180.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 84/A6-21406-4D2DCA15 for ; Mon, 03 Jun 2013 13:31:01 -0400 Received: by mail-ie0-f180.google.com with SMTP id b11so11146346iee.39 for ; Mon, 03 Jun 2013 10:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=kKhRaeallibeykaaQTXuYvyqhYdY9vSecWc8GBF7Dxs=; b=m2YmzmXmFJp6jKQTps35f7D3BPFdBBrZxBFmXuny34dEC/6SjZvicSS5tJHXC6pv// fspqkKwidjDA9qAFNgISQgoPHde3WlmcFSwkhnydBY3D9GaCLyOm1nHtucqa1Ii3RvUt 4FntiLw/78bbTx6KyNSHJ2jKBBNKjYAgzFCHRiIxFJix08rfz8sjy/r9XelsAwYuZ1Du n2Lhbr9gWGTnX1/TGNVujlRO9O7KO4FIyp+95Ui3ai5Hj8Y5+W+N6q7h67tOmhZqS6Sb ZDpHbbp/3Z4MqIc5NlDX8MCWgcPnP+tqP714+9/h8XQQk5QjWfJtidyMmPrXlYN9SDh1 HhPQ== X-Received: by 10.42.95.147 with SMTP id f19mr11176831icn.24.1370280657534; Mon, 03 Jun 2013 10:30:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.23.5 with HTTP; Mon, 3 Jun 2013 10:30:37 -0700 (PDT) Reply-To: RQuadling@GMail.com In-Reply-To: References: Date: Mon, 3 Jun 2013 18:30:37 +0100 Message-ID: To: Brandon Wamboldt Cc: Nikita Popov , PHP internals Content-Type: multipart/alternative; boundary=485b397dd1cdd5c57404de4353b9 Subject: Re: [PHP-DEV] Random Monday thought. From: rquadling@gmail.com (Richard Quadling) --485b397dd1cdd5c57404de4353b9 Content-Type: text/plain; charset=UTF-8 On 3 June 2013 18:22, Brandon Wamboldt wrote: > I think the point was that if somebody wants to extend one another class, > maybe one of the SPL classes for example, they can't also extend the base > class with getter/setter support so it's an incomplete solution that will > frustrate many users. > > > On Mon, Jun 3, 2013 at 2:20 PM, Richard Quadling wrote: > >> On 3 June 2013 17:55, Nikita Popov wrote: >> >> > On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling > >wrote: >> > >> >> Hi. >> >> >> >> Recently the setters/getters rfc was declined. >> >> >> >> Other than the vote, was there any technical reasons? >> >> >> >> I've been sitting here and had a thought. >> >> >> >> Currently, if I use ... >> >> >> >> > >> class some_base_class {} >> >> ?> >> >> >> >> I can, sort of, think of this as ... >> >> >> >> > >> class some_base_class extends \stdClass {} >> >> ?> >> >> >> >> in as much as \stdClass has no constants, properties or methods. In >> fact, >> >> no behaviour at all. >> >> >> >> Now, could it be possible that I could have another PHP maintained base >> >> class or interface that DID support setters/getters? >> >> >> >> So, I would have to make the decision at develop time ... >> >> >> >> > >> class some_base_class extends \stdClassThatHasSetterGetterSupport {} >> >> ?> >> >> >> >> sort of thing. >> >> >> >> So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the >> >> variable/property handling to be used is the original style. >> >> >> >> But for those base classes that do extend from >> >> \stdClassThatHasSetterGetterSupport, then these would have property >> >> support. >> >> >> >> >> >> Is this even possible/feasible? >> >> >> >> Whilst the vote went against the initial rfc, I'm happy to accept that >> >> (though I wish it had passed as I like the black boxing and the >> semantic >> >> cleanliness it would provide - IMHO). >> >> >> >> >> >> To me, if the internals operated as ... >> >> >> >> > >> class \stdClassThatHasSetterGetterSupport extends \stdClass {} >> >> ?> >> >> >> >> add if that was enough to enable setters/getters, then COULD this be a >> way >> >> forward for PHP supporting new functionality without breaking base >> >> functionality? >> >> >> >> In essence, turning PHP's internals into a sort of OOP framework. >> >> >> >> Regards, >> >> >> >> Richard. >> >> >> > >> > PHP does not support multiple inheritance. So no, this doesn't solve >> > really the issue. >> > >> > Nikita >> > >> >> >> I'm not talking about multiple inheritance, but of extension. >> >> A new internal PHP base class which internally extends from stdClass, but >> is a class that provides additional functionality, specifically >> setter/getter logic. >> >> So, from userland, I can not extend and get the current stdClass, or I can >> choose \stdClassThatHasSetterGetterSupport and get that. >> >> And if I so wish, I can implement >> SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever. >> >> Richard. >> > Ah. DOH! Would having an interface that swapped the default property accessor logic be any better? So, I could say ... Hmmm... I know it is still not perfect. Shame. I really would have liked setter/getter. -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY --485b397dd1cdd5c57404de4353b9--