Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63413
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.42 as permitted sender)
MIME-Version: 1.0
Sender: ekneuss@gmail.com
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B655A@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local>
 <CACQesk5MLCqhdKr9j30WmL6ySTeMpVVEs9q2UfOjYbA+4bp_Yw@mail.gmail.com> <9570D903A3BECE4092E924C2985CE485612B655A@MBX202.domain.local>
Date: Mon, 15 Oct 2012 16:09:47 +0200
Message-ID: <CACQesk4q-YLPkn=ECHsNcTmoanzKVH8eN8iZ-LW-wULn7_rbHQ@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
From: colder@php.net (Etienne Kneuss)

Hi,

On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest <cpriest@zerocue.com> wrote:
> I would bet, that at present, what you've put down is not allowed because=
 I purposely leveraged functions in this regard because all of the restrict=
ions put in place against functions would apply to accessors (because they =
are functions).  I would have to test it to be certain though.
>
> Because of Nikita's desire to not have underlying __getXX() functions exp=
osed in any way this may have to change.  I had spent several hours actuall=
y divorcing the created function from the Functions HashTable and later rea=
lized I could simply enforce their non-existence at call time, this has tur=
ned somewhat problematic for static accessors though.
>
> Also, your "should be valid" statement implies that you feel properties a=
nd accessors are the same and they are not, internally.  When a class attem=
pts to implement an interface a "function check" is done and since there is=
 no __getXX() function defined it would fail to implementation check agains=
t an interface.
>
> I cannot stress enough that properties !=3D accessors in any way except t=
he syntax in which they are used ($o->xyz) or ($o->xyz =3D 1), that is thei=
r *only* similarity.

I not saying accessors are properties. I'm saying that interfaces
define usage contracts. And from the point of view of usage contacts:

interface A {
   public $a {get; set; }
}

is entirely fulfilled by the class:

class B extends A {
    public $a;
}

You can see a public property as an underlying private property with
all usual public accessors defined.

From the point of view of the user both should be interchangeable transpare=
ntly.

>
>> -----Original Message-----
>> From: ekneuss@gmail.com [mailto:ekneuss@gmail.com] On Behalf Of Etienne =
Kneuss
>> Sent: Monday, October 15, 2012 8:29 AM
>> To: Clint Priest
>> Cc: Nikita Popov (nikita.ppv@gmail.com); internals@lists.php.net
>> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfac=
es
>>
>> Hi,
>>
>> >
>> > Interfaces are a tough one, I would just like to point out that, again=
 accessors are fundamentally different than properties, they
>> just happen to share the same "use" syntax but act entirely differently.=
  The difficulty with allowing an interface to enforce a
>> property is that the implementing class doesn't know when that property =
has changed or been accessed, whereas with an accessor
>> they are required to write code that responds to the use of the property=
.
>> >
>> >
>> >
>> > I hate to keep pointing to C# but (IMHO) it's a leader in terms of fun=
ctionality for a language and PHP is so similar to the C* family
>> of languages it would follow suit that we should continue that direction=
 as its probably one of the reasons it has grown in popularity
>> so much (any C* programmer can write PHP with minimal new understanding,=
 and new programmers are exposed to an easy
>> language which mimics some of the best other languages out there); and t=
hus, C# specifically permits accessors within an interface.
>> >
>> >
>> >
>> > I have no personal stake in this desire to keep them as I do not use i=
nterfaces (very often) but from a purist point of view on the
>> concept of interfaces I wanted to finish this up with an example of an i=
nterface that could exemplify why they should be allowed:
>> >
>> >
>> >
>> > interface iVehicle {
>> >
>> >                 public $TireCount { get; }
>> >
>> >                 public $EngineType { get; }
>> >
>> >                 public $IsFunctional { get; }
>> >
>> >                 public $Speed { get; }
>> >
>> >
>> >
>> >                 public $OutputLocale { get; set; }  /* Do we output
>> > MPH or KPH, for example)
>> >
>> >
>> >
>> >                 public function Drive();
>> >
>> > }
>>
>> Interfaces are defined to specify how a an object implementing a certain=
 interfaces can be used. The clear indication of this is that
>> only public methods are allowed in interfaces.
>>
>> For instance, an interface A with a get accessor on the property "foo"
>> will only tell you that, given that $obj implements A, you will be able =
to read $obj->foo.
>>
>> In fact, the following code
>>
>> interface A {
>>    public $a { get; set }
>> }
>>
>> class B implements A {
>>    public $a;
>> }
>>
>> should be valid. In terms of capabilities, the class B implements all th=
e requirements imposed by the interface A. (The same goes if
>> A was a class,  BTW)
>>
>> Is that the case in your current patch? (I couldn't find information in =
your RFC nor in the tests on github) If it is the case, I'm fine with
>> having accessors and not plain properties in interfaces.
>>
>> Best,
>>
>>
>> >
>> > -Clint
>>
>>
>>
>> --
>> Etienne Kneuss



--=20
Etienne Kneuss
http://www.colder.ch