Hi,

On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest <cpri...@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 restrictions 
> 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 exposed 
> in any way this may have to change.  I had spent several hours actually 
> divorcing the created function from the Functions HashTable and later 
> realized I could simply enforce their non-existence at call time, this has 
> turned somewhat problematic for static accessors though.
>
> Also, your "should be valid" statement implies that you feel properties and 
> accessors are the same and they are not, internally.  When a class attempts 
> to implement an interface a "function check" is done and since there is no 
> __getXX() function defined it would fail to implementation check against an 
> interface.
>
> I cannot stress enough that properties != accessors in any way except the 
> syntax in which they are used ($o->xyz) or ($o->xyz = 1), that is their 
> *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 
>transparently.

>
>> -----Original Message-----
>> From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne 
>> Kneuss
>> Sent: Monday, October 15, 2012 8:29 AM
>> To: Clint Priest
>> Cc: Nikita Popov (nikita....@gmail.com); internals@lists.php.net
>> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
>>
>> 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 
>> > functionality 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 thus, 
>> C# specifically permits accessors within an interface.
>> >
>> >
>> >
>> > I have no personal stake in this desire to keep them as I do not use 
>> > interfaces (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 
>> interface 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 the 
>> 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



-- 
Etienne Kneuss
http://www.colder.ch

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to