Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63296 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54511 invoked from network); 9 Oct 2012 08:20:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Oct 2012 08:20:41 -0000 Authentication-Results: pb1.pair.com header.from=tbprogrammer@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tbprogrammer@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.42 as permitted sender) X-PHP-List-Original-Sender: tbprogrammer@gmail.com X-Host-Fingerprint: 209.85.219.42 mail-oa0-f42.google.com Received: from [209.85.219.42] ([209.85.219.42:53192] helo=mail-oa0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 99/15-23861-85ED3705 for ; Tue, 09 Oct 2012 04:20:41 -0400 Received: by mail-oa0-f42.google.com with SMTP id j1so5248043oag.29 for ; Tue, 09 Oct 2012 01:20:38 -0700 (PDT) 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=gyDmoLPrBKuBPoSJDsrYgLG+yIw0AsKtpL5H1LJ6tRs=; b=LLsbmE+XGzwGvsGxod8xPUn7Z8PId2pJTBlGCnjClTrNZb4e//kP3gWVOY8mb3m28n 97HaiIhU0L6K90+4nmalS1qlJOW6PnzEqAait0xpy+JxympLb+Q5d33J26llJ2Yxys1t 2boYWW83nJWWsbzCj1PTSpLezGJjgrGrcHVWbllwQRDyTD7eqmj/jSvjMl0kP0im0E7G 6Qb2RMxhgs194++IiEH+mvtk5AJ15bj+A4Q5KRHBd3xD0NpK4ZQf+kpxMxZbVeIqokx9 gDHhPyUtRRNuF3OJoeoaiR4U9tgWHD/O8HSwPog97vEPcJpP7MsFeobMktHG9mCw2K3d OOkw== Received: by 10.60.170.202 with SMTP id ao10mr15133207oec.135.1349770838059; Tue, 09 Oct 2012 01:20:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.11.170 with HTTP; Tue, 9 Oct 2012 01:20:17 -0700 (PDT) In-Reply-To: <760ab4f994a78a846cf86aafda71e0e2@mohiva.com> References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local> <5073328D.5000002@gmail.com> <50735165.8010703@aaronholmes.net> <9570D903A3BECE4092E924C2985CE485612B4353@MBX202.domain.local> <760ab4f994a78a846cf86aafda71e0e2@mohiva.com> Date: Tue, 9 Oct 2012 01:20:17 -0700 Message-ID: To: Christian Kaps Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=bcaec54a354854aad304cb9c03ec Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 From: tbprogrammer@gmail.com (Jazzer Dane) --bcaec54a354854aad304cb9c03ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christian, I think a majority of your concerns are all for none. From top to bottom: - Extra indention: This is definitely a bias and is only moderately relevant while documenting this feature. - You *can* declare a public getter and private setter, or vice versa, or whatever you want. This is in the RFC. See "Asymmetric Accessor Accessibility." - "If we ever get return type hinting/checks then we needn't consider how the syntax has to look" From what I know, this isn't planned for PHP 5.5 and any proposals for it have been largely ignored. Return type hinting won't help when setting either, although it would help with getting. All that being said, type hinting aside, the syntax I proposed is, in my opinion, the most consistent out of any other proposal thus far (arguably aside from yours, I'll go over that momentarily). - "We must deal with two different syntaxes for the same thing" I don't quite understand what you mean here, unless you're talking about braces inside braces. It seems your code examples make your intended point here a bit clearer, though. - "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" While we want to strive to keep a clean and consistent syntax, I don't think molding to whatever is easiest for IDE's is a good idea. - "We have to create new rules about how the documentation for this syntax should look like" From my point of view, this isn't so much a concern as a to-do item later on. On to your proposal: I'm not a fan of this: > public function get hours() {} > This is adding another keyword after function, which is arguably more inconsistent than some previous proposals. I'm sort of okay with this: > public get hours() {} > Replacing function with get/set/isset/unset... but it still seems a bit too inconsistent and insensible. Replacing the function keyword with the name of a preexisting function? I also do not like how the accessors are separated from one another, which is not the case with the previous proposals. All in all, I still prefer my previous proposal to this. On Tue, Oct 9, 2012 at 12:46 AM, Christian Kaps wrote: > Hi, > > typehinting should definitely be available for this feature. But I have > another question. Why not go more consistent with the rest of the languag= e? > 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/** > WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#** > WS5b3ccc516d4fbf351e63e3d118a9**b90204-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 i= t > 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 o= f >> * >> __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 go= od >> idea. >> If I see $value in the code, I'll logically look for where it was define= d, >> 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# operate= s >>> and the original author thought to keep it the same as another well-kno= wn >>> 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, isse= t >>> 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 mag= ic >>> 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 somethi= ng >>> 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 ad= d >>> 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 =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> > > >> >>> > > >>> public $Hours { >>> > > >>> get { return $this->Seconds / 3600; } >>> > > >>> set { $this->Seconds =3D $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 =3D $value * 3600; } >>> > > >> } >>> > > >> >>> > > >> public $Hours { >>> > > >> set (DateTime $dateTime) { $this->Seconds =3D >>> > > >> $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 >>> > > > >>> > > > >>> > > >>> >>> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --bcaec54a354854aad304cb9c03ec--