Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basnetworks.net from 208.97.132.145 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=J6xx7lMF4srqyxTNL9oEtkS3WlOPpv+LyIVg2eVo0LQ5n
	s3+tdwcvLfYY/13Kl9pt9xyrCwliPn4gzON3sJXderoNhgxZOjaiPc3l0NN7Qsen
	x2KmMmSLmioU45VplSoih8r6br1B6/cQHywdL+UkaJlJAI4HZgolFAfxo09mFA=
Message-ID: <2450924ae03481f5b1382a7f00e5743d.squirrel@webmail.basnetworks.net>
In-Reply-To: <003401cb8fee$1be39840$53aac8c0$@com>
References:
    <ae7aa0536c47a2ac725222d49918183f.squirrel@webmail.basnetworks.net>
    <003601cb8fd0$f6494e80$e2dbeb80$@com> <4CF3B855.5010406@sugarcrm.com>
    <003401cb8fee$1be39840$53aac8c0$@com>
Date: Tue, 30 Nov 2010 08:42:42 -0500
To: "Jonathan Bond-Caron" <jbondc@openmv.com>
Cc: "'Stas Malyshev'" <smalyshev@sugarcrm.com>,
 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

Hello,

>> Hi!
>>
>> > Nice RFC, just an idea for an alternative syntax (added to the RFC
>> > as
>> #2):
>> >
>> > property Hours {
>> > 	get { return $this->seconds / 3600; }
>> > 	set { $this->seconds =3D $value * 3600; } // The variable $value
>> holds
>> > the incoming value to be "set"
>> > }
>> >
>> > class TimePeriod
>> > {
>> >      private $seconds;
>> >
>> >      public [Hours] $hours1;
>> >      public {use Hours;} $hours2;
>> > }
>>
>> If you change "property" to "class" or "trait" and "get" to "__get"
>> you need almost no new syntax :)
>>
>
> Right, it looks the same but the subtle difference is 'property Hours'
> wouldn't be registered as a class. It's just container code for get(),
> set()
> methods that would get 'compiled' into opcodes in the class TimePeriod
> (the
> property exists vs. searching for it in runtime). So you can think of i=
t
> as
> a special 'trait' that only applies to properties.
>
> The idea behind this syntax is you can move the 'property' definition o=
ut
> of
> the class so that you can test and re-use it somewhere else (like trait=
s).
>
> That might not be problem if you can define properties in traits (needs=
 to
> be explained in the RFC):
> trait TimeUnits {
>     public property Seconds
>     {
>         get { return $this->seconds; }
>         set { $this->seconds =3D $value; }// The variable $value holds =
the
> incoming value to be "set"
>     }
>     public property Minutes
>     {
>         get { return $this->seconds / 60; }
>         set { $this->seconds =3D $value * 60; }
>     }
>     public property Hours
>     {
>         get { return $this->seconds / 3600; }
>         set { $this->seconds =3D $value * 3600; }// The variable $value
> holds
> the incoming value to be "set"
>     }
> }
>
> class MyTime {
>   uses TimeUnits;
>
>   protected $_seconds;
> }


I do not think that properties should make use of a trait-like syntax, as
that is not what a property is about.  A property is basically a layer of
syntactic sugar over a pair of methods.  The majority of the time when
writing properties, you will not want to re-use them, so I have a hard
time seeing many parallels to traits.

However, it does make sense to be able to define a property as part of a
trait, as again, it is basically just a pair of methods.  When I get some
time, I will try to add a syntax for traits to the RFC.

- Dennis