- 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:
- 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
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
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 : InterfacesHi,
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 outputMPH 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
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.
-----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 : InterfacesHi,
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 outputMPH 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
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.
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.
-----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 : InterfacesHi,
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.
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.
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.
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.
I prefer the current syntax to your proposal because:
- 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.
- 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
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.
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:
- 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.
- 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.netwrote:
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.
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
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 : InterfacesHi!
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
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
-----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 : InterfacesHi!
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?
I'd have to do some research to know for sure, but it's highly likely that they cannot be mixed.
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 anI 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.
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 %dI 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
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
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
-----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 : InterfacesHi!
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?
I'd have to do some research to know for sure, but it's highly likely that they cannot be mixed.
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.
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.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.
Class b does not satisfy the requirement because you are missing the fact that public $xyz { get; } forbids setting of $xyz, only reading it.
That doesn't make sense. An implementation has to have the same or less
restricted visibility, so the above should work. The inverse however
should not:
interface a { public $xyz; }
class b implements a { public $xyz { get; }}
Daivd
I acquiesce to this issue, I agree that declaring a property in a class which implements an interface which has designated an accessor does indeed satisfy the accessor.
But I think it would be very poor programming practice to do it.
Anyone else have anything to say about this issue?
-----Original Message-----
From: David Muir [mailto:davidkmuir@gmail.com]
Sent: Tuesday, October 16, 2012 11:20 PM
To: Clint Priest
Cc: Stas Malyshev; Nikita Popov (nikita.ppv@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces-----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 :
InterfacesHi!
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?
I'd have to do some research to know for sure, but it's highly likely that they cannot be mixed.
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.
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.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.
Class b does not satisfy the requirement because you are missing the fact that public $xyz { get; } forbids setting of $xyz, only
reading it.That doesn't make sense. An implementation has to have the same or less restricted visibility, so the above should work. The
inverse however should not:interface a { public $xyz; }
class b implements a { public $xyz { get; }}
Daivd