Steve:
Like your summary. Disagree with a few points but in general I agree
with you. More below.
> 2. C# has no issetter/unsetter.
>
> IMO customizing these functions is completely unneeded for the vast majority
> of use cases and could be replaced by simpler logic: isset($this->prop)
> calls the getter and compares to NULL; unset($this->prop) passes NULL to the
> setter.
Agreed, but if they are automatically generated then I see no harm in
allow custom `isset` and `unset` behavior as long as it doesn't get in
the way or complicate things.
> I think the path forward is to determine how we can serve the same goals as
> this RFC, but retain the conceptual simplicity of the C# implementation and
> maybe syntax that strays less from current PHP.
>
> I have some ideas that I could start forging into an RFC. Consider this:
>
> class Foo {
> private $_bar;
> public function get bar { return $this->_bar; }
> public function set bar { $this->_bar = $value; }
> }
>
> Advantages I see over the RFC:
> * It's clearer that the accessors map to regular methods, and you know how
> to control visibility of methods and how they're inherited.
> * It's clearer $bar doesn't exist as a property, and it will never show up
> in state inspection.
> * You know $_bar is a plain PHP property, and you can initialize it directly
> in the constructor; we don't need an "initter".
> * There are no guards/proxies/shadow property to think about
Keyword 'function' is unnecessary and please don't use a magic
`$value`. Just do a normal parenthesis:
class Foo {
private $_bar;
public get bar() { return $this->_bar; }
public set bar($value) { $this->_bar = $value; }
}
This allows for a function-like feel and type-hints as well. Which
brings me to the shorthand notation:
> As for type-hinting, I think that could be achieved by a separate, simpler
> mechanism: type-hinting the properties.
>
> class Foo {
> private Bar? $_bar;
> }
I like type-hinting properties as a shorter syntax, but now we have a
`private` method that has public getters/setters? Seems odd at first.
In any case it is confusing.
I also don't like the `?` for `nullable`. Just stick with PHP
convention and do:
class Foo {
public Bar $bar = NULL;
}
Ralph:
>This is too similar to what we have today:
>
>class Foo {
> private $_bar;
> public function getBar() { return $this->_bar; }
> public function setBar($value) { $this->_bar = $value; }
>
>}
Is there anything inherently *wrong* with that method? And the fact
that it is close is a GOOD indication, right? It's familiar and easy
to adopt. In fact, if we did accessors annotations style (which Python
has, so don't knock it blindly):
class Foo {
private $bar;
@bar.getter
public function getBar() { return $this->bar; }
@bar.setter
public function setBar($value) { $this->bar = $value; }
}
Then I'd say that this is *perfect* style. All we add is some
annotations to allow it to be used in getter and setter syntax:
$foo = new Foo;
$foo->bar = 2; //Foo::setBar
$bar = $foo->bar; //Foo::getBar
I can name my getters and setters however I want. Talk about about options!
Note: I'm not saying we should use annotations for this; I'm just
saying it makes certain cases nicer. I'm sure we can find drawbacks as
well. Discuss at will.
Clint:
I'm sorry that you spent all that time without hearing feedback from a
lot of the "No" voters. Had they been participating all along perhaps
it could have been avoided. We'll never know.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
