Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63398
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.41 as permitted sender)
To: Amaury Bouchard <amaury@amaury.net>
CC: Nikita Popov <nikita.ppv@gmail.com>, Benjamin Eberlei
	<kontakt@beberlei.de>, "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Thread-Index: Ac2oOZ3+vAOzWRcnRpOb6a/hOVK5+ABAY8yAAALpNQAAAUOoAAAEr8EwAACGpYAAB+4qMAAKcpQAAAQ9rMk=
Date: Sun, 14 Oct 2012 03:22:55 +0000
Message-ID: <E03D369B-713C-4EF1-BA11-3615563BE5A7@zerocue.com>
References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local>
 <CAEPJdu=1_TWqzyf+sKep+0zBMMJnWjw4R=WM8R95fC=S4UOSXg@mail.gmail.com>
 <CAF+90c-OAcgv6kjg4Xy4acskQ6+35yfPq_hx5+oxPJn-EaaPsg@mail.gmail.com>
 <CAPaKmRmhU0o2DLk2Zy0GYVKB=uenrRNETXNgE3wO8DN5dy+PXg@mail.gmail.com>
 <9570D903A3BECE4092E924C2985CE485612B59F6@MBX202.domain.local>
 <CAPaKmRmVr=dQTF0MZbhL0CqY5BU8PJx4RkEXOd42L0TvJ4xF5g@mail.gmail.com>
 <9570D903A3BECE4092E924C2985CE485612B5A54@MBX202.domain.local>,<CAPaKmRn4vDKdo+sZUN8OWSTc170iHH3Pui19PWHavD0J5nh-4g@mail.gmail.com>
In-Reply-To: <CAPaKmRn4vDKdo+sZUN8OWSTc170iHH3Pui19PWHavD0J5nh-4g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_E03D369B713C4EF1BA113615563BE5A7zerocuecom_"
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
From: cpriest@zerocue.com (Clint Priest)

--_000_E03D369B713C4EF1BA113615563BE5A7zerocuecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



-Clint

On Oct 13, 2012, at 4:21 PM, "Amaury Bouchard" <amaury@amaury.net<mailto:am=
aury@amaury.net>> wrote:

2012/10/13 Clint Priest <cpriest@zerocue.com<mailto:cpriest@zerocue.com>>
Interfaces are used to define what methods must be present, properties are =
not allowed.

Yes, so no one should be correct, right?
I mean, yes the first declaration implies some code; but for the interface,=
 it's still a property definition.

You=92re mixing concepts here, it=92s an accessor definition, not a propert=
y definition.  property !=3D accessor, an accessor just happens to look and=
 act like a property (which is the point of accessors).

Interfaces define methods, not properties. Fine.
But is an accessor (as defined in the RFC) a method? Or should we consider =
that an accessor definition is valid inside an interface? I would say no, b=
ecause it will be used as a property: outside of the object that implements=
 the accessor, nobody know if it's an attribute or an accessor function.

It's the whole point of the RFC (apart from the asymetric visibility, but y=
ou know my point of view).


So, for me, this code should be incorrect:
  interface Fooable {
    public $abc { get; set; }
  }

Because if an object implements the interface:
  class Fooer implements Fooable {
    public $abc {
      get { /* what you want */ }
      set { /* what you want too */ }
    }
  }

How this code will be used? Like that:
  $foo =3D new Fooer();
  $foo->abc =3D 3;
  print($foo->abc);

Everybody will agree with me that $abc is used like a property, not as a me=
thod. So the language should enforce that.
There is a real issue here; this is not a fad from me.

An accessor is a method and an interface which defines an accessor is indic=
ating that the accessor must be implemented by any using the interface.

See: http://msdn.microsoft.com/en-US/library/64syzecx(v=3Dvs.80).aspx

Also, "used like a property" does not mean it is a property, it is a method=
 call with the syntax of accessing a property, it is still a method call.

I believe __get() may be declared in an interface and if so, then accessors=
 should be as well.

--_000_E03D369B713C4EF1BA113615563BE5A7zerocuecom_--