You are right, we can define __get() in an interface. So, in the end I will
shut my mouth.
But still, it's not logical. An interface is a contract which defines the
capacities of an object. If an interface defines the entry point swim(), we
know that an object which implements this interface is
Hi Clint,
1) Point taken.
2) The use case can be solved with an object implementing ArrayAccess,
but not pragmatically, because then you need a class for *each*
bidirectional association. Let me give a short example:
Given the class Article with a bidirectional many-to-one relation to
Category
Hey Amaury,
Good points all around, but one last thing to point out, interfaces only
declare what *must* be supported by an implementer, properties have no
implementation, they just are. Whereas an accessor *has* an implementation.
So when you see that an interface has an accessor, you can
True. But:
1. The code doesn't reflect that. In my previous example, it's true that I
know the Fooable interface details when I write the Bar object. But later,
when I'll read the code of this object, nothing tells me that $abc is an
accessor an not a property. It could be confusing and
On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest cpri...@zerocue.com wrote:
Alright, here is the updated RFC as per discussions for the last few days:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
If you could read it over, make sure I have all of your concerns correctly
On Sun, Oct 14, 2012 at 2:50 PM, Nikita Popov nikita@gmail.com wrote:
On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest cpri...@zerocue.com wrote:
Alright, here is the updated RFC as per discussions for the last few days:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
If you
Hi,
Here you have a dump of a run of PHP_HEAD in the gcov machine (almost 13k
tests) without valgrind:
http://gcov.php.net/~nlopess/dump_PHP_HEAD_z4.txt
It was run with -z 4. However, the reported CPU usage is only 213%
(instead of ~400%).
As you can see in the dump, there are a few
One of the reasons the current syntax, as seen below, was chosen, is for
typehints - yes.
public $property {
get() { ... }
set{TypeHint $value) { ... }
}
The other reason it was chosen was to specifically get rid of the magic
$value that appeared out of thin air. If typehints become
On Sun, Oct 14, 2012 at 10:55 PM, Jazzer Dane tbprogram...@gmail.com wrote:
One of the reasons the current syntax, as seen below, was chosen, is for
typehints - yes.
public $property {
get() { ... }
set{TypeHint $value) { ... }
}
The other reason it was chosen was to specifically get
