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
<christian.k...@mohiva.com>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 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)
> - 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 <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
>
>
