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 th
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
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
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 i
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 befo
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
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
acces
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 h
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
On 1/3/13 12:42 PM, Michael Wallner wrote:
On 3 January 2013 17:41, Clint Priest 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?
My
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 3 January 2013 17:41, Clint Priest 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 Internals - PHP Runt
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 $this->realbar
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; $this
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/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; $t
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 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 t
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 {
public
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
On Jan 2, 2013, at 10:24 PM, Clint Priest 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 semantics depend
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 attempt
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 ment
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 if
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 exp
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/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 remaining
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.
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
On Wed, Jan 2, 2013 at 10:41 AM, Steve Clay 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 fatal e
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 bo
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 metho
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 dis
33 matches
Mail list logo
