On Sun, Oct 14, 2012 at 10:55 PM, Jazzer Dane 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 rid of th
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
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 BORK'e
On Sun, Oct 14, 2012 at 2:50 PM, Nikita Popov wrote:
> On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest 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
On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest 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
> addressed and we 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 error-pron
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
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 a
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 ab
