Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63295
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: sebastian.krebs.berlin@gmail.com
In-Reply-To: <760ab4f994a78a846cf86aafda71e0e2@mohiva.com>
References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local>
	<5073328D.5000002@gmail.com>
	<50735165.8010703@aaronholmes.net>
	<CAEPJdu=pRSDRD68t3o7XVbWRo-FvA07Wr+bzM_bwOXkwfiMxng@mail.gmail.com>
	<CACxA8bkF0EHDs3As=kMcg-BahRfBK6A5i7B9TdRc_SweCsv23A@mail.gmail.com>
	<9570D903A3BECE4092E924C2985CE485612B4353@MBX202.domain.local>
	<CACxA8b=wbHN_mRomH25Jr+i9BeTzj=VTGfPe_T8igjzCsMNn_Q@mail.gmail.com>
	<760ab4f994a78a846cf86aafda71e0e2@mohiva.com>
Date: Tue, 9 Oct 2012 10:17:27 +0200
Message-ID: <CALtuQzAH-=ePssPi-yUcXghpUhO6jOH4oDhDtPEFVj9bRf1VLA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b621c74fa51d104cb9bf74d
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7b621c74fa51d104cb9bf74d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2012/10/9 Christian Kaps <christian.kaps@mohiva.com>

> 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<http://help.adobe.com/en_US/A=
ctionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.ht=
ml#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)
>

I guess it's more useful to document the property as a whole and not every
single accessor on it's own.


> - It isn't possible to declare a private setter and a public getter, as i=
t
> is possible with methods
>

As far as I understand it it is possible.


> - 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
>

For now it seems the only bigger difference is, that the keyword 'function'
is omitted. You can propose to add it :)


> - 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
>

The tools should not decide how the language should look like, just because
it makes their life easier ;)


> - We have to create new rules about how the documentation for this syntax
> should look like
>

Why should the documentation differ from the documentation for regular
properties?


>
> 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() {}
>

I don't like how it separate the single accessors from each other. The
benefit from this RFC (imo) -- especially compared to __get()/__set() --
is, that every accessors is directly and obviously bound to the (single)
property: You have a single block with all the corresponding accessors in
it and not several (on the first glance: different) methods, that could be
spread over the whole class.

Maybe it's just me, but I really would like to see this feature in 5.5. As
far as I remember it was first proposed for 5.3 and now (years after)
seeing it delayed, because the syntax "looks ugly (just my opinion)" makes
me feel a little bit ... ehm ... sad. I think the syntax is fine and it
seems it covers the most important points (even not all). There is a
property and "the value" of the property are the accessors. I bet we could
find an infinite number of different syntax, that provides exactly the same
functionality, but why?

Regards,
Sebastian


>
> 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 <cpriest@zerocue.com> 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 <kontakt@beberlei.de
>>> >wrote:
>>> >
>>> > > The set() one is really nice with the typehints.
>>> > >
>>> > > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes <aaron@aaronholmes.ne=
t
>>> >
>>> > > 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<http://www.php.net/**isset**<http://www.php.net/=
isset**>>
>>>  { return isset<
>>> > > >>> http://www.php.net/isset**>($**this->Seconds); }
>>> > > >>>          unset<http://www.php.net/**unset**<http://www.php.net/=
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/<htt=
p://ejohn.org/blog/**javascript-getters-and-**setters/>
>>> <
>>> > > http://ejohn.org/blog/**javascript-getters-and-**setters/<http://ej=
ohn.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
>
>


--=20
github.com/KingCrunch

--047d7b621c74fa51d104cb9bf74d--