Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64918 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77912 invoked from network); 13 Jan 2013 14:02:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2013 14:02:01 -0000 Authentication-Results: pb1.pair.com smtp.mail=markg85@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=markg85@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.54 as permitted sender) X-PHP-List-Original-Sender: markg85@gmail.com X-Host-Fingerprint: 209.85.219.54 mail-oa0-f54.google.com Received: from [209.85.219.54] ([209.85.219.54:36462] helo=mail-oa0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0C/40-09741-85EB2F05 for ; Sun, 13 Jan 2013 09:02:01 -0500 Received: by mail-oa0-f54.google.com with SMTP id n9so3236474oag.13 for ; Sun, 13 Jan 2013 06:01:58 -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=SblBBSMEQKNTOM04c73Ifh9EV6kSfejs+UCVHbuLcb8=; b=y0vUx2MQ0FhcYoesEAyp7bmgdTquEH9Prl9N3No3xt5ZVR0IfocVefcvvZ2aFj6Tc5 pYJ0CwVTm1DRZVBkybDQ/bVqhPBsyodQK2RLByPoBFTS4SBhb1RG/+eoPa0QNJSUjSj4 +ena6lHLI9EQ42L3i4xcZiR9JLLqtLhCodJGrjyBdJYYsD4F36JTliipH/wbujVZcKIg QyvP7NzlgIu42ILzHs4HRqg9Q2rZgaZqAwEBDC93wzm7/LYlPE7Fp56N0YF1iPZVPlZW sBjT3Og6xqmTLJka9hn6NtS7VzFYjhGW+ZA3jlMsuH+u6ZhawVj2Hoa/8YHZK57uDjkS dWGQ== Received: by 10.182.218.37 with SMTP id pd5mr59302240obc.24.1358085717980; Sun, 13 Jan 2013 06:01:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.78.65 with HTTP; Sun, 13 Jan 2013 06:01:37 -0800 (PST) In-Reply-To: <50EFBA6F.90702@sugarcrm.com> References: <50E41BB6.4030901@zerocue.com> <50E648BE.2060005@zerocue.com> <50E6822D.9060807@sugarcrm.com> <71B3F435-4289-473B-B4D7-EB2DB5F888A9@zerocue.com> <7213E637-26A2-4F44-82DE-297E751726CD@zerocue.com> <50E6F501.4090806@zerocue.com> <50E75658.6050006@sugarcrm.com> <50E79D16.1090905@zerocue.com> <50EF56BD.3040608@sugarcrm.com> <50EFBA6F.90702@sugarcrm.com> Date: Sun, 13 Jan 2013 15:01:37 +0100 Message-ID: To: Stas Malyshev Cc: Nikita Popov , Clint Priest , PHP Developers Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue From: markg85@gmail.com (Mark) On Fri, Jan 11, 2013 at 8:08 AM, Stas Malyshev wrote: > Hi! > >> Re the ReflectionProperty::getParentProperty($this, 'foo') suggestion, >> is this supposed to already get the value of the property (and there >> would be an additional method ReflectionProperty::setParentProperty)? > > I meant getting the ReflectionProperty class, but getting the actual > value is an option too. Of course, then it should be method on > ReflectionPropertyAccessor, since regular properties don't have this > thing. I'm not sure which is better - it depends on how much this would > be used. We could even not do anything special at all - as I said, > current reflection already has API to allow doing exactly this (well, > after property support is added), even if a bit long-winded. > >> The current property can be obtained through >> EG(current_execute_data)->function_state.function. This holds the >> accessor function and the property can be taken from its name. Though >> this is obviously all a bit dirty and is probably not a good idea. >> Probably better to let people explicitly pass the property name. > > I agree. That's why I also mentioned having __PROPERTY__ - this makes > copypasting methods a bit easier since you have less chances of making > typo in property names :) > -- > 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 > I'm guessing this RFC won't make it in PHP 5.5? Too bad since it did seem like a very nice feature to have. I don't know if it is very helpful but posting nevertheless. I'm a C++/Qt/QML/PHP developer and for me the proposed syntax in the v1.2 document makes perfect sense and is intuitive to use. As for the earlier example about isset... i'd expect an example like this: class SomeClass { public $date { get; set(DateTime $date); } } $temp = new SomeClass(); i'd expect "isset($temp->date)" to return exactly the same as if the class where defined like this: class SomeClass { public $date; } I don't know if that issue was already sorted out but i wanted to share my expectations in that regards. Will this make PHP 5.5? Or will it be deferred to 5.6?