Le 08/10/2012 14:27, Amaury Bouchard a écrit :
My idea was to write attribute's visibility like
read_visiblity:write_visibility $attr;
public:protected $foo; // public reading, protected writing
public:private $bar; // public reading, private writing
protected:private $aaa; // protected
Hi!
The RFC states
ReflectionClass::getMethods() will not return accessor functions
(hides implementation detail).
Up until now reflection is leaky and is telling the truth. We should
either keep that or completely clean up reflection. (mind also
get_class_methods() and
Hi!
Does the PHP programmer need the truth of underlying language
implementation details or do they need the truth of what they've
defined?
If the method exists, he needs to know it exists. For the rest, see below.
I would argue that if the PHP programmer has defined a property
accessor
Hi!
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes on this until all fine details
aren't hashed out. This is a *huge* feature - one of the
Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Hi!
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes
On Oct 16, 2012 11:27 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes on this until
Stas Malyshev wrote:
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes on this until all fine details
aren't hashed out. This is a*huge* feature -
2012/10/12 Clint Priest cpri...@zerocue.com
I guess I didn’t see any other support for it from others
Well, I get some bad replies (mainly from Andrew), but good ones too. Some
people (like Matthew) said it was an elegant syntax...
and it is a subset of what the RFC I am proposing would
Le 12 oct. 2012 10:37, Bernhard Schussek bschus...@gmail.com a écrit :
As I said, both syntaxes can work together. For example:
public:protected $a {
get() { return ($this-_prefix . $this-_a); }
set($val) { $this-_a = substr($val, 1); }
}
A shortcoming of this syntax is
Clint Priest wrote:
I certainly would not want to push through the door a low quality solution, I would never
do that, but I have been working on this project myself for a year and each time I come
back, having addressed the concerns of the last batch of opinions there are a whole new
set of
On Thu, Oct 11, 2012 at 2:35 AM, Clint Priest cpri...@zerocue.com wrote:
Okay, I would like this to be the last time there are revisions to this
RFC.
To sum up the last few days of conversations, I have these down as points
of contention:
1. Accessor functions should not be present on the
(Let me suggest an idea irrelevant. Sorry...)
The performance of getters is critical.
For me the best solution would be a new keyword, equivalent to a var
without write access from outside the class:
class TimePeriod {
*property* $Hours = 1;
public function setHours($h) {
: Wednesday, October 10, 2012 9:18 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a pretty syntax point of view, private final set() {}
and private
: [PHP-DEV] [RFC] Propety Accessors v1.1
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a pretty syntax point of view, private final set() {}
and private final get() {} are definitely our best bets. But... from a
logical point of view, I prefer read
hi,
On Thu, Oct 11, 2012 at 2:16 PM, Sebastian Krebs krebs@gmail.com wrote:
public read-only $hours {
get { /* .. */ }
set { /* .. */ }
}
that should not be possible or it will be too complicated to document
or to use. Combinations of the readonly option and a setter should not
This would produce a compile error, cannot define set, property is read-only.
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, October 11, 2012 7:43 AM
To: Sebastian Krebs
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors
On 11 October 2012 12:46, Cal c...@icical.net wrote:
For me the best solution would be a new keyword, equivalent to a var
without write access from outside the class:
New keywords should not (will not) be introduced trivially, they can
cause massive headaches with backwards compatibility
[mailto:tbprogram...@gmail.com]
*Sent:* Wednesday, October 10, 2012 9:18 PM
*To:* Clint Priest
*Cc:* internals@lists.php.net
*Subject:* Re: [PHP-DEV] [RFC] Propety Accessors v1.1
** **
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a pretty syntax point of view
want to vote on the aforementioned changes?
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Wednesday, October 10, 2012 7:36 PM
To: internals@lists.php.net
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Okay, I would like this to be the last time
...
Or... do ya'll want to vote on the aforementioned changes?
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Wednesday, October 10, 2012 7:36 PM
To: internals@lists.php.net
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Okay, I would like this to be the last
agreement...
Or... do ya'll want to vote on the aforementioned changes?
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Wednesday, October 10, 2012 7:36 PM
To: internals@lists.php.net
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Okay, I would
10, 2012 7:36 PM
To: internals@lists.php.net
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Okay, I would like this to be the last time there are revisions to this
RFC.
To sum up the last few days of conversations, I have these down as
points of contention:
1. Accessor
, 2012 6:42 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
You really don't want to even think about my idea? It's complementary on some
aspects, you know.
2012/10/11 Clint Priest cpri...@zerocue.commailto:cpri...@zerocue.com
Rather than go
Hi Clint,
In order to achieve read-only and write-only, we could do something
similar to this:
/* Explicitly read-only, sub-classes may redefine the getter but may
not define a setter */
public $Hours {
get() { ... }
final private set() {}
}
This would make the additional keyword
On 10 October 2012 01:16, Johannes Schlüter johan...@schlueters.de wrote:
Up until now reflection is leaky and is telling the truth. We should
either keep that or completely clean up reflection.
Reflection should always tell the truth, or there is no point in it.
On 10 October 2012 04:28,
On 10 October 2012 04:51, Clint Priest cpri...@zerocue.com wrote:
Wow, I'm surprised by all the talk about this RFC this time around. I
posted this numerous times in the past trying to elicit feedback and got
little to none, so I took the time to write it as I thought it should be
written.
On 10 October 2012 08:46, Bernhard Schussek bschus...@gmail.com wrote:
Second, I'd like to throw in the idea of array accessors. I mentioned
this before, but did not get any response.
public $Addresses {
offsetSet($offset, $value) { ... }
offsetGet() { ... }
Here's my feedback on some current outstanding issues/suggestions:
1) Default value: I think having functionality for a default value is
necessary, but I'm also thinking it may already be implementable within the
current syntax.
class Test {
private $seconds;
public $hours {
On 10 October 2012 01:16, Johannes Schlüter johan...@schlueters.de wrote:
Up until now reflection is leaky and is telling the truth. We should
either keep that or completely clean up reflection.
Reflection should always tell the truth, or there is no point in it.
Unfortunately the truth
Second, I'd like to throw in the idea of array accessors. I mentioned
this before, but did not get any response.
public $Addresses {
offsetSet($offset, $value) { ... }
offsetGet() { ... }
offsetUnset($offset) { ... }
offsetExists($offset) { ... }
}
Definitely
2012/10/10 Clint Priest cpri...@zerocue.com:
While I agree it would be a nice to have it would also be un-necessary.
There are already ways to do precisely what is desired here by way of
ArrayAccess.
class Addresses implements ArrayAccess {
offsetSet($offset, $value) { ... }
What concerns me with the current implementation is that it leaks
many implementation details, in particular the fact that the
accessors are implemented as *real* __getXYZ methods and automatic
implementations also use *real* $__XYZ properties.
I don't particularly see this as a
On Wed, 2012-10-10 at 11:53 +, Clint Priest wrote:
On 10 October 2012 01:16, Johannes Schlüter johan...@schlueters.de wrote:
Up until now reflection is leaky and is telling the truth. We should
either keep that or completely clean up reflection.
Reflection should always tell the
On Wed, Oct 10, 2012 at 5:51 AM, Clint Priest cpri...@zerocue.com wrote:
I'm not even sure that automatic backing fields are even desired, I never
felt the need to have them in C# and the only reason they were included is
because they were a part of Dennis's original proposal. Eliminating them
On Wed, Oct 10, 2012 at 5:51 AM, Clint Priest cpri...@zerocue.com wrote:
I'm not even sure that automatic backing fields are even desired, I
never felt the need to have them in C# and the only reason they were
included is because they were a part of Dennis's original proposal.
Eliminating
On Oct 8, 2012, at 10:07 PM, Denis Portnov denixp...@gmail.com wrote:
08.10.2012 15:52, Clint Priest пишет:
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
issethttp://www.php.net/isset { return
: Clint Priest cpri...@zerocue.com, internals@lists.php.net
internals@lists.php.net
Date: Tue, 9 Oct 2012 19:33:20 -0700
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
class A {
public $seconds = 3600;
public $hours {
get() { return $this-seconds / 3600 };
}
}
class B
--
From: Jazzer Dane tbprogram...@gmail.com
To: Leigh lei...@gmail.com
Cc: Clint Priest cpri...@zerocue.com, internals@lists.php.net
internals@lists.php.net
Date: Tue, 9 Oct 2012 19:33:20 -0700
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
class A {
public $seconds = 3600
Okay, I would like this to be the last time there are revisions to this RFC.
To sum up the last few days of conversations, I have these down as points of
contention:
1. Accessor functions should not be present on the object and callable
directly, for example, $o-__getHours() should not be
On Wed, Oct 10, 2012 at 6:35 PM, Clint Priest cpri...@zerocue.com wrote:
I will come up with some way for people to vote on the issues at hand and
we can cast our votes and be done with it, then I will finish the project
and get it out the door.
-Clint
I very much appreciate your work in
Just a couple of quick remarks.
Clint wrote:
I'm not even sure that automatic backing fields are even desired, I never
felt the need to have them in C# and the only reason they were included is
because they were a part of Dennis's original proposal.
Automatic backing fields are indeed
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a pretty syntax point of view, private final set() {}
and private final get() {} are definitely our best bets. But... from a
logical point of view, I prefer read-only/write-only.
private final get() {} is
that does not have such a feature.
-Original Message-
From: Levi Morrison [mailto:morrison.l...@gmail.com]
Sent: Wednesday, October 10, 2012 8:27 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On Wed, Oct 10, 2012 at 6:35 PM, Clint
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a pretty syntax point of view, private final set() {} and
private final get() {} are definitely our best bets
On Oct 11, 2012 5:00 AM, Clint Priest cpri...@zerocue.com wrote:
Why is everyone so dead set against read-only and write-only?
I could not disagree more with you on what is pretty and readable.
To me:
public read-only $hours {
get { ... }
}
Is infinitely more readable
What about private final set($value) { } tells you that it's read only? There
is a setter.
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, October 11, 2012 12:05 AM
To: Clint Priest
Cc: PHP internals; Jazzer Dane
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
On Oct 11
:* Wednesday, October 10, 2012 9:18 PM
*To:* Clint Priest
*Cc:* internals@lists.php.net
*Subject:* Re: [PHP-DEV] [RFC] Propety Accessors v1.1
** **
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a pretty syntax point of view, private final set
, October 09, 2012 5:08 AM
To: Clint Priest
Cc: internals@lists.php.net; Aaron Holmes; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
While I understand your concern with set being the only keyword using (),
and even agree it's a bit problematic, I see a big problem with using
$value
: Aaron Holmes; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
I agree.
It's more consistent than the $Hours solution and we don't have to
add
another superglobal or magic constant, which is quite nice. The
typehinting is a big plus as well.
On Mon, Oct 8, 2012 at 3
of
$value is fairly irrelevant. Thoughts?
-Original Message-
From: Jazzer Dane [mailto:tbprogram...@gmail.com**]
Sent: Monday, October 08, 2012 5:32 PM
To: Benjamin Eberlei
Cc: Aaron Holmes; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
I agree
, 2012 5:32 PM
To: Benjamin Eberlei
Cc: Aaron Holmes; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
I agree.
It's more consistent than the $Hours solution and we don't have to add
another superglobal or magic constant, which is quite nice. The
typehinting
On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest cpri...@zerocue.com wrote:
It's been a while since I posted any updates about this, a few individuals
have been asking about it privately and wanting me to get it out the door for
PHP 5.5 release. It's come a long way since the last time I posted
Hi,
On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest cpri...@zerocue.com wrote:
It's been a while since I posted any updates about this, a few individuals
have been asking about it privately and wanting me to get it out the
What concerns me with the current implementation is that it leaks many
implementation details, in particular the fact that the accessors are
implemented as *real* __getXYZ methods and automatic implementations
also use *real* $__XYZ properties.
Further to this, take the following example.
Kneuss
Sent: Tuesday, October 09, 2012 8:15 AM
To: Nikita Popov
Cc: Clint Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Hi,
On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest cpri...@zerocue.com
RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
public $property {
set { $this-property = ($this-property*2)+$value }
get;
}
How do I reference the property being set from within the function? The way
I have done it in the example will cause recursion? How can I
This looks great, and essentially has everything I had hoped for!
My only remaining comment is on the read-only and write-only keywords...
this seems really superfluous and strange to me - the syntax (using a
hyphenated keyword) and the feature itself, is way off the grid as compared
to other
On Mon, 2012-10-08 at 11:52 +, Clint Priest wrote:
It's been a while since I posted any updates about this, a few individuals
have been asking about it privately and wanting me to get it out the door for
PHP 5.5 release. It's come a long way since the last time I posted about it.
RFC
I think Leigh brings up some important flaws to in the current RFC. What
Leigh is asking for does not appear to be possible, and in my opinion, it
should be.
I also agree with Rasmus, to a certain extent.
By putting only a getter/setter, the developer essentially sets the
property as read or
On 09/10/12 19:20, Jazzer Dane wrote:
- If we ever get return type hinting/checks then we needn't consider how
the syntax has to look From what I know, this isn't planned for PHP 5.5
and any proposals for it have been largely ignored. Return type hinting
won't help when setting either, although
Wow, I'm surprised by all the talk about this RFC this time around. I posted
this numerous times in the past trying to elicit feedback and got little to
none, so I took the time to write it as I thought it should be written. Some
of these things will take considerable effort to
As an update, just ran some performance testing:
master
Cycles Direct Getter
__get
v1.4 @ 10/8/20121m .05s.21s
.20s
php 5.5.0-dev
Good work Clint!
Performance is probably one of the things people will complain about
so it's good that your benchmark is proving that it's merely identical
to the old __get() approach.
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I
Hi,
This summer (july 15) I did another proposal, which has some connections
with yours.
For the main usage of getters/setters, my guess is that we need separate
read/write visibilities. Your RFC goes beyond that, but I think both are
complementary.
Most of the time, we write getters/setters to
08.10.2012 15:52, Clint Priest пишет:
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
issethttp://www.php.net/isset { return
issethttp://www.php.net/isset($this-Seconds); }
unsethttp://www.php.net/unset {
On 10/8/12 1:07 PM, Denis Portnov wrote:
08.10.2012 15:52, Clint Priest пишет:
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
issethttp://www.php.net/isset { return
issethttp://www.php.net/isset($this-Seconds); }
The set() one is really nice with the typehints.
On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes aa...@aaronholmes.net wrote:
On 10/8/12 1:07 PM, Denis Portnov wrote:
08.10.2012 15:52, Clint Priest пишет:
public $Hours {
get { return $this-Seconds / 3600; }
set {
Eberlei
Cc: Aaron Holmes; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
I agree.
It's more consistent than the $Hours solution and we don't have to add
another superglobal or magic constant, which is quite nice. The
typehinting is a big plus as well.
On Mon, Oct
09.10.2012 5:10, Clint Priest пишет:
Seems a fair amount of people would like it with a definable parameter name,
though the original RFC I based mine off of is more than 4 years old (mine is
over a year old already).
The $value is precisely chosen because it is exactly the way C# operates
]
Sent: Monday, October 08, 2012 5:32 PM
To: Benjamin Eberlei
Cc: Aaron Holmes; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
I agree.
It's more consistent than the $Hours solution and we don't have to add
another superglobal or magic constant, which
, October 08, 2012 10:08 PM
To: Clint Priest
Cc: internals@lists.php.net; Aaron Holmes; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
While I understand your concern with set being the only keyword using (), and
even agree it's a bit problematic, I see a big problem with using
71 matches
Mail list logo
