2012/10/9 Christian Kaps <christian.k...@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 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/**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcb<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)
>
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 it
> 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 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 <cpri...@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# 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:tbprogram...@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 <kont...@beberlei.de
>>> >wrote:
>>> >
>>> > > The set() one is really nice with the typehints.
>>> > >
>>> > > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes <aa...@aaronholmes.net
>>> >
>>> > > 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<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 = $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/>
>>> <
>>> > > 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
>
>
--
github.com/KingCrunch
