Hi,
On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of Etienne
>> Kneuss
>> Sent: Monday, October 15, 2012 8:29 AM
>> To: Clint Priest
>> Cc: Nikita Popov ([email protected]); [email protected]
>> 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
