Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 reading, private writing protected:const $bbb; // protected reading, no writing I read all the messages on the property accessors. And I really agree with the solution of Amaury. It is a nice solution: not verbose, not slower, just covers most of developper's needs. Cal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 such) I think the reflection should return all methods that exist. If the accessors are implemented as PHP methods/functions (and I see no reason why not) then reflection should return it. Reflection, as you pointed out, should tell the truth. There's nothing leaky about it, IMO - yes, it's an implementation detail, so what? If you don't want to use implementation details, don't - just ignore all __ functions and don't call them. Python, for example, has tons of __ functions, and people live just fine with it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 then the truth to him/her is that it's a property accessor and should be reflected as such. The fact that the underlying php One does not contradict the other. Reflection can have specific calls to see properties and accessors, but if accessors are PHP methods - which they should be, since producing more unneeded separate entities that look like methods but aren't quite is wrong - they also should be seen as methods. See for example in Python - special methods have __ to specify they aren't something you should mess with, but they also do not go out of the way to make it a separate concept. We should do the same. We could have option for Reflection to skip __ methods in list calls, maybe - if there's a use case for it - but I currently do not see any use case for it at all. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 this until all fine details aren't hashed out. This is a *huge* feature - one of the biggest ones recently, and has a lot of implications for various scenarios. Property access is what virtually every script in existence does, and doing changes there have implications that touch every corner of the engine. I think Clint is doing a great job with this RFC, but we need to carefully work through all the corners and side cases and relationships with all other features before we can declare it's ready for the prime time. Exactly because it is such a big deal it needs to be refined and polished. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
At this point, the last two weeks of deliberations on this RFC have pushed its release back quite a long ways. I don't know when 5.5 is due out but if it's within the next 6 months (and I'm the only one working on the code) then it will probably not be happening. Due to the dramatic changes that have been talked about, I may just scrap the fork and start over, since I've learned a lot about php-core since starting this a year ago. -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Tuesday, October 16, 2012 4:27 AM To: Paul Dragoonis Cc: Clint 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 this until all fine details aren't hashed out. This is a *huge* feature - one of the biggest ones recently, and has a lot of implications for various scenarios. Property access is what virtually every script in existence does, and doing changes there have implications that touch every corner of the engine. I think Clint is doing a great job with this RFC, but we need to carefully work through all the corners and side cases and relationships with all other features before we can declare it's ready for the prime time. Exactly because it is such a big deal it needs to be refined and polished. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 all fine details aren't hashed out. This is a *huge* feature - one of the biggest ones recently, Exactly because it is such a big deal it needs to be refined and polished. Amen.
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 - one of the biggest ones recently, and has a lot of implications for various scenarios. Property access is what virtually every script in existence does, and doing changes there have implications that touch every corner of the engine. I think Clint is doing a great job with this RFC, but we need to carefully work through all the corners and side cases and relationships with all other features before we can declare it's ready for the prime time. Exactly because it is such a big deal it needs to be refined and polished. But a vote NOT to include it should still be one of the options! The more edge cases I see on this discussion, the more I am convinced that this is simply not right for PHP ... it's not needed and only adds unnecessary bloat. The more the functionality of PHP gets buried in 'magic code' that can't even be debugged properly or viewed the less useful PHP becomes. I'm sorry if people are spending a lot of time trying to make something work, but that is their choice, and should not be a reason to include something. I still don't see how this improves anything when all we need to be doing is managing the existing variables, arrays and objects stored in the object. __get and __set aren't needed either but that is another matter. Does anybody actually use them, or are they waiting for the 'better alternative'? Is there any real reason not simply to be using $obj-var ? It is the fastest way of doing it anyway ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 encompass
Yes it's true, my proposal was focusing on a subset of your RFC. But this
subset is - from my experience - the main usage of accessors.
More, both can work together: My syntax could be used to define the
visibility of reading and writing access, while yours is perfect to add
processing on these accesses.
did I miss something with your original email?
I don't know. It's a matter of choice. I prefer to write:
public:protected $a;
protected:const $b;
Rather than:
public $a {
protected set;
}
protected read-only $b;
I saw you removed your new keywords. I think it's a good thing, because
const was already here (no need for read-only).
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); }
}
The visibility is defined first (how I can use this property?), and then
the code is available if needed (how does it work?). It's the same logic
than when you write private static function foo() { ... }.
Maybe I'm the only one thinking we can imagine an elegant and
understandable syntax that doesn't need to mimic what C# does. But still.
:-)
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 that it does not offer a solution for
the isset() and usset() accessors. Different visibility syntaxes for
get/set and isset/unset would be unlogical and confusing.
Yes, you're right. But I never ever felt the need to define specific
visibility for __isset. On the other hand, I'm using getters and setters
everyday to manage the visibility of my object's attributes. (more about
isset and unset at the end of this email)
I'm trying to solve the main situation, not the special case.
Also, public:protected implies an order which does not have to be kept
in the block AFAIK. What is public and what is protected?
Read it aloud.
public $a { protected set; }
«$a is publicly readable, and protected against writing.»
Exactly the same:
public:protected $a;
«public read, protected write $a»
Seems easy to understand.
public:protected $a { // ???
protected isset() { ... }
private unset() { ... }
get() { ... }
set($value) { ... }
}
I consider that isset() is covered by the attribute's reading visibility,
and unset() is covered by writing visibility. If it's not obvious for you
as it is for me, can you give me some code examples?
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 concerns. It is indeed part of the problem with a project such as this, there is
no head to make a decision, only numerous opinions, none of which come to a
consensus.
Perhaps it is an aspect of the medium of using email for this purpose but it really goes
in every direction at once very quickly and nothing is really ever decided,
it's quite frustrating.
In the end, I just want everyone to come to a consensus on what this should be
and I will go and finish it and be done with it. The original property get/set
RFC has been around for over 3 years and PHP is one of the few modern languages
that does not have such a feature.
Do all RFC's need to become 'law' ?
While on one had I can see the rational behind not SIMPLY using the object
directly, one of the nicest things in PHP has been the short cut to directly
access and update things. Alright it may not be politically correct in some
peoples mind, but isn't it time to think 'Why was PHP4 so popular?' ... because
it was simple and nothing has changed to stop it doing a job. PHP5 seems to get
more and more complex every day ...
Do we need 'reflection' at all?
Do extra hidden things like $o-__getHours() have any place?
Complexity like public set($value) { ... } just seem obscene?
I could make a case for 'public readonly setting;' where the public view can't
write to 'setting' that just seems a logical progression, but instead of
'strict' mode, how about 'simple' mode and disable anything that is not needed
to simply write code ...
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
This is actually the most useful for me imho, why is it confusing? It
creates a property that is a pure getter/setter what 90% of the properties
need. It would be a shame to see this go.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
+1 for private final. Its already there, why not use it.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
The Reflection API has to be such, that I can code-generate a stub of the
class just from the Reflection API.That means that we have to have access
to the getter/setter methods of the property, otherwise we couldnt generate
a stub for public $Hours { public set(DateTime $time) { ... }}
Did I miss anything?
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
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
(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) {
$this-Hours = $h;
}
}
$myTP = new TimePeriod();
echo $myTP-Hours; // 1
$myTP-setHours(3);
echo $myTP-Hours; // 3
$myTP-Hours = 5; // KO. PHP error here
Le 08/10/2012 13:42, Clint Priest a écrit :
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
Cycles Direct Getter
__get
v1.4 @ 10/8/20121m .04sn/a
.21s
Performance of property accessors was important to me as I'm sure it will be to
many, on one million cycles of a simple getter, it's .01s difference.
Depending on the run it is sometimes exactly the same performance.
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Monday, October 08, 2012 6:53 AM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC] Propety Accessors v1.1
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 Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
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 {
unsethttp://www.php.net/unset($this-Seconds); }
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons for
inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code, this
greatly simplified that part of the code and future proofed
it.
The code is available at the url below and is up to date with master, all tests
pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5 release,
only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests still
pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any others
that I have missed, please let me know.
-Clint
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On Oct 11, 2012, at 4:59 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 and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
The latter implies that it can be set within the right context (internally
to the class), which is precisely the opposite of what is desired (read only).
If it can be used on normal properties as well (w/o the overhead of function
calls) then: +1
Otherwise it would not be consistent to introduce it.
On the topic of consistency, could not see any other keyword in php that uses
hyphen in it.
From: Jazzer Dane [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, 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 technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do anything
- but it still works.
But I don't see any sane scenario where someone would want to do the above.
Therefore, it may just be best to use them in place of the currently proposed
read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest
cpri...@zerocue.commailto: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 object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is
no directly suitable replacement but I believe a private final set() { } will
take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors
6. The truth of reflection. Should it reveal details internal to how PHP
works on the inside or should it reflect the way PHP presents it as options?
Did I miss anything?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/11 Clint Priest cpri...@zerocue.com
Why is everyone so dead set against read-only and write-only?
my opinion
1.
public read-only $hours {
get { /* .. */ }
set { /* .. */ }
}
And now? That this is even possible is reason enough for me. Especially now
the engine must take care about this inconsistency (over the whole
inheritance tree). It feels unnecessary.
2. This new keyword is unnecessary
3. Don't know, if it's just my, but I find it slightly annoying, that this
discussion even exists. The engine already knows every token, that is
required to implement this RFC, so whats this all about? This way it will
not be ready for 5.5 and I guess not for 5.6 either...
4. It is more readable, ok, but it is not that much and I think it's just
to less to say Lets rewrite everything and make everything more complex
(see 1.) and such!
I could not disagree more with you on what is pretty and readable.
To me:
public read-only $hours {
get { ... }
}
Is infinitely more readable and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
The latter implies that it can be set within the right context
(internally to the class), which is precisely the opposite of what is
desired (read only).
No, it's not the opposite, but only slightly more loosely: It only says It
is 'set'able from within this concrete class, but it is read-only from
_everywhere_ else, what is in most cases that, what is _really_ wanted. If
you don't want to set it, don't set it. It is your class. And for everyone
else, it's really read-only.
From: Jazzer Dane [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, 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 technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do
anything - but it still works.
But I don't see any sane scenario where someone would want to do the
above. Therefore, it may just be best to use them in place of the currently
proposed read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest cpri...@zerocue.commailto:
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 object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
Did I miss anything?
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
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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
be possible.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 v1.1
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 be possible.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 breaks, and should be a last resort only when absolutely necessary. Re-using existing keywords is the most logical solution. (i.e. suggestions such as public get and protected/private set) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On 10/10/12 10:46 PM, Jazzer Dane wrote:
If at all possible, I'd rather not add extra keywords such as read-only and
write-only to the language. If it's unnecessary than it shouldn't be done -
that's my point of view. The question is thus is read-only necessary?.
The proposal brought up by someone else was using
private final set($value) {}
and
private final get() {}
With no code in-between the braces, the functions are not accessible, not
extensible, and pointless. Thus we could arguably use them as alternatives
to the proposed read/write-only syntax.
But, in my previous emai,l I brought up the fact that this proposal isn't
that logically sound. The above lines of code don't exactly mean that
get/set aren't allowed... but at the same time, I don't know of any
scenarios where a developer would want to use private final get/set wherein
null is always returned or nothing is ever set.
The fact that this proposal is consistent with the language is a plus to
me. But I don't think it's enough - I don't like the logical
inconsistencies it brings.
If I were to vote between the two as to which gets implemented into PHP, I
would probably lean towards read/write-only, but I'm not a fan of either.
In the end, we need it to be logical. Good looking, consistent syntax is
nice, but having something behave even a little bit illogically is not at
all okay.
On Wed, Oct 10, 2012 at 7:59 PM, 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 and understandable than:
** **
public $hours {
get() { ... }
private final set($value) { … }
}
** **
The latter implies that it can be “set” within the right context
(internally to the class), which is precisely the opposite of what is
desired (read only).
** **
*From:* Jazzer Dane [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, 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 technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do
anything - but it still works.
But I don't see any sane scenario where someone would want to do the
above. Therefore, it may just be best to use them in place of the currently
proposed read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, 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 object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
Did I miss anything?
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 suspect this will be unpopular, but is there room in PHP to consider
that the developer will do whatever they want with any classes they
are using?
In an instance where the developer wants to change a property defined as
private, they generally have the option to change the class themselves,
and make it public.
Same with final - if they want to extend a class and overload final
functions, they can change the finality in the overloaded class. Of
course, this is true for private and protected as well.
There is a lot of discussion over read-only, but in the end it ends up
only as a suggestion to the developer using it. Why not just make
set() a no-op, if this is what you want to achieve, and document it as
such? I'm not sure why there is so much talk about
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Rather than go to the trouble of finding a reasonable way to hold a vote on
these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via $o-__getHours(), the
accessor functions will be completely unavailable for use except as property
references ($o-Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and along
with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing field
creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will also
check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes to the
RFC and re-present for final 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 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
allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is
no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the way
PHP presents it as options?
Did I miss anything?
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
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
I'm in favor of all your points Clint and type hinting would be very valuable
to me. Also, I would favor if reflection does not reveal internals either. If I
am correct, that would require ReflectionClass to have
getPropertyAccessors()/getPropertyAccessor('Hours') method and a new
ReflectionPropertyAccessor class for property accessors.
My main point is regarding the read-only issue. I think that, given that the
problem only arises when inheriting from a class defining a property accessor,
a solution would be not to allow to extend accessor property functions (get(),
set(), isset() and unset()) that are not defined in the parent class.
Otherwise, an error should be raised. Something similar is already implemented
in PHP when overriding a parent method with a different signature. Here, we
would not allow to implement a different signature for property accessors in
the child class. So:
class Timing
{
/* … */
/* set() not defined, setting $Hours is not allowed, $Hours is thus
read-only, everybody should agree with this */
public $Hours {
get() { return $this-seconds / 3600; }
final isset() { return isset($this-seconds); }
unset() { unset($this-seconds); }
}
}
class SpecialTiming extends Timing
{
/** … */
public $Hours {
get() { return $this-seconds / 3600; } // -- OK,
set(TypeHint $value) { $this-seconds = 3600 * $value; } // --
ERROR, set() not defined in parent class
final isset() { return isset($this-seconds); } // -- ERROR,
isset() is final in parent class.
/* unset inherited from parent class */
}
}
Am 11.10.2012 um 21:45 schrieb Clint Priest cpri...@zerocue.com:
Rather than go to the trouble of finding a reasonable way to hold a vote on
these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via $o-__getHours(),
the accessor functions will be completely unavailable for use except as
property references ($o-Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and
along with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing field
creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will
also check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes to
the RFC and re-present for final 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 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
allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is
no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the way
PHP presents it as options?
Did I miss anything?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/11 Clint Priest cpri...@zerocue.com
Rather than go to the trouble of finding a reasonable way to hold a vote
on these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via
$o-__getHours(), the accessor functions will be completely unavailable for
use except as property references ($o-Hours)
I don't really care, but what were the concrete objections? You can call
__construct() directly too and that is similar ... not useful ^^ Assuming,
that most developers should try to avoid unuseful stuff, wouldn't it be
more complicated to explicitly restrict the access?
2) Change syntax to use public set($value) { }, public get(), etc. (and
along with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing
field creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will
also check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes
to the RFC and re-present for final 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 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
allowed.
2. Preferred syntax for accessors should be public set($value) { ...
} with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them?
There is no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the
way PHP presents it as options?
Did I miss anything?
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
--
github.com/KingCrunch
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.com
Rather than go to the trouble of finding a reasonable way to hold a vote
on these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via
$o-__getHours(), the accessor functions will be completely unavailable for
use except as property references ($o-Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and
along with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing
field creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will
also check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes
to the RFC and re-present for final 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 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
allowed.
2. Preferred syntax for accessors should be public set($value) { ...
} with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them?
There is no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the
way PHP presents it as options?
Did I miss anything?
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
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
I guess I didn't see any other support for it from others and it is a subset of
what the RFC I am proposing would encompass, did I miss something with your
original email?
From: amaury.bouch...@gmail.com [mailto:amaury.bouch...@gmail.com] On Behalf Of
Amaury Bouchard
Sent: Thursday, October 11, 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 to the trouble of finding a reasonable way to hold a vote on
these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via $o-__getHours(), the
accessor functions will be completely unavailable for use except as property
references ($o-Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and along
with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing field
creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will also
check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes to the
RFC and re-present for final agreement...
Or... do ya'll want to vote on the aforementioned changes?
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.commailto:cpri...@zerocue.com]
Sent: Wednesday, October 10, 2012 7:36 PM
To: internals@lists.php.netmailto: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 functions should not be present on the object and callable
directly, for example, $o-__getHours() should not be
allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is
no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the way
PHP presents it as options?
Did I miss anything?
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
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 superfluous. It's very similar
to what is currently done in Singleton classes that usually have
private constructors.
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) { ... }
}
The reasoning for this feature is that in object-oriented design you
have to process logic when establishing bidirectional associations
between objects. For example, adding an Address to a Contact instance
would require Address::$Contact to be set as well if the association
is bidirectional.
public $Addresses {
offsetSet($offset, $address) {
$address-Contact = $this;
}
}
$contact-Addresses[] = new Address();
What do you think about supporting this?
Cheers,
Bernhard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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, David Muir davidkm...@gmail.com wrote:
That said, it wouldn't help for scalar values, and that leads to a problem
with the current syntax (AFAICS). You can't specify the initial value for a
property:
This is one of the points I was trying to get across, there is
currently no way to set the default value*. If your setter performs
some sort of calculation on the value, then you're going to have to
reverse that process in order to set the initial value constructor.
*Unless you use the following highly confusing approach.
class MyClass {
protected $__property = 'default';
public $property {
get;
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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. Some of these things will take considerable effort to
fix/correct/change.
Sometimes things get overlooked. Lots of suggestions make their way to
the list, usually by people who have no way to implement the feature
and they disappear as quickly as they are suggested. Be happy you ARE
getting feedback now. The fact people now see this as something that
may be implemented as it is (in a way they don't necessarily like) is
prompting them to speak up about their concerns.
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 problem (the ability to use it as a
getter or call it as a function), but see my comments at the end. I also
don’t particularly see the point of auto implemented getters/setters (
public $h { get; set; } )
For me the problem is simply that you can call the accessor functions
directly. I don't like it.
I don't like the fact that accessors and their associated properties
are implemented as direct (yet slightly obfuscated/hidden) elements of
the containing class. It's unintuitive (I'd even go as far as saying
confusing)
A property should be a property, not a collection of hidden methods
and variables. If it needs to be seen whether a property implements
accessors, this should be done through reflection.
## 3 - Can directly access $__automaticProperty and even unset it (causing
notices in the internal code)
I'm not even sure that automatic backing fields are even desired
See above I guess, I agree that these hidden properties should not
exist in the first place.
I think it would
be better to cleanly separate out the accessor implementation. It might
require more code now, but will be better in the long run.
All three of these issues, could be addressed I believe by not having the
functions and/or properties a part of the ordinary HashTables, or to have
flags set on them. I believe there is already a SHADOW flag type defined
which may be able to be used for this type of functionality.
Nikita do you have any other proposals for how this should be
addressed? I think most of my concerns with this revolve around the
implementation not being cleanly separated as you put it. I believe
that setters/getters would be a tremendously powerful and useful
addition to the language, just not quite like this, so lets here your
proposal please :)
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 assign to
self?
Generally speaking, I don't know why you would use an automatic backing
getter with a separate setter, but if you wanted to do that, at present you
would access the automatic backing field by $this-__property.
Kind of confusing. We have to think of the users who just want to pick
this up and run with it. You can't say I don't know why you would,
because people will do strange things, and you have to make it so that
the behaviour is predictable, and intuitive.
The above will not cause recursion, it is protected from recursion by the
same mechanism that __get() and __set() are protected.
Good, thanks. I didn't get to test it since I was on a bus at the time :)
In fact, the above
code would set an actual property named $property on the object which would
then side-step the accessor entirely (true properties take precedence over
accessors, though they may only be set from within the setter of the
accessor. This may be a bit confusing, but I specifically wrote it this way
for the purpose of lazy-loading.
Yep, confusing!
The first access of the $objList property getter would create the object and
attempt to set its-self which would be passed to the setter, the setter (now
guarded) will directly set the property on the object, further calls to
$objList would retrieve the already created object (bypassing the accessor).
To get out of that situation, you would simply unset($objList) and the
accessor would take over again.
Also confusing. (Think of the users!)
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'm really not quite clear on what Leigh was going for with the code she
indicated, I think she was trying to demonstrate infinite recursion which is
not possible due to guards.
She? Only when I go shoe shopping with Nikita at the weekends...
Actually
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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() { ... }
offsetUnset($offset) { ... }
offsetExists($offset) { ... }
}
Definitely on the nice to have list.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 {
get() {
if(!is_null($this-seconds)) {
return $this-seconds;
} else {
return 10; // 10 is default
}
}
}
}
The above should work fine in many scenarios, right?
We could perhaps then claim that the issue may rather be that we need
access to the variable *$hours* itself inside of the get/set/etc functions,
which I think has been brought up before - though I'm not so sure how
sensible that is. Whether we need that or not is up in the air.
2) read-only and write-only is ugly. While this is a bias, I think we can
do better.
One idea I had is exactly what bernhard suggesting - using *final private
set() {}* to achieve read-only functionality.
My problem with this implementation is that it's not as logical as I'd
prefer. In my eyes, from a logical point of view, just the fact that set is
there means that it works. Thus it just so happens that, while setting the
variable doesn't error out, it does absolutely nothing.
While I don't see any real world scenarios where people would want this
behavior, I still am wrestling with this proposed implementation, as I
think that, logically speaking, set should work but just not do anything.
Whether or not this is illogical is arguably none of our concern - it's the
coder's concern. Hmm.
I'd definitely like to explore other alternatives to this solution.
Already proposed:
public read-only $property {
get() { ... }
}
public $property {
get() { ... }
final private set() {};
}
I'm going to throw out some alternatives just for the sake of it. They may
be more illogical than I'd prefer, but I'm just trying to get the juices
flowing:
public $property {
get() { ... }
final private set;
}
public $property {
get() { ... }
final private set();
}
public $property {
get_only() { ... } // Same as get but implies read only; set not
allowed to be defined. In case of set_only and get_only, top one has
precedence.
}
public $property {
set(read_only);
get() { ... }
}
public $property {
read_only; // or read_only();
get() { ... }
}
3) I'll agree with Leigh here:
I don't like the fact that accessors and their associated properties are
implemented as direct (yet slightly obfuscated/hidden) elements of the
containing class. It's unintuitive (I'd even go as far as saying confusing).
4) In regards to array accessors, it'd be nice to have but not at all
necessary.
On Wed, Oct 10, 2012 at 2:29 AM, Leigh lei...@gmail.com wrote:
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() { ... }
offsetUnset($offset) { ... }
offsetExists($offset) { ... }
}
Definitely on the nice to have list.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 here is subjective.
Does the PHP programmer need the truth of underlying language implementation
details or do they need the truth of what they've defined?
I would argue that if the PHP programmer has defined a property accessor then
the truth to him/her is that it's a property accessor and should be reflected
as such. The fact that the underlying php language implements it internally as
a series of functions isn't relevant and is a distortion of the truth, from the
perspective of the PHP programmer.
On 10 October 2012 04:28, David Muir davidkm...@gmail.com wrote:
That said, it wouldn't help for scalar values, and that leads to a
problem with the current syntax (AFAICS). You can't specify the
initial value for a
property:
This is one of the points I was trying to get across, there is currently no
way to set the default value*. If your setter performs some
sort of calculation on the value, then you're going to have to reverse that
process in order to set the initial value constructor.
*Unless you use the following highly confusing approach.
class MyClass {
protected $__property = 'default';
public $property {
get;
}
}
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
Property accessors are not properties, they do not have their own data storage
memory space.
Let's take a big example here, lets expand on the TimePeriod class...
class TimePeriod {
private $_Seconds = 600;
public $Seconds {
get { return $this-_Seconds; }
set { $this-_Seconds = $value; }
}
public $Minutes {
get { return $this-Seconds / 60; }
set { $this-Seconds = $value * 60; }
}
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value * 3600; }
}
public $Days { ... }
public $Weeks { ... }
public $Months { ... }
public $Years { ... }
public $Decades { ... }
public $Centuries { ... }
}
Now, this class's data space is one variable ($_Seconds), if we were to
some-how deviate from (afaik) every other language which implements property
accessors and create a memory space for every property accessor (none of
which would be used by the above code), this classes data space now becomes 10
variables, only 1 of which is used.
I'll take this example to another language many people should be familiar with,
Javascript:
{
_Seconds: 600,
get Seconds() { return this._Seconds; },
get Minutes() { return this._Seconds / 60; }
get Hours() { return this._Seconds / 3600; }
...
}
These 'getters' do not get their own memory space allocated, they *are not*
properties, they are getters.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 on the nice to have list.
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) { ... }
offsetGet() { ... }
offsetUnset($offset) { ... }
offsetExists($offset) { ... }
}
// In base class where the proposed additional accessor types were suggested
public $Addresses = new Addresses();
Or if you felt like using an accessor to control access to the Addresses
object, you could implement that as well, but an accessor wouldn't even be
necessary.
This would provide for cleaner object-oriented principles, the logic for
dealing with acceptance of a new address stays within a class designed to hold
and control access to the collection of addresses.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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) { ... }
offsetGet() { ... }
offsetUnset($offset) { ... }
offsetExists($offset) { ... }
}
This approach does not work for the use case I presented:
class Addresses implements ArrayAccess {
public function offsetSet($offset, $address) {
$this-_Addresses[] = $address;
$address-Contact = $contact; // where do we get the contact from?
}
}
If we pass $contact to the Addresses instance, the class is bound to
Contact and cannot be used anymore for different associations that
* do not involve Contact
* have a different arity (one-to-many: $address-Contact = $contact,
many-to-many: $address-Contacts[] = $contact)
Consequently, we would need to create a new collection class for each
to-many association, which is neither pragmatic nor good OO design.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 problem (the ability to use it as a
getter or call it as a function), but see my comments at the end. I
also don't particularly see the point of auto implemented
getters/setters ( public $h { get; set; } )
For me the problem is simply that you can call the accessor functions
directly. I don't like it.
I don't like the fact that accessors and their associated properties are
implemented as direct (yet slightly obfuscated/hidden)
elements of the containing class. It's unintuitive (I'd even go as far as
saying
confusing)
A property should be a property, not a collection of hidden methods and
variables. If it needs to be seen whether a property
implements accessors, this should be done through reflection.
Leigh, a property IS a property, a property accessor IS a series of functions.
## 3 - Can directly access $__automaticProperty and even unset it
(causing notices in the internal code)
I'm not even sure that automatic backing fields are even desired
See above I guess, I agree that these hidden properties should not exist in
the first place.
If this automatic implementation { get; set; } is not desired, I'd be happy to
rip it out, I never wanted it in the first place. This is the only case in
which a real property is automatically implemented.
I think it would
be better to cleanly separate out the accessor implementation. It
might require more code now, but will be better in the long run.
All three of these issues, could be addressed I believe by not having
the functions and/or properties a part of the ordinary HashTables, or
to have flags set on them. I believe there is already a SHADOW flag
type defined which may be able to be used for this type of functionality.
Nikita do you have any other proposals for how this should be addressed? I
think most of my concerns with this revolve around the
implementation not being cleanly separated as you put it. I believe that
setters/getters would be a tremendously powerful and useful
addition to the language, just not quite like this, so lets here your
proposal please :)
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
assign to self?
Generally speaking, I don't know why you would use an automatic
backing getter with a separate setter, but if you wanted to do that,
at present you would access the automatic backing field by
$this-__property.
Kind of confusing. We have to think of the users who just want to pick this
up and run with it. You can't say I don't know why you
would, because people will do strange things, and you have to make it so
that the behaviour is predictable, and intuitive.
I agree completely, what are you trying to achieve because the above code makes
it look like you are thinking of accessors as properties, which they are not.
Accessors do not have their own memory space.
The above will not cause recursion, it is protected from recursion by
the same mechanism that __get() and __set() are protected.
Good, thanks. I didn't get to test it since I was on a bus at the time :)
In fact, the above
code would set an actual property named $property on the object which
would then side-step the accessor entirely (true properties take
precedence over accessors, though they may only be set from within
the setter of the accessor. This may be a bit confusing, but I
specifically wrote it this way for the purpose of lazy-loading.
Yep, confusing!
Well it's confusing because you wrote it that way... thinking that somehow
$property has its own memory space which it does not.
The first access of the $objList property getter would create the
object and attempt to set its-self which would be passed to the
setter, the setter (now
guarded) will directly set the property on the object, further calls
to $objList would retrieve the already created object (bypassing the
accessor).
To get out of that situation, you would simply unset($objList) and the
accessor would take over again.
Also confusing. (Think of the users!)
This does not need to be used, it's simply a way it can be used. Again, the
confusion I think you are running into is that you think that a property
accessor has it's own memory space, which it does not have.
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'm really not quite clear on what Leigh was going for with the code
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 truth, or there is no point in it. Unfortunately the truth here is subjective. Does the PHP programmer need the truth of underlying language implementation details or do they need the truth of what they've defined? I would argue that if the PHP programmer has defined a property accessor then the truth to him/her is that it's a property accessor and should be reflected as such. The fact that the underlying php language implements it internally as a series of functions isn't relevant and is a distortion of the truth, from the perspective of the PHP programmer. The truth is like 2this is what the engine is behaving like. To my understanding those methods could be called explicitly and exist. As such for the engine they are there. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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
would eliminate this as an issue.
I just did a bit of research regarding this topic and I have found the
following reasons why automatic properties exist in C#:
1. Changing a field to a property breaks the binary interface, so all
code using the library has to be recompiled. If you are using an
automatic property you can safely add additional behavior for it
later.
2. Properties support data binding, whereas fields do not.
3. There are attributes that work for properties, but don't work for fields.
4. Reflection for fields and properties works differently, so changing
a field to a property is a BC break.
I guess that #1 is the most important one (you don't want to break the
interface) and it obviously does not apply to PHP. Points #2 and #3
also don't apply as PHP has neither data binding not attributes. #4
also doesn't seem to apply because ReflectionPropertyAccessor defines
all the methods that ReflectionProperty defines, so changing
field-property should be okay there too.
From that I would conclude that the automatic properties are really
not needed in PHP. I think they will only cause confusion as to when
one should use `public $name;` and when one should use `public $name {
get; set; };`.
The only thing I'm not sure about is how read-only / write-only
properties rely on automatic properties with your current
implementation. If the automatic properties aren't needed there
either, then I think they can be safely removed.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 would eliminate this as an issue.
I just did a bit of research regarding this topic and I have found the
following reasons why automatic properties exist in C#:
1. Changing a field to a property breaks the binary interface, so all code
using the library has to be recompiled. If you are using an
automatic property you can safely add additional behavior for it later.
2. Properties support data binding, whereas fields do not.
3. There are attributes that work for properties, but don't work for fields.
4. Reflection for fields and properties works differently, so changing a
field to a property is a BC break.
I guess that #1 is the most important one (you don't want to break the
interface) and it obviously does not apply to PHP. Points #2 and #3 also
don't apply as PHP has neither data binding not attributes. #4
also doesn't seem to apply because ReflectionPropertyAccessor defines all the
methods that ReflectionProperty defines, so
changing
field-property should be okay there too.
From that I would conclude that the automatic properties are really not
needed in PHP. I think they will only cause confusion as to
when one should use `public $name;` and when one should use `public $name {
get; set; };`.
The only thing I'm not sure about is how read-only / write-only properties
rely on automatic properties with your current
implementation. If the automatic properties aren't needed there either, then
I think they can be safely removed.
Nice, I would agree that we should eliminate the automatic get/set since the
reason they exist in C# is not an issue in PHP and it has only served to
confuse everyone.
With the read-only and write-only, they are separate from automatic
getters/setters really. If you define a read-only with {get;} it's the same as
any other getter.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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
issethttp://www.php.net/isset($this-Seconds); }
unsethttp://www.php.net/unset {
unsethttp://www.php.net/unset($this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And except for
superglobals I guess there is no such thing in PHP, so it looks bit puzzling
to me. I'd suggest on of the following:
- variable for value has the same name as property
public $Hours {
set { $this-Seconds = $Hours * 3600; }
}
- magic constant
public $Hours {
set { $this-Seconds = __VALUE__ * 3600; }
}
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds = $dateTime-getTimestamp();
}
}
If this function inspired syntax is used, then it kind of hints the possibility
of future parameter overloading, like:
public $Hours {
set ( DateTime $dateTime ) { $this-Seconds = $dateTime-getTimestamp(); }
set ( int $hours ) { $this-Seconds = $hours*60*60; }
}
So for me +1 on that syntax, or using/future-proofing for the syntax from C#:
public DateTime $Hours {
set { $this-Seconds = $value-getTimestamp(); }
}
However the example doesn't make much sense (hours being datetime).
- or at least have it in same format as superglobals
public $Hours {
set { $this-Seconds = $_VALUE * 3600; }
}
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
There's no way to stop the developer from doing that without read-only.
Yes, there is - I don't even know why would write it that way - doesn't
seem to make much sense.
What you probably should be doing, is this:
class A {
private $seconds = 3600;
public $hours {
get() { return $this-seconds / 3600 };
}
}
Keep your field private - now try extending this with a write-accessor.
I think that read-only is really almost merely a pseudonym for read-only
accessor for a private field - what you're really trying to do, is protect
the field behind the accessor, not the accessor itself.
In the same way, write-only is practically synonymous with write-only
accessor for a private field - to some extend (at least) the point of
having accessors to begin with, is to protect the underlying value(s) from
unauthorized or incorrect use.
You can relax your read-only or write-only accessors by declaring the
backing field(s) protected - this would be the equivalent of declaring a
read-only accessor that you are permitted to extend with a write-accessor
if you need to...
-- Forwarded message --
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;
public $hours {
get() { return $this-seconds / 3600 };
}
}
class B extends A {
public $hours { // Maintains 'get' from class A
set($value) { $this-seconds = $value; }
}
}
^There's no way to stop the developer from doing that without read-only.
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Jazzer's example was extending an accessor and her statement about no way to
stop the developer from doing what she did there without read-only is correct.
There are other, more verbose and less simple ways to accomplish read-only and
write-only (preventing sub-classes from defining a getter, etc, namely through
the use of final) but none of them are as simple and easily readable as public
read-only $hours { ... }
-Original Message-
From: Rasmus Schultz [mailto:ras...@mindplay.dk]
Sent: Wednesday, October 10, 2012 6:47 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
There's no way to stop the developer from doing that without read-only.
Yes, there is - I don't even know why would write it that way - doesn't seem
to make much sense.
What you probably should be doing, is this:
class A {
private $seconds = 3600;
public $hours {
get() { return $this-seconds / 3600 };
}
}
Keep your field private - now try extending this with a write-accessor.
I think that read-only is really almost merely a pseudonym for read-only
accessor for a private field - what you're really trying to
do, is protect the field behind the accessor, not the accessor itself.
In the same way, write-only is practically synonymous with write-only
accessor for a private field - to some extend (at least) the
point of having accessors to begin with, is to protect the underlying
value(s) from unauthorized or incorrect use.
You can relax your read-only or write-only accessors by declaring the backing
field(s) protected - this would be the equivalent of
declaring a read-only accessor that you are permitted to extend with a
write-accessor if you need to...
-- Forwarded message --
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;
public $hours {
get() { return $this-seconds / 3600 };
}
}
class B extends A {
public $hours { // Maintains 'get' from class A
set($value) { $this-seconds = $value; }
}
}
^There's no way to stop the developer from doing that without read-only.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 functions should not be present on the object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... } with
no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is no
directly suitable replacement but I believe a private final set() { } will take
care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors
6. The truth of reflection. Should it reveal details internal to how PHP
works on the inside or should it reflect the way PHP presents it as options?
Did I miss anything?
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
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 this area, Clint, but please, please do not try to push this out the door. This is not how we need PHP to be developed. This is a highly useful feature and should not be taken lightly. Things should be thought carefully and over a period by many people. There can be others to pick up the work if you cannot sustain it over the next few months. What we do not want or need is a new feature that is pushed out the door too early. Levi Morrison -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 necessary in C# for various technical reasons none of which have any bearing on the PHP language - Nikita explained this in another e-mail. So I vote for dropping automatic auto-implemented accessors. In PHP, an auto-implemented accessor really would be almost identical to a regular property anyhow. I would also add that the double-underscore convention for the field-name seems somewhat spooky to me - double-underscore is generally reserved for PHP internal stuff... now suddenly these would be userland-fields. Seems wrong. Clint, I am sorry these issue were not surfaced earlier... I do seem to recall sending a very long e-mail highlighting many of these issues a long while back though (?) ... I only watch the list with half an eye, but I usually speak up when I feel strongly about something. You're doing a great job here! I hope you you will see it through - this would be a fantastic feature which will make for better code architecture in so many ways.
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. But... from a
logical point of view, I prefer read-only/write-only.
private final get() {} is technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do
anything - but it still works.
But I don't see any sane scenario where someone would want to do the above.
Therefore, it may just be best to use them in place of the currently
proposed read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, 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 object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
Did I miss anything?
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
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Hey Levi, 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 concerns. It is indeed part of the problem with a project such as this, there is no head to make a decision, only numerous opinions, none of which come to a consensus. Perhaps it is an aspect of the medium of using email for this purpose but it really goes in every direction at once very quickly and nothing is really ever decided, it's quite frustrating. In the end, I just want everyone to come to a consensus on what this should be and I will go and finish it and be done with it. The original property get/set RFC has been around for over 3 years and PHP is one of the few modern languages 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 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 this area, Clint, but please, please do not try to push this out the door. This is not how we need PHP to be developed. This is a highly useful feature and should not be taken lightly. Things should be thought carefully and over a period by many people. There can be others to pick up the work if you cannot sustain it over the next few months. What we do not want or need is a new feature that is pushed out the door too early. Levi Morrison -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
The latter implies that it can be set within the right context (internally to
the class), which is precisely the opposite of what is desired (read only).
From: Jazzer Dane [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, 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 technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do anything -
but it still works.
But I don't see any sane scenario where someone would want to do the above.
Therefore, it may just be best to use them in place of the currently proposed
read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest
cpri...@zerocue.commailto: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 object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... } with
no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is no
directly suitable replacement but I believe a private final set() { } will take
care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors
6. The truth of reflection. Should it reveal details internal to how PHP
works on the inside or should it reflect the way PHP presents it as options?
Did I miss anything?
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
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
Fully agreed. It is obvious and clear like water.
Cheers,
Pierre
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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, 2012 5:00 AM, Clint Priest
cpri...@zerocue.commailto: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 and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
Fully agreed. It is obvious and clear like water.
Cheers,
Pierre
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
If at all possible, I'd rather not add extra keywords such as read-only and
write-only to the language. If it's unnecessary than it shouldn't be done -
that's my point of view. The question is thus is read-only necessary?.
The proposal brought up by someone else was using
private final set($value) {}
and
private final get() {}
With no code in-between the braces, the functions are not accessible, not
extensible, and pointless. Thus we could arguably use them as alternatives
to the proposed read/write-only syntax.
But, in my previous emai,l I brought up the fact that this proposal isn't
that logically sound. The above lines of code don't exactly mean that
get/set aren't allowed... but at the same time, I don't know of any
scenarios where a developer would want to use private final get/set wherein
null is always returned or nothing is ever set.
The fact that this proposal is consistent with the language is a plus to
me. But I don't think it's enough - I don't like the logical
inconsistencies it brings.
If I were to vote between the two as to which gets implemented into PHP, I
would probably lean towards read/write-only, but I'm not a fan of either.
In the end, we need it to be logical. Good looking, consistent syntax is
nice, but having something behave even a little bit illogically is not at
all okay.
On Wed, Oct 10, 2012 at 7:59 PM, 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 and understandable than:
** **
public $hours {
get() { ... }
private final set($value) { … }
}
** **
The latter implies that it can be “set” within the right context
(internally to the class), which is precisely the opposite of what is
desired (read only).
** **
*From:* Jazzer Dane [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, 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 technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do
anything - but it still works.
But I don't see any sane scenario where someone would want to do the
above. Therefore, it may just be best to use them in place of the currently
proposed read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, 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 object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
Did I miss anything?
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
** **
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
I personally like the idea by Denis Portnov with the magic constant __VALUE__
which goes along with other magic constants documented here
http://www.php.net/manual/en/language.constants.predefined.php
But the advantage of the type hinting in the setter when we use set($value)
should be weighted stronger. This is a great plus!
I would vote for Jazzer's
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}
Best regards
Christian Stoller
-Original Message-
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: Tuesday, 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.
Even if $value internally makes sense due to something along the lines of *
__setHours($value)* {} being equal to *set {}*, I think using $value
without it ever being defined in the developer's code is not at all a good
idea.
If I see $value in the code, I'll logically look for where it was defined,
and when I don't see it anywhere else in the code, things are going to very
quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a note in
the documentation. That's not enough.
A similar alternative to using $value that I'd argue would be much more
sensible would be to, as Denis mentioned, use either a magic constant or a
superglobal.
As I mentioned previously, I would rather go with the set($value) {} syntax.
Now, back to the part where I agree with you - the inconsistency wherein
set has () that denote it is a method but get, isset, and unset do not. I
see this inconsistency as something problematic enough to warrant a
solution.
We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}
Yes, we now have a little bit more meat on the syntax, but in this case, I
don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which they are!
If anything, adding parenthesis to all of them makes the implementation *
more* sensible.
2) It's *only* two more characters per function. On top of that, in my
opinion, this syntax is not ugly. In fact, as I just mentioned - this
implementation is arguably *more* consistent with the rest of PHP.
On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest cpri...@zerocue.com wrote:
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
and the original author thought to keep it the same as another well-known
language (why re-invent new syntax for no reason).
That being said, javascript does indeed allow it, my concern then would be
would we have the parameterized syntax only for set() and not get, isset or
unset?
If we do have them for all of them, it's a lot of extra characters with no
real need.
I definitely favor set($value) over a magic $Hours for the $Hours
property, but I personally see no problem with the $value, it's not magic
it's a locally defined variable.
Internally, this:
public $Hours {
get { ... }
set { ... }
}
Is implemented as standard functions, while they are hidden through
reflection, these functions exist (as a result of the above example):
public __getHours() { ... }
public __setHours($value) { ... }
Lastly, with regards to JavaScript style getters/setters, I don't think
I've ever cared what the variable name was, I typically just do something
like:
set blah(x) { ... } -- x is fairly irrelevant and similarly the use 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.
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:26 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
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 { $this-Seconds = $value; }
issethttp://www.php.net/isset** { return isset
http://www.php.net/isset**($this-Seconds); }
unsethttp://www.php.net/unset** { unset
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
[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.
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:26 PM, Benjamin Eberlei
kont...@beberlei.de
wrote:
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 { $this-Seconds = $value; }
issethttp://www.php.net/isset** { return isset
http://www.php.net/isset**($this-Seconds); }
unsethttp://www.php.net/unset** { unset
http://www.php.net/unset**($this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And
except
for superglobals I guess there is no such thing in PHP, so it
looks
bit puzzling to me. I'd suggest on of the following:
- setter resambles setter method, wich also allows
typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
This seems like the cleanest method, in my opinion.
Javascript
does
this
for object prototypes:
http://ejohn.org/blog/**javascript-getters-and-**setters/
http://ejohn.org/blog/javascript-getters-and-setters/
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List To
unsubscribe,
visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
characters per function. On top of that, in my
opinion, this syntax is not ugly. In fact, as I just mentioned - this
implementation is arguably *more* consistent with the rest of PHP.
On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest cpri...@zerocue.com wrote:
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
and the original author thought to keep it the same as another well-known
language (why re-invent new syntax for no reason).
That being said, javascript does indeed allow it, my concern then would
be
would we have the parameterized syntax only for set() and not get, isset
or
unset?
If we do have them for all of them, it's a lot of extra characters with
no
real need.
I definitely favor set($value) over a magic $Hours for the $Hours
property, but I personally see no problem with the $value, it's not magic
it's a locally defined variable.
Internally, this:
public $Hours {
get { ... }
set { ... }
}
Is implemented as standard functions, while they are hidden through
reflection, these functions exist (as a result of the above example):
public __getHours() { ... }
public __setHours($value) { ... }
Lastly, with regards to JavaScript style getters/setters, I don't think
I've ever cared what the variable name was, I typically just do something
like:
set blah(x) { ... } -- x is fairly irrelevant and similarly the use 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.
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:26 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
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 { $this-Seconds = $value; }
issethttp://www.php.net/**isset**http://www.php.net/isset**
{ return isset
http://www.php.net/isset**($**this-Seconds); }
unsethttp://www.php.net/**unset**http://www.php.net/unset**
{ unset
http://www.php.net/unset**($**this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And
except
for superglobals I guess there is no such thing in PHP, so it
looks
bit puzzling to me. I'd suggest on of the following:
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
This seems like the cleanest method, in my opinion. Javascript
does
this
for object prototypes:
http://ejohn.org/blog/javascript-getters-and-setters/http://ejohn.org/blog/**javascript-getters-and-**setters/
http://ejohn.org/blog/**javascript-getters-and-**setters/http://ejohn.org/blog/javascript-getters-and-setters/
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List To
unsubscribe,
visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
, I would rather go with the set($value) {}
syntax.
Now, back to the part where I agree with you - the inconsistency wherein
set has () that denote it is a method but get, isset, and unset do not. I
see this inconsistency as something problematic enough to warrant a
solution.
We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}
Yes, we now have a little bit more meat on the syntax, but in this case, I
don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which they
are!
If anything, adding parenthesis to all of them makes the implementation *
more* sensible.
2) It's *only* two more characters per function. On top of that, in my
opinion, this syntax is not ugly. In fact, as I just mentioned - this
implementation is arguably *more* consistent with the rest of PHP.
On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest cpri...@zerocue.com wrote:
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
and the original author thought to keep it the same as another well-known
language (why re-invent new syntax for no reason).
That being said, javascript does indeed allow it, my concern then would
be
would we have the parameterized syntax only for set() and not get, isset
or
unset?
If we do have them for all of them, it's a lot of extra characters with
no
real need.
I definitely favor set($value) over a magic $Hours for the $Hours
property, but I personally see no problem with the $value, it's not magic
it's a locally defined variable.
Internally, this:
public $Hours {
get { ... }
set { ... }
}
Is implemented as standard functions, while they are hidden through
reflection, these functions exist (as a result of the above example):
public __getHours() { ... }
public __setHours($value) { ... }
Lastly, with regards to JavaScript style getters/setters, I don't think
I've ever cared what the variable name was, I typically just do something
like:
set blah(x) { ... } -- x is fairly irrelevant and similarly the use 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.
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:26 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
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 { $this-Seconds = $value; }
issethttp://www.php.net/**isset**http://www.php.net/isset**
{ return isset
http://www.php.net/isset**($**this-Seconds); }
unsethttp://www.php.net/**unset**http://www.php.net/unset**
{ unset
http://www.php.net/unset**($**this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And
except
for superglobals I guess there is no such thing in PHP, so it
looks
bit puzzling to me. I'd suggest on of the following:
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
This seems like the cleanest method, in my opinion. Javascript
does
this
for object prototypes:
http://ejohn.org/blog/javascript-getters-and-setters/http://ejohn.org/blog/**javascript-getters-and-**setters/
http://ejohn.org/blog/**javascript-getters-and-**setters/http://ejohn.org/blog/javascript-getters-and-setters/
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List To
unsubscribe,
visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 about it.
RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
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 {
unsethttp://www.php.net/unset($this-Seconds); }
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons for
inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code, this
greatly simplified that part of the code and future proofed it.
The code is available at the url below and is up to date with master, all
tests pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5
release, only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests
still pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any
others that I have missed, please let me know.
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.
A few examples:
## 1 - __getProperty() method directly callable
class Test {
public $property {
get { return 123; }
}
}
$test = new Test;
var_dump($test-property); // int(123)
var_dump($test-__getProperty()); // int(123)
## 2 - __getProperty() method exposed via exception
class Test {
public $throwingProperty {
get { throw new Exception; }
}
}
(new Test)-throwingProperty;
exception 'Exception' in /home/nikic/dev/php-src/t29.php:9
Stack trace:
#0 /home/nikic/dev/php-src/t29.php(31): Test-__getthrowingProperty()
#1 {main}
## 3 - Can directly access $__automaticProperty and even unset it
(causing notices in the internal code)
class Test {
public $automaticProperty {
get; set;
}
public function getAutomaticProperty() {
return $this-__automaticProperty;
}
public function unsetAutomaticProperty() {
unset($this-__automaticProperty);
}
}
$test-automaticProperty = 'foo';
var_dump($test-getAutomaticProperty());
$test-unsetAutomaticProperty();
var_dump($test-automaticProperty);
string(3) foo
Notice: Undefined property: Test::$__automaticProperty in
/home/nikic/dev/php-src/t29.php on line 13
NULL
=
I feel like this approach to the implementation will be a big can of
worms. Sure, it works, but it is rather fragile and the enduser ends
up dealing with internal stuff which he ought not care about. I think
it would be better to cleanly separate out the accessor
implementation. It might require more code now, but will be better in
the long run.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 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 Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
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 {
unsethttp://www.php.net/unset($this-Seconds); }
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons
for inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code, this
greatly simplified that part of the code and future proofed it.
The code is available at the url below and is up to date with master, all
tests pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5
release, only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests
still pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any
others that I have missed, please let me know.
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.
A few examples:
## 1 - __getProperty() method directly callable
class Test {
public $property {
get { return 123; }
}
}
$test = new Test;
var_dump($test-property); // int(123)
var_dump($test-__getProperty()); // int(123)
## 2 - __getProperty() method exposed via exception
class Test {
public $throwingProperty {
get { throw new Exception; }
}
}
(new Test)-throwingProperty;
exception 'Exception' in /home/nikic/dev/php-src/t29.php:9
Stack trace:
#0 /home/nikic/dev/php-src/t29.php(31): Test-__getthrowingProperty()
#1 {main}
## 3 - Can directly access $__automaticProperty and even unset it
(causing notices in the internal code)
class Test {
public $automaticProperty {
get; set;
}
public function getAutomaticProperty() {
return $this-__automaticProperty;
}
public function unsetAutomaticProperty() {
unset($this-__automaticProperty);
}
}
$test-automaticProperty = 'foo';
var_dump($test-getAutomaticProperty());
$test-unsetAutomaticProperty();
var_dump($test-automaticProperty);
string(3) foo
Notice: Undefined property: Test::$__automaticProperty in
/home/nikic/dev/php-src/t29.php on line 13
NULL
=
I feel like this approach to the implementation will be a big can of
worms. Sure, it works, but it is rather fragile and the enduser ends
up dealing with internal stuff which he ought not care about. I think
it would be better to cleanly separate out the accessor
implementation. It might require more code now, but will be better in
the long run.
I disagree, to me that this feature is all about syntactic sugar, as
such it does what it expected: it generates concrete properties and
methods that are somewhat hidden to the end-user.
I feel that any implementation that do not rely on proper
properties/methods would be a big hack.
Best,
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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.
public $_state {
set { ... }
}
This automatically generates a hidden function __set_state(), which
is a magic method already (and should be declared static, and take an
array as it's only parameter)
Another fine example of how automatically generating *real*
implementations can potentially break things.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Is there a reason why we cannot implement this using PHP's already widely used
function syntax:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
public function get() { return $this-Seconds / 3600; }
private function set($value) { $this-Seconds = $value; }
/*public implied */function isset(){ return isset ($this-Seconds); }
private function unset() { unset ($this-Seconds); }
}
}
This would be much less confusing as it follows other PHP standards for
creating functions and such. I know C# has a similar syntax to what is
proposed, but we are not developing for C# we are developing for PHP which has
its own syntax rules that differ from C#'s and my vote is to follow PHP's
already in existent syntax format.
---
-Nathan Bruer
-Original Message-
From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne 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 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 Document:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
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 {
unsethttp://www.php.net/unset($this-Seconds); }
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons
for inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code, this
greatly simplified that part of the code and future proofed it.
The code is available at the url below and is up to date with master, all
tests pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5
release, only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests
still pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any
others that I have missed, please let me know.
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.
A few examples:
## 1 - __getProperty() method directly callable
class Test {
public $property {
get { return 123; }
}
}
$test = new Test;
var_dump($test-property); // int(123)
var_dump($test-__getProperty()); // int(123)
## 2 - __getProperty() method exposed via exception
class Test {
public $throwingProperty {
get { throw new Exception; }
}
}
(new Test)-throwingProperty;
exception 'Exception' in /home/nikic/dev/php-src/t29.php:9 Stack
trace:
#0 /home/nikic/dev/php-src/t29.php(31): Test-__getthrowingProperty()
#1 {main}
## 3 - Can directly access $__automaticProperty and even unset it
(causing notices in the internal code)
class Test {
public $automaticProperty {
get; set;
}
public function getAutomaticProperty() {
return $this-__automaticProperty;
}
public function unsetAutomaticProperty() {
unset($this-__automaticProperty);
}
}
$test-automaticProperty = 'foo';
var_dump($test-getAutomaticProperty());
$test-unsetAutomaticProperty();
var_dump($test-automaticProperty);
string(3) foo
Notice: Undefined property: Test::$__automaticProperty in
/home/nikic/dev/php-src/t29.php on line 13 NULL
=
I feel like this approach to the implementation will be a big can of
worms. Sure, it works, but it is rather fragile and the enduser ends
up dealing with internal stuff which he ought not care about. I think
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 assign to
self?
How do I set the default value of $property when the object is created?
Surely I don't have to reverse the set accessors logic and set the inverse
in __construct?
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 languages. In my opinion, this is a feature that is so exotic, it's likely to never actually be used by anyone. What I dislike the most about this feature, is that it's existence may mandate a best practice of declaring read-only properties as read-only. What I mean is, because this feature exists, anytime you're declaring something that is read-only by nature (because a write-accessor makes no logical sense), you would be expected to declare such a property as read-only. In other words, not using the read-only keyword for a property that only has a read-accessor, can only be interpreted in two ways: 1. it's an oversight, or simply bad practice. 2. it's an implied invitation to implement the write-accessor in an extension. Case 1 of course shouldn't happen, while case 2 would be an extremely exotic and far-fetched scenario. I understand the justification for this keyword - but the use-cases are just too rare, and they don't, in my opinion, outweigh the disadvantages. This feature just feel clumsy and out of place to me. I will never use it, and I would strongly prefer not to have to think about it, having to declare read-only and write-only deliberately. For 95% of cases, it's going to be perfectly obvious, both to me and other consumers of the code, why or whether something is read-only or write-only, and the extra guarantee or insulation against error in the marginal 5% of cases do not justify the effort of having to declare it explicitly everywhere. Just my two cents... Subject: [PHP-DEV] [RFC] Propety Accessors v1.1 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 Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented About the items in regards to reflection in there: 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 such) The RFC also introduces a new class ReflectionPropertyAccessor and has methods returning ReflectionProperty and ReflectionPropertyAccessor. there should either be a common base class or interface (see i.e. ReflectionFunctionAbstract) What will ReflectionPropertyAccessor-getGetter()-getName() return? I guess reflection will be leaky there? (see first item) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 write only. At first glance, there is no need for the
read-only or write-only keyword. Except... subclassing may or may not be an
issue.
By setting a property to read-only, it ensures that 'set' can never be set
by a subclass. Unless I redefine the entire property... or is that not even
possible? *The RFC isn't very clear but it appears that there is no way to
redefine the entire property, as if you define it in the subclass with only
get, then it will take set, isset, and unset from the parent class, correct?
* Though, that can be outright stopped by making the property final. But
then there is no point in having read/write-only.
From what I can tell, read-only becomes useful if I extend the class and
want to partially modify the property.
Example:
class A {
public $seconds = 3600;
public $hours {
get() { return $this-seconds / 3600 };
}
}
class B extends A {
public $hours { // Maintains 'get' from class A
set($value) { $this-seconds = $value; }
}
}
^There's no way to stop the developer from doing that without read-only.
Also, if the property is public, what if an outside class tries to do this:
class A {
public $seconds = 3600;
public $hours {
get() { return $this-seconds / 3600 };
}
}
$object = new A();
$object-hours = 100;
What happens then?
And similarly, how do we set a public property as a property accessor, hmm?
class A {
public $hours = 1;
}
$seconds = 20;
$object = new A();
$object-hours = { // Does this work?
get() { return $seconds; }
};
There's definitely still some questions to answer before this RFC is ready.
On Tue, Oct 9, 2012 at 10:19 AM, Leigh lei...@gmail.com wrote:
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 assign to
self?
How do I set the default value of $property when the object is created?
Surely I don't have to reverse the set accessors logic and set the inverse
in __construct?
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 it would help with getting. All
that being said, type hinting aside, the syntax I proposed is, in my
opinion, the most consistent out of any other proposal thus far (arguably
aside from yours, I'll go over that momentarily).
Excellent point. Return type-hints only affect the getter, and even then
it could be a moot point if the property itself could be bound to a
particular type. It would actually be a much cleaner solution, and
wouldn't require any superfluous parens in the declaration:
class MyClass{
public SomeClass $property {
get {...}
set {...}
}
}
$foo = new MyClass;
$bar = new SomeClass;
$foo-property = $bar; //ok
$foo-property = new StdClass; //type mismatch
Heck, half the time setters and getters are implemented specifically for
this purpose. If the property itself could be typed, then 90% of the
time we wouldn't even need to specify get/set. Just give the property a
type and be done with it.
That said, it wouldn't help for scalar values, and that leads to a
problem with the current syntax (AFAICS). You can't specify the initial
value for a property:
eg:
class MyClass{
public $property = 5//?can we do this?
{
set($value){
if(!is_int($value)){
throw new InvalidArgumentException('value of wrong type');
}
$this-__property = $value;
}
}
}
Or would that have to happen in the constructor?
class MyClass{
public $property
{
set($value){
if(!is_int($value)){
throw new InvalidArgumentException('value of wrong type');
}
$this-__property = $value;
}
}
public function __construct(){
$this-property = 5;
}
}
Cheers,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 fix/correct/change.
I'll try to address everyone's comments/questions in one post:
Nikita:
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.
A few examples:
## 1 - __getProperty() method directly callable
class Test {
public $property {
get { return 123; }
}
}
$test = new Test;
var_dump($test-property); // int(123)
var_dump($test-__getProperty()); // int(123)
I don't particularly see this as a problem (the ability to use it as a getter
or call it as a function), but see my comments at the end. I also don't
particularly see the point of auto implemented getters/setters ( public $h {
get; set; } )
## 2 - __getProperty() method exposed via exception
class Test {
public $throwingProperty {
get { throw new Exception; }
}
}
(new Test)-throwingProperty;
exception 'Exception' in /home/nikic/dev/php-src/t29.php:9 Stack trace:
#0 /home/nikic/dev/php-src/t29.php(31): Test-__getthrowingProperty()
#1 {main}
I have gone to great lengths to shield the implementation details from users,
this one slipped past me. Nearly all errors that are shown reference a
property rather than a function name and this could also be cleaned up.
## 3 - Can directly access $__automaticProperty and even unset it (causing
notices in the internal code)
class Test {
public $automaticProperty {
get; set;
}
public function getAutomaticProperty() {
return $this-__automaticProperty;
}
public function unsetAutomaticProperty() {
unset($this-__automaticProperty);
}
}
$test-automaticProperty = 'foo';
var_dump($test-getAutomaticProperty());
$test-unsetAutomaticProperty();
var_dump($test-automaticProperty);
string(3) foo
Notice: Undefined property: Test::$__automaticProperty in
/home/nikic/dev/php-src/t29.php on line 13 NULL
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 would
eliminate this as an issue.
=
I feel like this approach to the implementation will be a big can of worms.
Sure, it works, but it is rather fragile and the enduser ends up dealing with
internal stuff which he ought not care about. I think it would be better to
cleanly separate out the accessor implementation. It might require more code
now, but will be better in the long run.
All three of these issues, could be addressed I believe by not having the
functions and/or properties a part of the ordinary HashTables, or to have flags
set on them. I believe there is already a SHADOW flag type defined which may
be able to be used for this type of functionality.
Leigh:
Further to this, take the following example.
public $_state {
set { ... }
}
This automatically generates a hidden function __set_state(), which is a
magic method already (and should be declared static, and take an array as
it's only parameter)
Another fine example of how automatically generating *real* implementations
can potentially break things.
This would clearly cause problems, again this could possibly be addressed by
not having the accessor functions be a part of the standard Functions
HashTable, the functions would not even need to have names at that point if
they are not intended to be accessible directly.
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 assign to self?
How do I set the default value of $property when the object is created?
Surely I don't have to reverse the set accessors logic and set the inverse in
__construct?
Generally speaking, I don't know why you would use an automatic backing getter
with a separate setter, but if you wanted to do that, at present you would
access the automatic backing field by $this-__property.
The above will not cause recursion, it is protected from recursion by the same
mechanism that __get() and __set() are protected. In fact, the above code
would set an actual property named $property on the object which would then
side-step the accessor entirely (true properties take precedence over
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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
Cycles Direct Getter
__get
v1.4 @ 10/8/20121m .04sn/a
.21s
Performance of property accessors was important to me as I'm sure it will be to
many, on one million cycles of a simple getter, it's .01s difference.
Depending on the run it is sometimes exactly the same performance.
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Monday, October 08, 2012 6:53 AM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC] Propety Accessors v1.1
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 Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
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 {
unsethttp://www.php.net/unset($this-Seconds); }
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons for
inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code, this
greatly simplified that part of the code and future proofed
it.
The code is available at the url below and is up to date with master, all
tests pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5
release, only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests
still pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any
others that I have missed, please let me know.
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 think this would be a valuable addition to PHP 5.5.
Cheers,
Paul.
On Mon, Oct 8, 2012 at 1:42 PM, Clint Priest cpri...@zerocue.com wrote:
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
Cycles Direct
Getter __get
v1.4 @ 10/8/20121m .04sn/a
.21s
Performance of property accessors was important to me as I'm sure it will be
to many, on one million cycles of a simple getter, it's .01s difference.
Depending on the run it is sometimes exactly the same performance.
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Monday, October 08, 2012 6:53 AM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC] Propety Accessors v1.1
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 Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
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 {
unsethttp://www.php.net/unset($this-Seconds); }
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons
for inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code, this
greatly simplified that part of the code and future proofed
it.
The code is available at the url below and is up to date with master, all
tests pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5
release, only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests
still pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any
others that I have missed, please let me know.
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 ensure that a private
attribute can be read but not modified (or modified only as we want to).
Your RFC is pretty powerful in some use cases. Like your example, which is
a virtual attribute, created from some processing. But create a new
read-only keyword is not a good idea for me: introduce a new keyword
should be avoided when it's not absolutely necessary, and it lacks meaning
(exact visibility information).
Correct me if I'm wrong, but your syntax is similar to the one used in C#.
Not a bad idea, but I think we can imagine for PHP somethink a little more
concise for the general usage.
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 reading, private writing
protected:const $bbb; // protected reading, no writing
With your RFC it will be:
public $foo { get; protected set; }
public $bar { get; private set; }
protected $aaa { get; private set; }
protected read-only $bbb;
When I did my proposal on the internals mailing-list, I got some pretty bad
feedbacks, and some very good ones.
So, maybe we can try to merge some ideas?
My patch: http://github.com/Amaury/php-src
Regards,
Amaury
2012/10/8 Clint Priest cpri...@zerocue.com
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 Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
issethttp://www.php.net/isset { return isset
http://www.php.net/isset($this-Seconds); }
unsethttp://www.php.net/unset {
unsethttp://www.php.net/unset($this-Seconds);
}
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons
for inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code,
this greatly simplified that part of the code and future proofed it.
The code is available at the url below and is up to date with master, all
tests pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5
release, only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests
still pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any
others that I have missed, please let me know.
-Clint
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 {
unsethttp://www.php.net/unset($this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And except for
superglobals I guess there is no such thing in PHP, so it looks bit
puzzling to me. I'd suggest on of the following:
- variable for value has the same name as property
public $Hours {
set { $this-Seconds = $Hours * 3600; }
}
- magic constant
public $Hours {
set { $this-Seconds = __VALUE__ * 3600; }
}
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
- or at least have it in same format as superglobals
public $Hours {
set { $this-Seconds = $_VALUE * 3600; }
}
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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); }
unsethttp://www.php.net/unset {
unsethttp://www.php.net/unset($this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And except
for superglobals I guess there is no such thing in PHP, so it looks
bit puzzling to me. I'd suggest on of the following:
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
This seems like the cleanest method, in my opinion. Javascript does this
for object prototypes:
http://ejohn.org/blog/javascript-getters-and-setters/
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 { $this-Seconds = $value; }
issethttp://www.php.net/isset** { return isset
http://www.php.net/isset**($this-Seconds); }
unsethttp://www.php.net/unset** { unset
http://www.php.net/unset**($this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And except for
superglobals I guess there is no such thing in PHP, so it looks bit
puzzling to me. I'd suggest on of the following:
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
This seems like the cleanest method, in my opinion. Javascript does this
for object prototypes:
http://ejohn.org/blog/**javascript-getters-and-**setters/http://ejohn.org/blog/javascript-getters-and-setters/
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
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 and
the original author thought to keep it the same as another well-known language
(why re-invent new syntax for no reason).
That being said, javascript does indeed allow it, my concern then would be
would we have the parameterized syntax only for set() and not get, isset or
unset?
If we do have them for all of them, it's a lot of extra characters with no real
need.
I definitely favor set($value) over a magic $Hours for the $Hours property, but
I personally see no problem with the $value, it's not magic it's a locally
defined variable.
Internally, this:
public $Hours {
get { ... }
set { ... }
}
Is implemented as standard functions, while they are hidden through reflection,
these functions exist (as a result of the above example):
public __getHours() { ... }
public __setHours($value) { ... }
Lastly, with regards to JavaScript style getters/setters, I don't think I've
ever cared what the variable name was, I typically just do something like:
set blah(x) { ... } -- x is fairly irrelevant and similarly the use 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.
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:26 PM, Benjamin Eberlei kont...@beberlei.dewrote:
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 { $this-Seconds = $value; }
issethttp://www.php.net/isset** { return isset
http://www.php.net/isset**($this-Seconds); }
unsethttp://www.php.net/unset** { unset
http://www.php.net/unset**($this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And except
for superglobals I guess there is no such thing in PHP, so it looks
bit puzzling to me. I'd suggest on of the following:
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
This seems like the cleanest method, in my opinion. Javascript
does
this
for object prototypes:
http://ejohn.org/blog/**javascript-getters-and-**setters/
http://ejohn.org/blog/javascript-getters-and-setters/
What do you think?
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
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 and
the original author thought to keep it the same as another well-known language
(why re-invent new syntax for no reason).
Well, in C# 'value' is a contextual keyword not a variable. Same as :
get, set, yield. So I'd argue, copying the syntax of well-known language
is not the case here.
That being said, javascript does indeed allow it, my concern then would be
would we have the parameterized syntax only for set() and not get, isset or
unset?
If we do have them for all of them, it's a lot of extra characters with no real
need.
I definitely favor set($value) over a magic $Hours for the $Hours property, but
I personally see no problem with the $value, it's not magic it's a locally
defined variable.
Internally, this:
public $Hours {
get { ... }
set { ... }
}
Is implemented as standard functions, while they are hidden through reflection,
these functions exist (as a result of the above example):
public __getHours() { ... }
public __setHours($value) { ... }
Didn't fully graps the internals yet, not that sharp in C, sorry. Is
there a possibility of collision with user-defined __getHours() method?
Lastly, with regards to JavaScript style getters/setters, I don't think I've
ever cared what the variable name was, I typically just do something like:
set blah(x) { ... } -- x is fairly irrelevant and similarly the use of $value
is fairly irrelevant. Thoughts?
I kinda share your concern for having parameterized syntax for set()
only. One way out of this could be introducing new keyword complimentary
to 'return' to define by what name value will be presented in local
scope. Possible names whould be: keep, accept or value
public $Hours {
get {
return $this-seconds / 3600;
}
set {
// present value as $hours in local scope
keep $hours;
$this-seconds = $hours * 3600;
}
}
I find people's need for typehinting plausible though
Thanks
Denis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
Even if $value internally makes sense due to something along the lines of *
__setHours($value)* {} being equal to *set {}*, I think using $value
without it ever being defined in the developer's code is not at all a good
idea.
If I see $value in the code, I'll logically look for where it was defined,
and when I don't see it anywhere else in the code, things are going to very
quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a note in
the documentation. That's not enough.
A similar alternative to using $value that I'd argue would be much more
sensible would be to, as Denis mentioned, use either a magic constant or a
superglobal.
As I mentioned previously, I would rather go with the set($value) {} syntax.
Now, back to the part where I agree with you - the inconsistency wherein
set has () that denote it is a method but get, isset, and unset do not. I
see this inconsistency as something problematic enough to warrant a
solution.
We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}
Yes, we now have a little bit more meat on the syntax, but in this case, I
don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which they are!
If anything, adding parenthesis to all of them makes the implementation *
more* sensible.
2) It's *only* two more characters per function. On top of that, in my
opinion, this syntax is not ugly. In fact, as I just mentioned - this
implementation is arguably *more* consistent with the rest of PHP.
On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest cpri...@zerocue.com wrote:
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
and the original author thought to keep it the same as another well-known
language (why re-invent new syntax for no reason).
That being said, javascript does indeed allow it, my concern then would be
would we have the parameterized syntax only for set() and not get, isset or
unset?
If we do have them for all of them, it's a lot of extra characters with no
real need.
I definitely favor set($value) over a magic $Hours for the $Hours
property, but I personally see no problem with the $value, it's not magic
it's a locally defined variable.
Internally, this:
public $Hours {
get { ... }
set { ... }
}
Is implemented as standard functions, while they are hidden through
reflection, these functions exist (as a result of the above example):
public __getHours() { ... }
public __setHours($value) { ... }
Lastly, with regards to JavaScript style getters/setters, I don't think
I've ever cared what the variable name was, I typically just do something
like:
set blah(x) { ... } -- x is fairly irrelevant and similarly the use 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.
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:26 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
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 { $this-Seconds = $value; }
issethttp://www.php.net/isset** { return isset
http://www.php.net/isset**($this-Seconds); }
unsethttp://www.php.net/unset** { unset
http://www.php.net/unset**($this-Seconds); }
}
Hi Clint,
I've noticed some magic variable '$value' is introduced. And except
for superglobals I guess there is no such thing in PHP, so it looks
bit puzzling to me. I'd suggest on of the following:
- setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
public $Hours {
set (DateTime $dateTime) { $this-Seconds =
$dateTime-getTimestamp(); }
}
This seems like the cleanest method, in my opinion. Javascript
does
this
for object prototypes:
http://ejohn.org/blog/**javascript-getters
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Great arguments for, anyone against this being the new way? If not then I’ll
begin work on this change as well. I would like to keep this discussion going
so that at the end of this two week discussion period I can submit it for
voting.
Jazzer, your points make a lot of sense in terms of making it clear that they
are all functions, I’m all game. If it’s not difficult I may just make it
compatible in both ways (auto-define $value) if parenthesized option is not
specified. Flexibility is at the heart of php.
-Clint
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: Monday, 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 $value.
Even if $value internally makes sense due to something along the lines of
__setHours($value) {} being equal to set {}, I think using $value without it
ever being defined in the developer's code is not at all a good idea.
If I see $value in the code, I'll logically look for where it was defined, and
when I don't see it anywhere else in the code, things are going to very quickly
get confusing.
Our best option to combat this confusion is, in my eyes, putting a note in the
documentation. That's not enough.
A similar alternative to using $value that I'd argue would be much more
sensible would be to, as Denis mentioned, use either a magic constant or a
superglobal.
As I mentioned previously, I would rather go with the set($value) {} syntax.
Now, back to the part where I agree with you - the inconsistency wherein set
has () that denote it is a method but get, isset, and unset do not. I see this
inconsistency as something problematic enough to warrant a solution.
We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}
Yes, we now have a little bit more meat on the syntax, but in this case, I
don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which they are! If
anything, adding parenthesis to all of them makes the implementation more
sensible.
2) It's only two more characters per function. On top of that, in my opinion,
this syntax is not ugly. In fact, as I just mentioned - this implementation
is arguably more consistent with the rest of PHP.
On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest
cpri...@zerocue.commailto:cpri...@zerocue.com wrote:
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 and
the original author thought to keep it the same as another well-known language
(why re-invent new syntax for no reason).
That being said, javascript does indeed allow it, my concern then would be
would we have the parameterized syntax only for set() and not get, isset or
unset?
If we do have them for all of them, it's a lot of extra characters with no real
need.
I definitely favor set($value) over a magic $Hours for the $Hours property, but
I personally see no problem with the $value, it's not magic it's a locally
defined variable.
Internally, this:
public $Hours {
get { ... }
set { ... }
}
Is implemented as standard functions, while they are hidden through reflection,
these functions exist (as a result of the above example):
public __getHours() { ... }
public __setHours($value) { ... }
Lastly, with regards to JavaScript style getters/setters, I don't think I've
ever cared what the variable name was, I typically just do something like:
set blah(x) { ... } -- x is fairly irrelevant and similarly the use of $value
is fairly irrelevant. Thoughts?
-Original Message-
From: Jazzer Dane
[mailto:tbprogram...@gmail.commailto:tbprogram...@gmail.com]
Sent: Monday, October 08, 2012 5:32 PM
To: Benjamin Eberlei
Cc: Aaron Holmes; internals@lists.php.netmailto: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:26 PM, Benjamin Eberlei
kont...@beberlei.demailto:kont...@beberlei.dewrote:
The set() one is really nice with the typehints.
On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes
aa...@aaronholmes.netmailto: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 { $this-Seconds = $value; }
issethttp://www.php.net/isset** { return
