Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50751
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basnetworks.net from 208.97.132.119 cause and error)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; c=nofws; d=basnetworks.net; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:mime-version
	:content-type:content-transfer-encoding; q=dns; s=
	basnetworks.net; b=xhcb9jq8NeVQbaSR04me2tQyoV7J1C7yR//BB76WpzKS0
	v/RRojiOKYdqmHrVoJMuNvZmZfHpLmZONpyKEL9HTRVQXRnNkpzZK+trKORNdGpu
	9RhbHDB+jF9jbOHYHvRBdEHeWScF6gJLYWjZBX8/nxnwAGTN2x6p2ztWPn/tSM=
Message-ID: <7251c0fce39578c68ccc642410b1311a.squirrel@webmail.basnetworks.net>
In-Reply-To: <AANLkTi=sF=Kros8OqLmn1WqC7sujqXygFT2N8CCtbPmk@mail.gmail.com>
References:
    <ae7aa0536c47a2ac725222d49918183f.squirrel@webmail.basnetworks.net>
    <AANLkTi=wY_djZ=4ZKW7sV4zKpr_X_uEo3iqkA+pSDCsy@mail.gmail.com>
    <073c59f255a348e9684fb4875490b23f.squirrel@webmail.basnetworks.net>
    <AANLkTi=sF=Kros8OqLmn1WqC7sujqXygFT2N8CCtbPmk@mail.gmail.com>
Date: Tue, 30 Nov 2010 19:39:42 -0500
To: RQuadling@googlemail.com
Cc: president@basnetworks.net,
 internals@lists.php.net
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
From: president@basnetworks.net

> Thanks for your reply.
>
> Fundamentally, a big +1 from my little voice on having setters/getters =
in
> PHP.
>
>
> The issue of documentation is probably that the documentation tools
> would have to adapt. As things stand PHPDoc doesn't support
> namespaces, so setters/getters would just be added to the WIBNI list.

Here is a reply I wrote to Christan Kaps on the same subject:

>  Christan Wrote:
>
>  I like the idea of the property get/set syntax, but in my opinion it
>  doesn't figure with PHP's syntax, because it breaks the readability. T=
he
>  problem for me is the nesting of the inner set and get. How do you
>  document these syntax.
>
>  /**
>   *
>   */
>  public $name {
>
>      /**
>       *
>       */
>      get {
>          return $this->name;
>      }
>
>      /**
>       *
>       */
>      set {
>          $this->name =3D htmlentities($value);
>          $this->name =3D strip_tags($this->name);
>      }
>  };

Typically you only document the property as a whole, and not the
individual get and set method.  Since they are a pair, there should be no
reason to document them separately.  If the get method is doing something
totally different from the set, then they should not be paired, as that i=
s
confusing.

In C# you would typically see documentation like this:

Only a get method:
/// <summary>Gets the duration of the Timespan in seconds.</summary>
public int Seconds { get; }

Only a set method:
/// <summary>Sets the duration of the Timespan in seconds.</summary>
public int Seconds { set; }

Both a get and set method:
/// <summary>Gets/sets the duration of the Timespan in seconds.</summary>
public int Seconds { get; set; }





> With regard to the value supplied to the set method, would it make
> more sense for PHP to be ...
>
>         set($value) { $this->seconds =3D $value * 3600; }
>
> or
>
>         set { $this->seconds =3D __SETVALUE__ * 3600; }
>
> Having $value without a clear indication of where it comes from
> doesn't read quite right.
>
> $value is way to generic to be magically created. __SETVALUE__ (or
> __SOMETHINGELSE__) is clear in this regard.

That is a good point.  In C# it is simple the variable "value", which is
where I got $value from.  Rather magicy, yes.  A constant could work, and
would be more in line with PHP's magic constants.  Just a quick question
though, can a constant store all of the same data variable can?  What
about a reference?

Also, sometimes users in C# like to modify the contents of the "value"
variable before using it for something else.  If it were a constant this
would not be possible, you would have to define a new variable, then copy
the value from the constant, which seems unnecessarily cumbersome.

- Dennis