Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63294 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50645 invoked from network); 9 Oct 2012 07:46:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Oct 2012 07:46:40 -0000 Authentication-Results: pb1.pair.com header.from=christian.kaps@mohiva.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=christian.kaps@mohiva.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mohiva.com from 80.67.29.7 cause and error) X-PHP-List-Original-Sender: christian.kaps@mohiva.com X-Host-Fingerprint: 80.67.29.7 smtprelay03.ispgateway.de Linux 2.6 Received: from [80.67.29.7] ([80.67.29.7:42463] helo=smtprelay03.ispgateway.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 17/54-23861-B56D3705 for ; Tue, 09 Oct 2012 03:46:37 -0400 Received: from [80.67.16.116] (helo=webmail.df.eu) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1TLUWP-0000KT-0A for internals@lists.php.net; Tue, 09 Oct 2012 09:46:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 09 Oct 2012 09:46:32 +0200 To: In-Reply-To: References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local> <5073328D.5000002@gmail.com> <50735165.8010703@aaronholmes.net> <9570D903A3BECE4092E924C2985CE485612B4353@MBX202.domain.local> Message-ID: <760ab4f994a78a846cf86aafda71e0e2@mohiva.com> X-Sender: christian.kaps@mohiva.com User-Agent: Roundcube Webmail/0.8.1 X-Df-Sender: Y2hyaXN0aWFuLmthcHNAbW9oaXZhLmNvbQ== Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 From: christian.kaps@mohiva.com (Christian Kaps) Hi, typehinting should definitely be available for this feature. But I have another question. Why not go more consistent with the rest of the language? I have mentioned this previously as the first proposal comes up on the list. In my opinion the AS3 getter and setter syntax(http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb) fits more into the language as the proposed one. Here are my concerns: - I do not like the extra indentation level and it's ugly to document (OK, this is a personal preference) - It isn't possible to declare a private setter and a public getter, as it is possible with methods - If we ever get return type hinting/checks then we needn't consider how the syntax has to look - We must deal with two different syntaxes for the same thing, because both are methods - IDE's, documentation tools, static analyses tools or similar tools have a huge effort to implement this syntax. With the method syntax it's only a small effort - We have to create new rules about how the documentation for this syntax should look like For me the following syntax seems more consistent with the rest of PHP: public get hours() {} public set hours(DateTime $dateTime) {} public isset hours() {} public unset hours() {} Or: public function get hours() {} public function set hours(DateTime $dateTime) {} public function isset hours() {} public function unset hours() {} Or: public function get $hours() {} public function set $hours(DateTime $dateTime) {} public function isset $hours() {} public function unset $hours() {} Cheers, Christian Am 09.10.2012 05:08, schrieb Jazzer Dane: > While I understand your concern with set being the only keyword using > (), > and even agree it's a bit problematic, I see a big problem with using > $value. > > Even if $value internally makes sense due to something along the > lines of * > __setHours($value)* {} being equal to *set {}*, I think using $value > without it ever being defined in the developer's code is not at all a > good > idea. > If I see $value in the code, I'll logically look for where it was > defined, > and when I don't see it anywhere else in the code, things are going > to very > quickly get confusing. > Our best option to combat this confusion is, in my eyes, putting a > note in > the documentation. That's not enough. > > A similar alternative to using $value that I'd argue would be much > more > sensible would be to, as Denis mentioned, use either a magic constant > or a > superglobal. > > As I mentioned previously, I would rather go with the set($value) {} > syntax. > > Now, back to the part where I agree with you - the inconsistency > wherein > set has () that denote it is a method but get, isset, and unset do > not. I > see this inconsistency as something problematic enough to warrant a > solution. > > We could go with the following: > public $Hours { > get() { ... } > set($value) { ... } > isset() { ... } > unset() { ... } > } > > Yes, we now have a little bit more meat on the syntax, but in this > case, I > don't think that it's all that bad. Here's two reasons why: > 1) Adding parenthesis denotes that they are all functions - which > they are! > If anything, adding parenthesis to all of them makes the > implementation * > more* sensible. > 2) It's *only* two more characters per function. On top of that, in > my > opinion, this syntax is not "ugly". In fact, as I just mentioned - > this > implementation is arguably *more* consistent with the rest of PHP. > > On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest > wrote: > >> Seems a fair amount of people would like it with a definable >> parameter >> name, though the original RFC I based mine off of is more than 4 >> years old >> (mine is over a year old already). >> >> The $value is precisely chosen because it is exactly the way C# >> operates >> and the original author thought to keep it the same as another >> well-known >> language (why re-invent new syntax for no reason). >> >> That being said, javascript does indeed allow it, my concern then >> would be >> would we have the parameterized syntax only for set() and not get, >> isset or >> unset? >> >> If we do have them for all of them, it's a lot of extra characters >> with no >> real need. >> >> I definitely favor set($value) over a magic $Hours for the $Hours >> property, but I personally see no problem with the $value, it's not >> magic >> it's a locally defined variable. >> >> Internally, this: >> public $Hours { >> get { ... } >> set { ... } >> } >> >> Is implemented as standard functions, while they are hidden through >> reflection, these functions exist (as a result of the above >> example): >> >> public __getHours() { ... } >> public __setHours($value) { ... } >> >> Lastly, with regards to JavaScript style getters/setters, I don't >> think >> I've ever cared what the variable name was, I typically just do >> something >> like: >> >> set blah(x) { ... } <-- x is fairly irrelevant and similarly the use >> of >> $value is fairly irrelevant. Thoughts? >> >> > -----Original Message----- >> > From: Jazzer Dane [mailto:tbprogrammer@gmail.com] >> > Sent: Monday, October 08, 2012 5:32 PM >> > To: Benjamin Eberlei >> > Cc: Aaron Holmes; internals@lists.php.net >> > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 >> > >> > I agree. >> > It's more consistent than the $Hours solution and we don't have to >> add >> another superglobal or magic constant, which is quite nice. The >> > typehinting is a big plus as well. >> > >> > On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei >> > >wrote: >> > >> > > The set() one is really nice with the typehints. >> > > >> > > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes >> >> > > wrote: >> > > >> > > > On 10/8/12 1:07 PM, Denis Portnov wrote: >> > > > >> > > >> 08.10.2012 15:52, Clint Priest пишет: >> > > >> >> > > >>> public $Hours { >> > > >>> get { return $this->Seconds / 3600; } >> > > >>> set { $this->Seconds = $value; } >> > > >>> isset { return isset< >> > > >>> http://www.php.net/isset**>($this->Seconds); } >> > > >>> unset { unset< >> > > >>> http://www.php.net/unset**>($this->Seconds); } >> > > >>> } >> > > >>> >> > > >> >> > > >> >> > > >> Hi Clint, >> > > >> >> > > >> I've noticed some magic variable '$value' is introduced. And >> except >> > > >> for superglobals I guess there is no such thing in PHP, so it >> looks >> > > >> bit puzzling to me. I'd suggest on of the following: >> > > >> >> > > >> >> > > >> - setter resambles setter method, wich also allows >> typehinting >> > > >> public $Hours { >> > > >> set ($value) { $this->Seconds = $value * 3600; } >> > > >> } >> > > >> >> > > >> public $Hours { >> > > >> set (DateTime $dateTime) { $this->Seconds = >> > > >> $dateTime->getTimestamp(); } >> > > >> } >> > > >> >> > > >> This seems like the cleanest method, in my opinion. >> Javascript >> > > >> does >> > > this >> > > > for object prototypes: >> > > > http://ejohn.org/blog/**javascript-getters-and-**setters/< >> > > http://ejohn.org/blog/javascript-getters-and-setters/> >> > > > >> > > > >> > > >> >> > > >> What do you think? >> > > >> >> > > >> Thanks >> > > >> Denis >> > > >> >> > > >> >> > > > >> > > > -- >> > > > PHP Internals - PHP Runtime Development Mailing List To >> unsubscribe, >> > > > visit: http://www.php.net/unsub.php >> > > > >> > > > >> > > >>