Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65127
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <B103E205-5F44-4524-9BCD-7BF241F7E552@zerocue.com>
References: <510038C9.5000900@mrclay.org>
	<B103E205-5F44-4524-9BCD-7BF241F7E552@zerocue.com>
Date: Wed, 23 Jan 2013 14:17:24 -0700
Message-ID: <CAFMT4Nq+27=7BuqrJggjjf8mT_NBAXr7v-qzkWazFgdQLYTRew@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: Steve Clay <steve@mrclay.org>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] C# properties vs. accessors RFC
From: morrison.levi@gmail.com (Levi Morrison)

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.