On 16/10/12 14:55, Jazzer Dane wrote:
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
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.
On Mon, Oct 15, 2012 at 8:43 PM, David Muir wrote:
> On 16/10/
On 16/10/12 13:37, Clint Priest wrote:
On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest wrote:
> >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
> On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest wrote:
> > 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 the
Hi Nuno
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%).
I spent a lot of time this weekend trying
On Mon, Oct 15, 2012 at 10:07 PM, Etienne Kneuss wrote:
> On Mon, Oct 15, 2012 at 6:45 PM, Lester Caine wrote:
>> 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
On Mon, Oct 15, 2012 at 6:45 PM, Lester Caine wrote:
> 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 nee
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
Hi,
On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest wrote:
> 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 nothin
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
On Oct 15, 2012, at 9:37 AM, "Levi Morrison" wrote:
>> I *think* we are on the same page
> 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 prop
> -Original Message-
> From: ekne...@gmail.com [mailto:ekne...@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,
>
> On Mon
master
Cycles Direct Getter
__get
v1.4 @ 10/8/20121m .05s.21s
.20s
php 5.5.0-dev
Cycles Direct Getter
> 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 Catego
On Mon, Oct 15, 2012 at 8:09 AM, Etienne Kneuss wrote:
> Hi,
>
> On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest wrote:
>> I would bet, that at present, what you've put down is not allowed because I
>> purposely leveraged functions in this regard because all of the restrictions
>> put in place ag
> But here are some issues with the above that may be of concern:
> * Property access is 4x faster than accessor method calling
4x faster on what kind of scale? Where are these performance tests at?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
> public DateTime $date;
This is *real* progress, even if under the hood all it does is wrap
functions and use function type-hints. This piece of code is SO much
shorter and cleaner. Will it be a bit confusing to new developers?
Maybe, but I don't care. It is not aimed at making the lives of new
Hi,
On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest wrote:
> I would bet, that at present, what you've put down is not allowed because I
> purposely leveraged functions in this regard because all of the restrictions
> put in place against functions would apply to accessors (because they are
> fu
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 o
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
* I'm moving this into its own mail thread because talking about 3* 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 dat
* 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
* 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
23 matches
Mail list logo
