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
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
On Oct 16, 2012 11:27 AM, "Stas Malyshev" 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
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
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
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! > 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
Le 12 oct. 2012 10:37, "Bernhard Schussek" 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
2012/10/12 Clint Priest
> 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
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 mailto: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<mailto:cpri...@zerocue.com>]
> Sent: Wednesday, October 10, 2012 7:36 PM
> To: internals@lists.php.net<mailto: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
You really don't want to even think about my idea? It's complementary on
some aspects, you know.
2012/10/11 Clint Priest
> 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
2012/10/11 Clint Priest
> 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
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 :
> 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
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
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 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
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 n
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On 11 October 2012 12:46, Cal 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
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 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
hi,
On Thu, Oct 11, 2012 at 2:16 PM, Sebastian Krebs 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
2012/10/11 Clint Priest
> 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.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
On Oct 11, 2012, at 4:59 AM, Clint Priest 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
> mailto: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
(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; }
isset { return
isset($this->Seconds); }
unset {
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 Thu, Oct 11, 2012 at 2:35 AM, Clint Priest 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
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
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 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
> 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
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"
mailto: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
On Oct 11, 2012 5:00 AM, "Clint Priest" 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
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
mailto: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 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
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 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 10/10/12 21:41, Jazzer Dane wrote:
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.
I think the syntax for defaults would be:
class UsingInitialValue {
private $seconds = 36000;
public $hours {
get() { return $this->seconds/3600;}
}
}
class UsingLazyLoad {
public $seconds {
get() { return $this->seconds = 36000;}
set($value) {$this->seconds = (int) $value;}
}
}
class UsingConstructor {
public $seconds {
set($value) {$this->seconds = (int) $value;}
}
public function __construct(){
$this->seconds = 36000;
}
}
I think I've got those all right...
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
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
On Wed, Oct 10, 2012 at 6:35 PM, Clint Priest 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
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
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
> To: Leigh
> Cc: Clint Priest , "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
> 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
To: Leigh
Cc: Clint Priest , "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
On Oct 8, 2012, at 10:07 PM, Denis Portnov wrote:
> 08.10.2012 15:52, Clint Priest пишет:
>> public $Hours {
>> get { return $this->Seconds / 3600; }
>> set { $this->Seconds = $value; }
>> isset { return
>> isset($this->Seconds); }
>> unset {
>> 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
> On Wed, Oct 10, 2012 at 5:51 AM, Clint Priest 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 Wed, Oct 10, 2012 at 5:51 AM, Clint Priest 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, 2012-10-10 at 11:53 +, Clint Priest wrote: > > On 10 October 2012 01:16, Johannes Schlüter 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
> >> 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.
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/10 Clint Priest :
> 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
> > 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
> On 10 October 2012 01:16, Johannes Schlüter 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 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
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 wrote:
> On 10 October 2012 08:46, Bernhard Schussek 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 08:46, Bernhard Schussek 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 04:51, Clint Priest 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
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On 10 October 2012 01:16, Johannes Schlüter 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 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
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
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 $prope
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
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 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 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
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
> 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
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 wrote:
> On Mon, Oct 8, 2012 at 1:52 PM, 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
>>
>> Example Usage:
>>
>> class TimePeriod {
>> private $Seconds = 3600;
>>
>> public $Hours {
>> get { return $this->Seconds / 3600; }
>> set { $this->Seconds = $value; }
>> isset<http://www.php.net/isset> { return
>> isset<http://www.php.net/isset>($this->Seconds); }
>> unset<http://www.php.net/unset> {
>> unset<http://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 {
>
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
Hi,
On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov wrote:
> On Mon, Oct 8, 2012 at 1:52 PM, 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
>>
>> Example Usage:
>>
>> class TimePeriod {
>> private $Seconds = 3600;
>>
>> public $Hours {
>> get { return $this->Seconds / 3600; }
>> set { $this->Seconds = $value; }
>> isset { return
>> isset($this->Seconds); }
>> unset {
>> 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
On Mon, Oct 8, 2012 at 1:52 PM, 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
>
> Example Usage:
>
> class TimePeriod {
> private $Seconds = 3600;
>
> public $Hours {
> get { return $this->Seconds / 3600; }
> set { $this->Seconds = $value; }
> isset { return
> isset($this->Seconds); }
> unset {
> 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
he 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 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 >> >wrote:
>>> >
>>> > > The set() one is really nice with the typehints.
>>> > >
>>> > > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes >> >
>>> > > wrote:
>>> > >
>>> > > > On 10/8/12 1:07 PM, Denis Portnov wrote:
>>> > > >
>>> > > >> 08.10.2012 15:52, Clint Priest пишет:
>>> > > >>
>>> > > >>> public $Hours {
>>> > > >>>
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
istency 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 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 >> >wrote:
>>> >
>>> > > The set() one is really nice with the typehints.
>>> > >
>>> > > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes >> >
>>> > > 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; }
>>> > > >>>
>>> > > >>> isset<http://www.php.net/**isset**<http://www.php.net/isset**>>
>>> { return isset<
>>> > > >>> http://www.php.net/isset**>($**this->Seconds); }
>>> > > >>>
>>> > > >>> unset<http://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
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
>wrote:
>
> > The set() one is really nice with the typehints.
> >
> > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes
> > 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; }
> > >>> isset<http://www.php.net/isset**> { return isset<
> > >>> http://www.php.net/isset**>($this->Seconds); }
> > >>> 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/>
> > >
> > >
> > >>
> > >> 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
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 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 >wrote:
> >
> > > The set() one is really nice with the typehints.
> > >
> > > On Tue, Oct 9, 2012 at 12:19 AM, Aaro
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
mailto: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<mailto:tbprogram...@gmail.com>]
> Sent: Monday, October 08, 2012 5:32 PM
> To: Benjamin Eberlei
> Cc: Aaron Holmes; internals@lists.php.net<mailto: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
> mailto:kont...@beberlei.de>>wrote:
>
> > The set() one is really nice with the typehints.
> >
> > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes
> > mailto:aa...@aaronholmes.net>>
> > wrote:
> >
> > > On 10/8/12 1:07 PM, Denis Portnov wrote:
> > &g
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 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 >wrote:
> >
> > > The set() one is really nice with the typehints.
> > >
> > > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes
> > > 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; }
> > > >>> isset<http://www.php.net/isset**> { return isset<
> > > >>> http://www.php.net/isset**>($this->Seconds); }
> > > >>> unset<http://www.php.net/unset**> { unset<
> > > >>> http://www.php.net/unset**>($this->Seconds); }
> > > >>>
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
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 wrote:
>
> > The set() one is really nice with the typehints.
> >
> > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes
> > 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; }
> > >>> isset<http://www.php.net/isset**> { return isset<
> > >>> http://www.php.net/isset**>($this->Seconds); }
> > >>> 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/>
> > >
> > >
> > >>
> > >> 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
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 wrote:
> The set() one is really nice with the typehints.
>
> On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes
> 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; }
> >>> isset { return isset<
> >>> http://www.php.net/isset**>($this->Seconds); }
> >>> 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
The set() one is really nice with the typehints.
On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes 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; }
>>> isset { return isset<
>>> http://www.php.net/isset**>($this->Seconds); }
>>> 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/
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; }
isset { return
isset($this->Seconds); }
unset {
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
08.10.2012 15:52, Clint Priest пишет:
public $Hours {
get { return $this->Seconds / 3600; }
set { $this->Seconds = $value; }
isset { return
isset($this->Seconds); }
unset {
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
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
> 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; }
> isset { return isset<
> http://www.php.net/isset>($this->Seconds); }
> unset {
> 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
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 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; }
>> isset { return
>> isset($this->Seconds); }
>> unset {
>> 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
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; }
> isset { return
> isset($this->Seconds); }
> unset {
> 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
