# [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

- Thread: https://externals.io/message/63409
- Original archive: https://news-web.php.net/php.internals/63409
- Started by Clint Priest on 2012-10-15T12:34:49+00:00
- Messages: 27
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/63409.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #63409 — Clint Priest — 2012-10-15T12:34:49+00:00

URL: https://externals.io/message/63409#63409

* I'm moving this into its own mail thread because talking about 5 different topics under the same chain is ridiculous (has anyone suggested forums instead of email??)



> So here comes my round of feedback on the current proposal.

>

> But before getting to that: I have collected a bit of data how getter and setter are currently used in Symfony and ZF:

> https://gist.github.com/3884203 Mainly so I get a better overview of the situation, but might be of interest for other people involved

> in this discussion too.

>

> So, my points on the proposal, in no particular order:

> 2. Interfaces

> ------------------

>

> I already mentioned this before, but I'll reiterate it here again:

> Currently properties and properties with accessors are handled different with regards to interfaces. In particular, if you have an

> interface such as follows:

>

>     interface Extension {

>         public $name { get; }

>         // more stuff

>     }

>

> then the following is not a valid implementation of the interface:

>

>     class FooExtension implements Extension {

>         public $name = 'foo';

>         // more stuff

>     }

>

> This does not make sense to me: $foo->name is a gettable property, as such it satisfies the interface. I don't see a reason why we

> would need a hard distinction between properties and properties with accessors here.

>

> The converse is also true: An interface currently can not define a "plain" property:

>

>     interface Foo {

>         public $foo;

>     }

>

> I would expect this interface definition to be the same as "public $foo { get; set; }". But I'm not sure on this point, as one could argue

> that it's just a redundant way to say the same thing.



Etienne Kneuss Wrote:

> I have to agree here.

>

> Interfaces are means to describe the capabilities of an object from the outside. And from the outside, properties defined through accessors are used like properties, not methods.

>

> It would IMHO be better not to support accessors in interfaces until properties are also (if ever) supported.



Jazzer Dane Wrote:

> In terms of interfaces, Clint's reason for allowing accessors in interfaces is moderately sensible: to remain cohesive with the already allowed __get and __set magic methods that are usable in interfaces. That's the underlying issue. If we want to require an object to be able to be converted to a string, we can sensibly put __toString in the interface. But what does forcefully implementing __get or __set do for the object? What does it tell us about how we're able to use it? It relates to properties in arguably such a manner that we(i.e. accessing the object's API) nor the interface should care about. But that's an argument for another day.

>

> So what do we do right now, then? If we allow it in interfaces, my main worry is that people will put the accessor in an interface just because they can't put a property, and they'd use the accessor as a normal, basic property.



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();

}



Clearly much more could be added to that interface, it probably isn't even a good interface, but it illustrates my point I think.  These accessors answer questions about a vehicle and provide one way to make it move.



The two biggest problems with allowing properties with interfaces is symmetrical only access and non-observability, neither of which accessors have a problem with.  The alternative interface that would have to be written for the above interface without allowing accessors is the old get/set function calls (which I think just about everyone hates, no?):



interface iVehicle {

                public function getTireCount();

                public function getEngineType();

                public function getIsFunctional();

                public function getSpeed();



                public function getOutputLocale();

                public function setOutputLocale();



                public function Drive();

}



I think that accessors should be allowed with interfaces because an interface really is a specification on how to communicate and while accessors do pass messages, properties do not.



-Clint

---

## #63411 — Etienne Kneuss — 2012-10-15T13:29:25+00:00

URL: https://externals.io/message/63409#63411 · In reply to: #63409

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

---

## #63412 — Clint Priest — 2012-10-15T13:55:45+00:00

URL: https://externals.io/message/63409#63412 · In reply to: #63411

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.

> -----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 : Interfaces
> 
> Hi,
> 
> > […]
> 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.
> > […]
> 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.
> > […]
> concept of interfaces I wanted to finish this up with an example of an interface that could exemplify why they should be allowed:
> > […]
> 
> 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,
> 
> 
> > […]
> 
> 
> 
> --
> Etienne Kneuss

---

## #63413 — Etienne Kneuss — 2012-10-15T14:09:47+00:00

URL: https://externals.io/message/63409#63413 · In reply to: #63412

Hi,


> 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.

>
> > […]



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

---

## #63416 — Levi Morrison — 2012-10-15T14:19:17+00:00

URL: https://externals.io/message/63409#63416 · In reply to: #63413

> Hi,
>
> 
> > […]
>
> 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.

I support this idea.  Dart used this method before they removed
interfaces from the language altogether and it seemed to work well. Is
it completely obvious? No, it's not. I honestly don't think it
matters, though, because people who will use this will use interfaces.
 As already mentioned, interfaces typically are not typically used in
PHP. The fact that it isn't 100% obvious is a non-issue in my opinon.

---

## #63419 — Clint Priest — 2012-10-15T14:34:10+00:00

URL: https://externals.io/message/63409#63419 · In reply to: #63413

> -----Original Message-----
> From: ekneuss@gmail.com [mailto:ekneuss@gmail.com] On Behalf Of Etienne Kneuss
> Sent: Monday, October 15, 2012 9:10 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
> 
> Hi,
> 
> 
> > […]
> 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.
> > […]
> 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.
> > […]
> 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.
> > […]
> 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.
> 

I *think* we are on the same page here, though I'm not sure what 'user' is referring to (user of interface "implementer") or (user of class B).  In any case, I don't believe that your class B would be allowed at present, but if it is, then it should not be allowed because defining a property to satisfy the requirements of an accessor is not right.

---

## #63420 — Levi Morrison — 2012-10-15T14:37:50+00:00

URL: https://externals.io/message/63409#63420 · In reply to: #63419

> I *think* we are on the same page here, though I'm not sure what 'user' is referring to (user of interface "implementer") or (user of class B).  In any case, I don't believe that your class B would be allowed at present, but if it is, then it should not be allowed because defining a property to satisfy the requirements of an accessor is not right.

According to whom?  In my opinion, not allowing a property to satisfy
the requirement of an accessor is wrong.

---

## #63421 — Clint Priest — 2012-10-15T16:02:42+00:00

URL: https://externals.io/message/63409#63421

Because fundamentally interfaces are designed to explain a way of communicating and properties are symmetrical and non-observable.

The implementing class cannot "know" when a property has changed.

-Clint



> > […]
> 
> According to whom?  In my opinion, not allowing a property to satisfy
> the requirement of an accessor is wrong.

---

## #63422 — Etienne Kneuss — 2012-10-15T16:33:18+00:00

URL: https://externals.io/message/63409#63422 · In reply to: #63421

Hi,


> Because fundamentally interfaces are designed to explain a way of communicating and properties are symmetrical and non-observable.
>
> The implementing class cannot "know" when a property has changed.

Do you agree that there is nothing that distinguishes

class A {
    public $v;
}

from

class B {
   private $_v;
   public $v { get { return $this->v; }; set($n) { $this->v = $n; }}
}

when it comes to a client of B reading and writing to $b->v ? That's
the entire point of accessors: being able to seamlessly intercept
usages of properties with custom code.

If you define an interface saying interface A { public $v { get;set;}
} you are only saying to the user: objects of type A will have a
property $v that you can read and write to.
Whether it is a set of accessors or a property belongs to the
implementation detail of the class implementing A, the user should not
be able to see a difference when interacting with the class, as he
will do it through $obj->v and $obj->v = ...;

I can understand why we might not want that in PHP in order to
simplify the implementation, but it we follow logical reasoning I
can't see why we shouldn't implement that.


This discussion makes we wonder about another aspect of the patch that
is unclear:

class A {
   public $v = 2;
}

class B extends A {
   public $v { get { .. }; set { .. } };
}

Will $b->v trigger the accessors, will it ignore them and access "v"
in the properties table, or is overriding existing properties using
accessors rejected during compilation?

Best,

>
> -Clint
>
> 
>
> > […]



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

---

## #63423 — Lester Caine — 2012-10-15T16:45:46+00:00

URL: https://externals.io/message/63409#63423 · In reply to: #63422

Etienne Kneuss wrote:
> I can understand why we might not want that in PHP in order to
> simplify the implementation, but it we follow logical reasoning I
> can't see why we shouldn't implement that.

With a decent IDE you don't need any of this overhead anyway. When you see the 
sorts of increase in time taken to do things why wouldn't you move as much as 
you can OUT of the core runtime code anyway?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #63424 — Etienne Kneuss — 2012-10-15T20:07:38+00:00

URL: https://externals.io/message/63409#63424 · In reply to: #63423

> Etienne Kneuss wrote:
> > […]
>
>
> With a decent IDE you don't need any of this overhead anyway. When you see
> the sorts of increase in time taken to do things why wouldn't you move as
> much as you can OUT of the core runtime code anyway?
>

Please do not hijack this thread, we are not discussing whether or not
accessors should be implemented, but how.

Best,

> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> 
> 
>



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

---

## #63425 — Etienne Kneuss — 2012-10-15T20:08:57+00:00

URL: https://externals.io/message/63409#63425 · In reply to: #63424

> 
> > […]
>
> Please do not hijack this thread, we are not discussing whether or not
> accessors should be implemented, but how.

To be perfectly clear, by "why we shouldn't implement that" the "that"
means being able to implement an interface with accessors using plain
properties.

>
> Best,
>
> > […]
>
>
>
> --
> Etienne Kneuss
> http://www.colder.ch



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

---

## #63427 — Clint Priest — 2012-10-16T02:37:43+00:00

URL: https://externals.io/message/63409#63427 · In reply to: #63422

> 
> > […]
> observable.
> > […]
> 
> Do you agree that there is nothing that distinguishes
> 
> class A {
>     public $v;
> }
> 
> from
> 
> class B {
>    private $_v;
>    public $v { get { return $this->v; }; set($n) { $this->v = $n; }} }
> 
> when it comes to a client of B reading and writing to $b->v ? That's the entire point of accessors: being able to seamlessly intercept
> usages of properties with custom code.
> 
> If you define an interface saying interface A { public $v { get;set;} } you are only saying to the user: objects of type A will have a
> property $v that you can read and write to.
> Whether it is a set of accessors or a property belongs to the implementation detail of the class implementing A, the user should not
> be able to see a difference when interacting with the class, as he will do it through $obj->v and $obj->v = ...;
> 
> I can understand why we might not want that in PHP in order to simplify the implementation, but it we follow logical reasoning I
> can't see why we shouldn't implement that.
> 

I'm not sure I understand what you're getting at here Etienne, this thread was about interfaces but now you're talking about two classes...

> 
> This discussion makes we wonder about another aspect of the patch that is unclear:
> 
> class A {
>    public $v = 2;
> }
> 
> class B extends A {
>    public $v { get { .. }; set { .. } }; }
> 
> Will $b->v trigger the accessors, will it ignore them and access "v"
> in the properties table, or is overriding existing properties using accessors rejected during compilation?
> 

This topic was brought up by Nikita and is now in the "backing property" thread.  Originally I had properties shadowing accessors, which would be the opposite of your desired functionality here.  

Nikita suggested that accessors should shadow properties which would let your above design do just as you want it to.  I think you and she are right, Accessors should shadow real properties (hide them if defined) such that an accessor will take over for a defined property.  Originally I wrote it the other way because that's the way __get() works, it only gets called if there is not a real property already.  I kept it the same for the sake of being the same but I think accessors shadowing properties is the way to go.

> Best,
> 
> > […]
> of class B).  In any case, I don't believe that your class B would be allowed at present, but if it is, then it should not be allowed
> because defining a property to satisfy the requirements of an accessor is not right.
> > […]
> 
> 
> 
> --
> Etienne Kneuss
> http://www.colder.ch

---

## #63428 — David Muir — 2012-10-16T03:43:41+00:00

URL: https://externals.io/message/63409#63428 · In reply to: #63427

> > […]
> I'm not sure I understand what you're getting at here Etienne, this thread was about interfaces but now you're talking about two classes...
>

 From an interface standpoint, both classes implement the same property. 
One as a literal property, the other as an accessor. The point being, 
from the code consuming the class, a property and accessor are the same 
thing. Interfaces are about contracts between an implementation and a 
consumer, so the actual implementation is irrelevant. What matters is 
how the implementation is accessed by the consumer. If it is via 
property syntax, then it *is* a property, even though the actual 
implementation might be a property, an accessor or (in theory) even 
__get/__set.

Cheers,
David

---

## #63429 — Jazzer Dane — 2012-10-16T03:55:20+00:00

URL: https://externals.io/message/63409#63429 · In reply to: #63428

I'm going to agree with David here. It is most sensible to either allow
properties AND accessors in interfaces, or don't allow either of them.
__get/__set is a different subject that I'd rather not dig into while
discussing this RFC.



> 
>
> > […]
> From an interface standpoint, both classes implement the same property.
> One as a literal property, the other as an accessor. The point being, from
> the code consuming the class, a property and accessor are the same thing.
> Interfaces are about contracts between an implementation and a consumer, so
> the actual implementation is irrelevant. What matters is how the
> implementation is accessed by the consumer. If it is via property syntax,
> then it *is* a property, even though the actual implementation might be a
> property, an accessor or (in theory) even __get/__set.
>
> Cheers,
> David

---

## #63430 — David Muir — 2012-10-16T04:20:47+00:00

URL: https://externals.io/message/63409#63430 · In reply to: #63429

> I'm going to agree with David here. It is most sensible to either 
> allow properties AND accessors in interfaces, or don't allow either of 
> them. __get/__set is a different subject that I'd rather not dig into 
> while discussing this RFC.

I tossed in the __get/__set because they satisfy the interface. The 
problem with them it is that they would satisfy the interface at runtime 
rather than compile time, and thus would be unsafe to use. Kind of 
defeats the point of an interface... ;-)

Cheers,
David

---

## #63431 — Amaury Bouchard — 2012-10-16T07:39:30+00:00

URL: https://externals.io/message/63409#63431 · In reply to: #63412

2012/10/15 Clint Priest <cpriest@zerocue.com>

> 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 disagree. That's why I said this is a matter of choice. A philosophical
choice.
I don't see properties and accessors like different things which are
accidentally written the same. Accessors are a layer upon properties. It's
a magical layer, trying to mimic accessors.
It's a bit like aspect-oriented programming: you can add layer but the core
is still the same (from a developper point of view, not from the PHP
interpreter point of view).


See another argument: My proposal for read/write accessibility definition.
When I suggested to allow this syntax: "public:private $abc;"
some people objected that it's the same than "public $abc { get; private
set; }"

So, if I understand what you said, for you it's deeply different and
comparing them is like comparing apples and oranges. I disagree. I still
think my syntax is better (and could be implemented with better
performance), but it's normal to compare them, because they (can) offer
pretty much the same functionnalities.

---

## #63432 — Jazzer Dane — 2012-10-16T07:54:06+00:00

URL: https://externals.io/message/63409#63432 · In reply to: #63431

I prefer the current syntax to your proposal because:

1) It is not at all obvious which side is which. Example:
    *protected:private
*    Is protected* *for get? Or set? The average PHP developer will have no
idea. In fact, they likely won't know that they even correlate to get and
set.

2) There is no such syntax already in PHP.  (And on a more personal note, I
don't think I've ever seen that syntax in any other language that I've
worked in before. Which means it's even *more-so* out of people's comfort
zones.)

The current read/write syntax works, and none of the discussion I've read
thus far would sway me towards any other option.

That being said, I wouldn't contest to hearing - in more detail - your
reasoning behind why we should use it instead of the current syntax.



> 2012/10/15 Clint Priest <cpriest@zerocue.com>
>
> > […]
>
>
> I disagree. That's why I said this is a matter of choice. A philosophical
> choice.
> I don't see properties and accessors like different things which are
> accidentally written the same. Accessors are a layer upon properties. It's
> a magical layer, trying to mimic accessors.
> It's a bit like aspect-oriented programming: you can add layer but the core
> is still the same (from a developper point of view, not from the PHP
> interpreter point of view).
>
>
> See another argument: My proposal for read/write accessibility definition.
> When I suggested to allow this syntax: "public:private $abc;"
> some people objected that it's the same than "public $abc { get; private
> set; }"
>
> So, if I understand what you said, for you it's deeply different and
> comparing them is like comparing apples and oranges. I disagree. I still
> think my syntax is better (and could be implemented with better
> performance), but it's normal to compare them, because they (can) offer
> pretty much the same functionnalities.

---

## #63438 — Amaury Bouchard — 2012-10-16T09:32:31+00:00

URL: https://externals.io/message/63409#63438 · In reply to: #63432

This discussion is opened in the dedicated thread. I used my proposal as an
example to illustrate my point of view, not to pollute this thread.

2012/10/16 Jazzer Dane <tbprogrammer@gmail.com>

> I prefer the current syntax to your proposal because:
>
> 1) It is not at all obvious which side is which. Example:
>     *protected:private
> *    Is protected* *for get? Or set? The average PHP developer will have
> no idea. In fact, they likely won't know that they even correlate to get
> and set.
>
> 2) There is no such syntax already in PHP.  (And on a more personal note,
> I don't think I've ever seen that syntax in any other language that I've
> worked in before. Which means it's even *more-so* out of people's comfort
> zones.)
>
> The current read/write syntax works, and none of the discussion I've read
> thus far would sway me towards any other option.
>
> That being said, I wouldn't contest to hearing - in more detail - your
> reasoning behind why we should use it instead of the current syntax.
>
>
> On Tue, Oct 16, 2012 at 12:39 AM, Amaury Bouchard <amaury@amaury.net>wrote:
>
> > […]

---

## #63439 — Stas Malyshev — 2012-10-16T09:36:53+00:00

URL: https://externals.io/message/63409#63439 · In reply to: #63409

Hi!

> I think that accessors should be allowed with interfaces because an
> interface really is a specification on how to communicate and while
> accessors do pass messages, properties do not.

"Communicate" is a loaded term. Property access is communication too,
but properties aren't defined in the interfaces. In any case, if you're
allowing accessors in interface, you should bring back automatic
implementation of accessors, since if you're saying "you must provide
property $a" I should be able to say "OK, here's property $a, working
exactly as plain old PHP property". Either that or I'd have to write a
boilerplate code (and make a couple of errors on the way such as
breaking references and isset, which 99% of less-experienced PHP
programmers would do).
I think accessors in interfaces are a huge can of worms because of their
potential of mixing function calls and property access, while the latter
is traditionally not the domain of the interface. We should carefully
consider if we really have use case for it. Especially given that PHP
always has underlying default property access functionality that is
always available - unlike methods which if not defined lead to fatal
error. So while if you do $foo->bar() on wrong $foo it will break, if
you do $foo->bar on wrong $foo yu just get default behavior. Given that,
do we really need an interface there?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #63448 — Clint Priest — 2012-10-16T10:32:02+00:00

URL: https://externals.io/message/63409#63448 · In reply to: #63439

I haven't done an exhaustive analysis of every language out there that supports interfaces but to my knowledge there isn't a single one that supports properties in interfaces.  Again, not exhaustive either but there is one language that does support accessors in interfaces and that's C#.

When I refer to "communicate" for an interface I am referring to the fact that if a property were allowed and a consumer of an object which implements that property changes that property, the object will not know about it until it has its own code run through some other method, whereas with an accessor the object will "hear about it" right away.  

Think about it, if you allowed an outside caller of your class to modify your internal state, any time you needed to use that internal state you would have to validate it before you could rely upon its value to be set correctly.  No such issue exists with accessors in an interface as the communication about its change attempt is resolved immediately (and can be rejected or accepted).

Just to be a bit more concrete here, as the code is presently written and because I have strongly separated the concept of a property vs an accessor, this code:

interface a {
	public $xyz { get; }
}

class b implements a {
	public $xyz;
}

Produces the following error:
Fatal error: Class b contains 3 abstract accessors and must be declared abstract or implement the remaining accessors (get a::$xyz, isset a::$xyz, ...) in %s on line %d

This fatal error actually occurs during the *function check* phase of interface checking, because public $xyz {get;} represents a set of functions that must be defined (accessors).

> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 4:37 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 : Interfaces
> 
> Hi!
> 
> > […]
> 
> "Communicate" is a loaded term. Property access is communication too, but properties aren't defined in the interfaces. In any case,
> if you're allowing accessors in interface, you should bring back automatic implementation of accessors, since if you're saying "you
> must provide property $a" I should be able to say "OK, here's property $a, working exactly as plain old PHP property". Either that or
> I'd have to write a boilerplate code (and make a couple of errors on the way such as breaking references and isset, which 99% of
> less-experienced PHP programmers would do).
> I think accessors in interfaces are a huge can of worms because of their potential of mixing function calls and property access, while
> the latter is traditionally not the domain of the interface. We should carefully consider if we really have use case for it. Especially
> given that PHP always has underlying default property access functionality that is always available - unlike methods which if not
> defined lead to fatal error. So while if you do $foo->bar() on wrong $foo it will break, if you do $foo->bar on wrong $foo yu just get
> default behavior. Given that, do we really need an interface there?
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #63456 — Stas Malyshev — 2012-10-16T11:05:46+00:00

URL: https://externals.io/message/63409#63456 · In reply to: #63448

Hi!

> that supports properties in interfaces.  Again, not exhaustive either
> but there is one language that does support accessors in interfaces
> and that's C#.

So what C# does when mixing regular properties and accessorized properties?

> Think about it, if you allowed an outside caller of your class to
> modify your internal state, any time you needed to use that internal
> state you would have to validate it before you could rely upon its
> value to be set correctly.  No such issue exists with accessors in an

I do not see why this assumption is made that I need to do some special
validation each time state is changed. In fact, in 99% of existing code
it is not happening, and I assume this ratio will be kept even when
accessors are available. Most code will be very straightforward, not
doing anything complex with the state.

Now, I think the bigger question is: what exactly you want to
say/require when you write:

interface a { public $xyz { get; } }

and what is the use case for this requirement?

> Just to be a bit more concrete here, as the code is presently written
> and because I have strongly separated the concept of a property vs an
> accessor, this code:
> 
> interface a { public $xyz { get; } }
> 
> class b implements a { public $xyz; }
> 
> Produces the following error: Fatal error: Class b contains 3
> abstract accessors and must be declared abstract or implement the
> remaining accessors (get a::$xyz, isset a::$xyz, ...) in %s on line
> %d

I think this is wrong. 3 abstract accessors is especially wrong since it
doesn't match the direct interface definition and is very confusing (see
my earlier point about isset/unset always having fallback defaults) but
even with get as abstract I do not see a valid use case that would
require such behavior. What you want is for any $foo that is instanceof
a to be able to respond to read request to $foo->xyz, right? Class b
satisfies this requirement, why you reject it then?
Also, if you reject it - how I should fix it to make it work? Would I
have to implement a bolierplate getter/setter just to make interface
work? Doesn't look like a good proposition to me.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #63459 — Clint Priest — 2012-10-16T11:34:01+00:00

URL: https://externals.io/message/63409#63459 · In reply to: #63456

> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 6:06 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 : Interfaces
> 
> Hi!
> 
> > […]
> 
> So what C# does when mixing regular properties and accessorized properties?

I'd have to do some research to know for sure, but it's highly likely that they cannot be mixed.
> 
> > […]
> 
> I do not see why this assumption is made that I need to do some special validation each time state is changed. In fact, in 99% of
> existing code it is not happening, and I assume this ratio will be kept even when accessors are available. Most code will be very
> straightforward, not doing anything complex with the state.

If you have a public property $a which internally can only deal with it being set to 2 or 3 and someone external to the class sets it to 4, your class either has to check that it's 2 or 3 and deal with the fact that it is now 4 or have indeterminate results when it is set to 4.

> Now, I think the bigger question is: what exactly you want to say/require when you write:
> 
> interface a { public $xyz { get; } }
> 
> and what is the use case for this requirement?

The use case is that you are declaring that interface a must allow a property $xyz to be readable and *not* writable.

> > […]
> 
> I think this is wrong. 3 abstract accessors is especially wrong since it doesn't match the direct interface definition and is very
> confusing (see my earlier point about isset/unset always having fallback defaults) but even with get as abstract I do not see a valid
> use case that would require such behavior. What you want is for any $foo that is instanceof a to be able to respond to read request
> to $foo->xyz, right? Class b satisfies this requirement, why you reject it then?
> Also, if you reject it - how I should fix it to make it work? Would I have to implement a bolierplate getter/setter just to make
> interface work? Doesn't look like a good proposition to me.

Class b does not satisfy the requirement because you are missing the fact that public $xyz { get; } forbids setting of $xyz, only reading it.

> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #63465 — Stas Malyshev — 2012-10-16T12:44:30+00:00

URL: https://externals.io/message/63409#63465 · In reply to: #63459

Hi!

> If you have a public property $a which internally can only deal with
> it being set to 2 or 3 and someone external to the class sets it to
> 4, your class either has to check that it's 2 or 3 and deal with the
> fact that it is now 4 or have indeterminate results when it is set to
> 4.

Most of the properties, however, aren't of that nature.

> The use case is that you are declaring that interface a must allow a
> property $xyz to be readable and *not* writable.

Why would you require for the implementor to *not* be able to do
something? Interfaces were never used to make class *not* be able to do
something. Are you sure it's good thing to introduce this? I think it's
not. I think interfaces should only define "X should work" but not "Y
should not work".

> Class b does not satisfy the requirement because you are missing the
> fact that public $xyz { get; } forbids setting of $xyz, only reading
> it.

See above, I think it's not the right use of interfaces. Also, error
message produced has nothing in common with this logic.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #63475 — Clint Priest — 2012-10-16T21:51:30+00:00

URL: https://externals.io/message/63409#63475

My choice of words were misleading/incorrect.  If you are programming to an interface then the interface dictates what *will* work, if you attempt to use an interface to do something that the interface has not declared is supported then it may work or it may fail.



> Hi!
> 
> > […]
> 
> Most of the properties, however, aren't of that nature.
> 
> > […]
> 
> Why would you require for the implementor to *not* be able to do
> something? Interfaces were never used to make class *not* be able to do
> something. Are you sure it's good thing to introduce this? I think it's
> not. I think interfaces should only define "X should work" but not "Y
> should not work".
> 
> > […]
> 
> See above, I think it's not the right use of interfaces. Also, error
> message produced has nothing in common with this logic.
> -- 
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

Next page: https://externals.io/message/63409.md?page=2