On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to
make this happen for 5.5, voting and the specifications are here:
On Wed, Jan 23, 2013 at 2:28 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Rasmus,
Now do 5 or even 10+ years and commits to Zend and APC. We are talking
about a core language feature here, so commits to the code most affected
is what you should be looking at and when I talk about
hi Rasmus,
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
The simple explanation from me is that the ROI isn't there on this one.
It adds a lot of code complexity for very little return. Yes, it saves a
couple of lines of boilerplate code for a few people, but the
On 01/23/2013 01:15 AM, Pierre Joye wrote:
About opcode cache complexity, I think apc per se is full of things we
should simplify or drop as features to make the code base much smaller
and much easier to test and valid, we have discussed that already and
we disagreed. But this is a topic I
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/22/2013 03:18 AM, Clint Priest wrote:
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a
On Wed, Jan 23, 2013 at 12:11 PM, Benjamin Eberlei kont...@beberlei.dewrote:
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 01/22/2013 03:18 AM, Clint Priest wrote:
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/22/2013 03:18 AM, Clint Priest wrote:
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a
On Tue, Jan 22, 2013 at 6:18 AM, Clint Priest cpri...@zerocue.com wrote:
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
this
Sherif,
Don't get me wrong, I liked it, but I also disliked the fact that it
introduces language changes that aren't easy to grasp or document. To me
this means we've borderline changed the behavior of a property (which most
PHP users currently understand to be a variable) into potential
On Wed, Jan 23, 2013 at 9:03 AM, Anthony Ferrara ircmax...@gmail.comwrote:
Sherif,
Don't get me wrong, I liked it, but I also disliked the fact that it
introduces language changes that aren't easy to grasp or document. To me
this means we've borderline changed the behavior of a property
On 1/23/2013 8:31 AM, Sherif Ramadan wrote:
Except that everything that's proposed here is possible today with __get,
__set, __isset and __unset. So already today you can't assume that a
property is a variable. In fact, you could build something like this
using __get, etc extremely dirty:
On Wed, Jan 23, 2013 at 12:00 PM, Clint Priest cpri...@zerocue.com wrote:
Actually you could say that last sentence is precisely opposite of the
truth in that a var_dump() will *never* expose properties that are
available via a magic __get() therefore a var_dump() already mis-leads the
On 23 January 2013 19:53, Sherif Ramadan theanomaly...@gmail.com wrote:
They're not shown because they don't exist. Thus no confusion about whether
this is a property or not. If it's a property we can see it in
var_dump($obj). If it's magic you can only see it in
var_dump($obj-property).
On 1/23/2013 1:00 PM, Marco Pivetta wrote:
Actually, having the properties shown even if virtual allows us to
access them in a reflection-ish manner without doing dangerous
assumptions like does the setter/getter exist?
The fact that the property is virtual is very useful, even though in
On Wed, Jan 23, 2013 at 2:07 PM, Clint Priest cpri...@zerocue.com wrote:
On 1/23/2013 1:00 PM, Marco Pivetta wrote:
Actually, having the properties shown even if virtual allows us to access
them in a reflection-ish manner without doing dangerous assumptions like
does the setter/getter
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to
make this happen for 5.5, voting and the specifications are here:
Clint Priest wrote:
There seems to be a lot of userland support for this proposal from people who
don't have voting rights.
And what about the userland people who don't want the additional complexity who
don't have voting rights?
--
Lester Caine - G8HFL
-
Contact
@Lester seems pretty much opt-in to me :)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
2013/1/22 Lester Caine les...@lsces.co.uk
Clint Priest wrote:
There seems to be a lot of userland support for this proposal from people
who
don't have voting rights.
And what about the userland people who don't want the additional
complexity who don't have voting rights?
Don't use it.
Sebastian Krebs wrote:
Clint Priest wrote:
There seems to be a lot of userland support for this proposal from
people who
don't have voting rights.
And what about the userland people who don't want the additional complexity
who don't have voting rights?
@Lester your explanation simply exposes the fact that your resources to
upgrade to newer technologies are insufficient. This doesn't mean that
newer technologies don't have to exist.
And no, it won't be possible to fix all bugs/flaws before getting a new
feature. We'd all be running in circles
On 1/22/2013 6:55 AM, Marco Pivetta wrote:
@Lester your explanation simply exposes the fact that your resources to
upgrade to newer technologies are insufficient. This doesn't mean that
newer technologies don't have to exist.
And no, it won't be possible to fix all bugs/flaws before getting a
Clint Priest wrote:
And no, it won't be possible to fix all bugs/flaws before getting a new
feature. We'd all be running in circles looking for perfection :)
I can agree that some things need fixing though, perhaps Lester could put
together an RFC detailing the myriad of things he deems
For those that have voted against this proposal, are there any
clarifications that can be made or questions answered?
I can say that this bit is particularly confusing:
public $foo {}
My understanding that this code will not emit any warnings when
interpreted, but the $foo property has no
Am 22.01.2013 02:46, schrieb Clint Priest:
On 1/20/2013 3:11 PM, Gordon Oheim wrote:
Am 17.01.2013 19:20, schrieb Clint Priest:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
On 01/22/2013 03:18 AM, Clint Priest wrote:
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to
make this happen for 5.5, voting and the
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
The simple explanation from me is that the ROI isn't there on this one.
It adds a lot of code complexity for very little return. Yes, it saves a
couple of lines of boilerplate code for a few people, but the cost is
high
On 1/22/2013 11:20 AM, Rasmus Lerdorf wrote:
On 01/22/2013 03:18 AM, Clint Priest wrote:
For those that have voted against this proposal, are there any
clarifications that can be made or questions answered?
There seems to be a lot of userland support for this proposal from
people who don't
On 1/22/2013 9:24 AM, Levi Morrison wrote:
For those that have voted against this proposal, are there any
clarifications that can be made or questions answered?
I can say that this bit is particularly confusing:
public $foo {}
My understanding that this code will not emit any warnings
Am 22.01.2013 22:27, schrieb Clint Priest:
property accessors and magic accessors use the same pre/post function
and logic
So this is the reason for some magic behaviour of property
accessors. Logically property accessors may be a subset of magic
accessors but not the other way around.
On 01/22/2013 01:27 PM, Clint Priest wrote:
In terms of cost of maintenance, I was under the impression that
since I wrote it, I would be maintaining it which is why I applied
for and you approved a VCS account for me.
The concern is historical and not personal. Frequently the long-term
On Jan 22, 2013, at 6:00 PM, Christopher Jones christopher.jo...@oracle.com
wrote:
On 01/22/2013 01:27 PM, Clint Priest wrote:
In terms of cost of maintenance, I was under the impression that
since I wrote it, I would be maintaining it which is why I applied
for and you approved a VCS
Rasmus,
If you look at the split in voting you will notice it is
pretty much split along the lines of the people who have to maintain
this code vs. the people who would like a shiny new feature.
I pulled some numbers, and this isn't really the case.
Based off of commits from the past year
On 01/22/2013 04:41 PM, Anthony Ferrara wrote:
Rasmus,
If you look at the split in voting you will notice it is
pretty much split along the lines of the people who have to maintain
this code vs. the people who would like a shiny new feature.
I pulled some numbers, and this
Rasmus,
Now do 5 or even 10+ years and commits to Zend and APC. We are talking
about a core language feature here, so commits to the code most affected
is what you should be looking at and when I talk about maintenance I
talk about code we are fixing 10 years from now. Commits in the past
On 1/20/2013 3:11 PM, Gordon Oheim wrote:
Am 17.01.2013 19:20, schrieb Clint Priest:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
this happen for 5.5, voting and the
On Sun, Jan 20, 2013 at 5:46 AM, Sherif Ramadan theanomaly...@gmail.comwrote:
I'm not sure if this has already come up in past discussion or not. So
I apologize in advance if this is repetitive. The discussion for property
accessors has been so lengthy I couldn't find the time to keep up with
On Sun, Jan 20, 2013 at 8:08 AM, Nikita Popov nikita@gmail.com wrote:
On Sun, Jan 20, 2013 at 5:46 AM, Sherif Ramadan
theanomaly...@gmail.comwrote:
I'm not sure if this has already come up in past discussion or not. So
I apologize in advance if this is repetitive. The discussion for
On Sun, 20 Jan 2013 14:35:14 +0100, Sherif Ramadan
theanomaly...@gmail.com wrote:
What I'm saying is this kind of behavior needs far more serious reasoning
than the very naive assesment you're making above.
I mean that with all due respect. Just wondering if there is another take
on this from
On Sun, Jan 20, 2013 at 8:45 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
On Sun, 20 Jan 2013 14:35:14 +0100, Sherif Ramadan
theanomaly...@gmail.com wrote:
What I'm saying is this kind of behavior needs far more serious reasoning
than the very naive assesment you're making above.
I mean
On Sun, 20 Jan 2013 14:52:36 +0100, Sherif Ramadan
theanomaly...@gmail.com wrote:
I think the current behavior is most appropriate one for var_dump() (and
array casts/get_object_vars()). It's the same behavior as if you had
manually defined getXXX() methods or used __get().
It's actually
On 1/20/2013 7:35 AM, Sherif Ramadan wrote:
Now $surface shows us the following from var_dump
object(surface)#1 (3) {
[area]=
NULL
[width]=
int(4)
[height]=
int(2)
}
Sounds like a reasonable approach to me... var_dump()
1) Should not invoke the getters..
2) Should indicate
On Sun, Jan 20, 2013 at 10:31 AM, Clint Priest cpri...@zerocue.com wrote:
On 1/20/2013 7:35 AM, Sherif Ramadan wrote:
Now $surface shows us the following from var_dump
object(surface)#1 (3) {
[area]=
NULL
[width]=
int(4)
[height]=
int(2)
}
Sounds like a
Am 17.01.2013 19:20, schrieb Clint Priest:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
this happen for 5.5, voting and the specifications are here:
Hello Clint, Nikita and Stas.
To facilitate complete functionality with properties it is necessary to
provide accessor functions to act on isset() and unset() calls.
Note: isset unset implementations are always provided with default
implementations unless the author explicitly defines their
On Thu, Jan 17, 2013 at 8:42 PM, Clint Priest cpri...@zerocue.com wrote:
On 1/17/2013 4:24 PM, Steve Clay wrote:
https://wiki.php.net/rfc/**propertygetsetsyntax-v1.2#**votinghttps://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
I'll say my peace on this. This is a very good
On Thu, Jan 17, 2013 at 7:20 PM, Clint Priest cpri...@zerocue.com wrote:
I'm happy to say that Property Accessors is ready for a vote for inclusion
in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
this happen for 5.5, voting and the specifications are
On 1/17/13 1:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for inclusion in
5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make this
happen for
5.5, voting and the specifications are here:
On 1/17/2013 4:24 PM, Steve Clay wrote:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
I'll say my peace on this. This is a very good implementation, and as
long as authors use accessors that depend on a separate property for
storage (like other langs require), everything will be
49 matches
Mail list logo
