On 02.01.2013 12:36, Clint Priest wrote:
Here is the updated RFC incorporating the feedback from previous rounds
of discussion.
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
One thing that I have not found in the RFC is how do you specify a
default value AND accessors?
Many examples
On 1/3/13 5:43 PM, Stas Malyshev wrote:
The whole problem here is that the only reason why it is a problem is
because of the accessors that have hidden state in guards. If it were
regular variables (and for all the API consumer knows, they are) there
Please ignore this if it's been debated
I like the alternate idea here, but I'm not sure what advantage it has
over the current situation?
This line of reasoning revealed a difference between what your verbiage
suggestion from a few days ago suggests and what
On 1/5/13 2:05 PM, Clint Priest wrote:
I like the alternate idea here, but I'm not sure what advantage it has over the
current
situation?
See the Pros I listed. The primary being a clear differentiation between calling
accessors and handling of the storage value associated with the property.
The problem I see with your proposal is that get/isset/unset could all
bypass the setter which I think is a bad idea.
If the problem is simply this hidden state that keeps being referred
to, I thought the solution I mentioned before would be better.
To re-iterate that prior idea is to make
Hi!
The first call to a getter would initiate the (calling) guard, any other
access outside of the getter from that point forward would return NULL,
but the access by the getter would return the property.
How we implement that? Would we have each variable access check whether
we are in the
That has not been covered and it is a problem, just tested it.
Anyone have any preferences on a resolution?
Only thing that really needs to occur is that the function names need to
be unique, we could prefix any capitals in a variable name with an
additional _ such that:
class A {
On 1/3/2013 12:48 AM, Stas Malyshev wrote:
Hi!
Within get: $this-Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this-Hours = 1 can write to the underlying property but a
read of the property would go
Just getting back to you on #1 and #2...
#1: It seems the majority want to have these internally created accessor
functions visible, which they presently are through get_class_methods,
etc. They are currently hidden by Reflection. I favor the latter, as is
implemented in Reflection since an
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t;
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value;
On 1/3/2013 8:21 AM, Steve Clay wrote:
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t;
On 1/3/2013 9:33 AM, Steve Clay wrote:
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return
On 3 January 2013 17:41, Clint Priest cpri...@zerocue.com wrote:
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
We have constructors, shouldn't those be sufficient for that task?
--
Regards,
Mike
--
PHP
On 1/3/13 11:41 AM, Clint Priest wrote:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value; }
}
}
What would be the point of this?
I think it would be more readable for someone using the class. As a user it
On 1/3/13 12:42 PM, Michael Wallner wrote:
On 3 January 2013 17:41, Clint Priest cpri...@zerocue.com wrote:
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
We have constructors, shouldn't those be sufficient
Clint,
...snip...
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
Well, just speaking in general, we should not try to rush through these
kinds of design decisions. They should only be done incrementally if
Hi!
I think infinite recursion is a potential issue for lots of logging setups
(let's log
when someone calls the logger!) and situations where you have multiple
values to keep in
sync. The accessor implementation shouldn't try to solve these design
problems.
The whole problem here is
Not really sure what to say about this, we can either guard against
recursion or not, I see
no reason *not* to guard against recursion except that it could allow
unauthorized direct
access when the guard is active.
I guess a third option could be that if the property is attempted to be
Here is the updated RFC incorporating the feedback from previous rounds
of discussion.
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
I'm posting it for final review so I can move to voting on Jan 7th.
Please note that the current fork is not quite up-to-date with the RFC
but will be
As is customary for me, I am voicing my opinion against this proposal.
I do not like the proposed syntax; it is cumbersome and unfamiliar to
current PHP style. I would opt for something more in line with current
method definitions.
I do think that PHP needs something like this proposal, but I
On 1/2/13 6:36 AM, Clint Priest wrote:
Here is the updated RFC incorporating the feedback from previous rounds of
discussion.
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
A few remaining questions. The RFC makes it clear that ReflectionClass::getMethods() does
not return internal
On 1/2/13 6:36 AM, Clint Priest wrote:
Here is the updated RFC incorporating the feedback from previous rounds of
discussion.
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
The RFC does not specify whether it's a fatal error to define a class (directly or via
extends/traits) which has
On Wed, Jan 2, 2013 at 10:41 AM, Steve Clay st...@mrclay.org wrote:
On 1/2/13 6:36 AM, Clint Priest wrote:
Here is the updated RFC incorporating the feedback from previous rounds of
discussion.
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
The RFC does not specify whether it's a
Also, I was under the impression that we wanted to remove the magic
`$value` for the setter. It seems the RFC intentionally left it in
there. Any real reason why?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I am confused by one thing about the RFC. There is a section for default
accessor implementations where you specify an accessor without a body,
however many of the examples omit the isset and unset accessors. I would
assuming that omitting an accessor would provide the automagic
implementation.
On 1/2/2013 11:08 AM, Steve Clay wrote:
A few remaining questions. The RFC makes it clear that
ReflectionClass::getMethods() does not return internal method names
like __setSeconds.
1. Are these names visible via get_class_methods() / method_exists() /
is_callable()?
This is the only
On 1/2/2013 12:44 PM, Philip Graham wrote:
I am confused by one thing about the RFC. There is a section for default
accessor implementations where you specify an accessor without a body,
however many of the examples omit the isset and unset accessors. I would
assuming that omitting an accessor
On 1/2/13 4:18 PM, Clint Priest wrote:
Omitting isset/unset has the same effect as declaring it without a body. This
is
described in the RFC under Automatic Implementations with this line:
Note that isset/unset implementations will always be provided if they are not
defined or
if they are
On 1/2/2013 4:18 PM, Steve Clay wrote:
On 1/2/13 4:18 PM, Clint Priest wrote:
Omitting isset/unset has the same effect as declaring it without a
body. This is
described in the RFC under Automatic Implementations with this line:
Note that isset/unset implementations will always be provided
On 1/2/13 6:08 PM, Clint Priest wrote:
Sorry, there was a typo in that RFC there, this line:
isset { return $this-Hours != NULL; }
Should have been with !==:
isset { return $this-Hours !== NULL; }
I've already updated the 1.2 doc to reflect the correct way.
Given what I
All great questions Steve, doesn't quite work the way you have here.
Specifically each get/set/isset/unset have their own guards (just like
__get(), __set(), __isset() and __unset()) which means that:
Within get: $this-Hours can read the underlying property but not write
to it, if it
On Jan 2, 2013, at 10:24 PM, Clint Priest cpri...@zerocue.com wrote:
I've updated the Shadowing section of the RFC which I hope clears this up, it
also includes a slightly modified version of your example at the bottom with
comments.
Updated RFC really helps. The notion of $this-prop access
Hi!
Within get: $this-Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this-Hours = 1 can write to the underlying property but a
read of the property would go through the getter.
Are the accesses also
34 matches
Mail list logo
