Re: [PHP-DEV] release frequency?
On 02.01.2013, at 7:26, Stas Malyshev smalys...@sugarcrm.com wrote: I see that we do not have a lot of changes in 5.4 since last release. So I wonder if it may make sense to reduce release frequency now that we got less bugfixes coming in, say from monthly to 1.5 or 2 months between release. What do you think? Just to be clear, I have no problem (excepting unforeseen circumstances, of course) still doing monthly, just not sure it's worth it if we'd have less than 10 bugfixes per release… if there's at least one REAL bug fix in release it's worth it -- Alexey Zakhlestin https://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #23815: Added extra ImageCopyMergeAlpha function
I have added ImageCopyMergeAlpha as an extra function to resolve bug 23815. I have created a pull request on github https://github.com/php/php-src/pull/211 Can this be merged into 5.5? And, what do I need to do? -- Matt Clegg --http://mattclegg.com/
[PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 I'm posting it for final review so I can move to voting on Jan 7th. Please note that the current fork is not quite up-to-date with the RFC but will be within a few more days. -Clint -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] zend_parse_parameters() improvements
Em 2012-07-18 23:05, Gustavo Lopes escreveu: Some deficiencies in zpp have been constrai ning the implementation of common scenarios such as 'allow integer or NULL'* or the more general 'allow different types for an argument'**. I've written an RFC. It's available on: https://wiki.php.net/rfc/zpp_improv Since there was already a discussion several months ago, I'll move on an expedited schedule and open the vote next Wednesday, provided that no new arguments are advanced. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] zend_parse_parameters() improvements
Gustavo Lopes glo...@nebm.ist.utl.pt wrote: I've written an RFC. It's available on: https://wiki.php.net/rfc/zpp_improv The patch is mssing an update to README.PARAMETER_PARSING and if you ant to truly export zend_parse_parameter() please mark it as ZENDAPI so it's available from shared extensions and such. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release frequency?
Alexey Zakhlestin indey...@gmail.com wrote: if there's at least one REAL bug fix in release it's worth it So, what is a real bugfix? Most things are responses on bug reports by users. Form them it is real. On the other hand most things we fix these days (especially when looking at 5.3) are really minor things which mostly can easily be worked-around and barely hit anybody (if bugs are reported 5 years after that code was initially released it's barely hit) As said in a recent thread for 5.3 I plan to reduce the release amount after February, I don't mind delaying the upcoming releases a bit, I haven't checked commits and bugs which came in during the holiday season, yet. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I'm thinking maybe the best solution is to have a new class - say, CurlFile - and do this: $file = new CurlFile(myface.png, image/png); curl_setopt($ch, CURLOPT_POSTFIELDS, array(foo = bar, picture = $file); What I wonder about in this thread: If we struggle here why not take the full step and abstract curl details comletely away and provide something like pecl/http by default instead? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release frequency?
On 02.01.2013, at 16:33, Johannes Schlüter johan...@schlueters.de wrote: Alexey Zakhlestin indey...@gmail.com wrote: if there's at least one REAL bug fix in release it's worth it So, what is a real bugfix? Most things are responses on bug reports by users. Form them it is real. String typos are not real. Segfault fixes and inconsistent behaviour fixes are real. -- Alexey Zakhlestin https://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] strtr vs. str_replace runtime
Hi! I stumbled upon a problem with the function strtr() the other day... I noticed a very long running php script, and tried to reproduce the behaviour. I traced it down to a single call of strtr doing text replacements using a search = replace array. It wasn't quit obvious why the call would take that long, so I started to investigate the issue. From the docs, it says that strtr ... will be the most efficient when all the keys have the same size. My testcase showed, that in fact I was using Keys of very different lengths (they are determined automatically, so there's no fixed list). I wrote a simple script to reproduce this behaviour: ?php $text = str_repeat( 'm', 2000 ); $long_from_a = str_repeat( 'a', 1 ); $long_from_x = str_repeat( 'x', 1500 ); $replacements = array( $long_from_a = 'b', $long_from_x = 'y' ); $start = microtime( true ); $result_1 = strtr( $text, $replacements ); echo strtr: . number_format( microtime( true ) - $start, 4 ) . \n; $start = microtime( true ); $result_2 = str_replace( array_keys( $replacements ), array_values( $replacements ), $text ); echo str_replace: . number_format( microtime( true ) - $start, 4 ) . \n; echo $result_1 === $result_2 ? results match!\n: no match!\n; ? On my box, this reports 2.5 seconds for strtr and 0.0 seconds for str_replace. As far as I know the only difference between str_replace and strtr is that strtr does not replace stuff in already replaced parts of the string. Might be wrong here, though. If I adjust the str_repeat for m from 2000 to 2 the runtime is 45 seconds for strtr and 0.0001 for str_replace. I might have chosen the wrong tool for what I'm trying to achieve in the first place, but can anyone comment on the algorithmic complexity of strtr? This is definitely not the expected behaviour for such small inputs. Since the inputs varied and the keys where determined automatically in my original script, I was confronted with runtimes of several hours compared to just a few seconds with str_replace. If this is the expected behaviour, at least the documentation should be adjusted to state that this function is very inefficient with keylengths that are very distant from each other... Greetings Nico
Re: [PHP-DEV] CURL file posting
On Wed, Jan 2, 2013 at 8:39 AM, Johannes Schlüter johan...@schlueters.de wrote: Stas Malyshev smalys...@sugarcrm.com wrote: I'm thinking maybe the best solution is to have a new class - say, CurlFile - and do this: $file = new CurlFile(myface.png, image/png); curl_setopt($ch, CURLOPT_POSTFIELDS, array(foo = bar, picture = $file); What I wonder about in this thread: If we struggle here why not take the full step and abstract curl details comletely away and provide something like pecl/http by default instead? Personally I've always hated using the cURL API in PHP and would love to see a solid implementation included by default, but I would guess that the general consensus would be that it could/should be done in user-land. Anyone know if Guzzle (http://guzzlephp.org/) handles this? I know it's a popular HTTP client for PHP and is included in the Amazon Web Service SDK (https://github.com/aws/aws-sdk-php). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
On Wed, Jan 2, 2013 at 4:39 PM, Johannes Schlüter johan...@schlueters.dewrote: Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I'm thinking maybe the best solution is to have a new class - say, CurlFile - and do this: $file = new CurlFile(myface.png, image/png); curl_setopt($ch, CURLOPT_POSTFIELDS, array(foo = bar, picture = $file); What I wonder about in this thread: If we struggle here why not take the full step and abstract curl details comletely away and provide something like pecl/http by default instead? johannes I think that a more compact and easier-to-use API would be nice, but only if we don't limit the current functionality. So that should either provide everything that we have currently or only add this as a separate interface, but keep the old one also. my 2 cents -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
As is customary for me, I am voicing my opinion against this proposal. I do not like the proposed syntax; it is cumbersome and unfamiliar to current PHP style. I would opt for something more in line with current method definitions. I do think that PHP needs something like this proposal, but I dislike the details of this one. I will vote no on January 7th. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/13 6:36 AM, Clint Priest wrote: Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 A few remaining questions. The RFC makes it clear that ReflectionClass::getMethods() does not return internal method names like __setSeconds. 1. Are these names visible via get_class_methods() / method_exists() / is_callable()? 2. Inside an accessor, what do __FUNCTION__ and __METHOD__ evaluate as? 3. What happens if a class/subclass contains a regular method __setSeconds? Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
Hi Stas, I think you're right using object is the safest way to do it safely. It might look strange because there are no object at all in the current extension and the procedural function will use in this specific case an object but still we have to provide a safe way to do it. I also agree with Johannes, the php/curl api is not the easiest one to use, mainly due to the number of available functionalities. pecl/http is really a nicer api, and it is easier to work with but it don't offer all the functionnalities libcurl do. Maybe Mike is planning to add all of those ? Pierrick On 2 January 2013 02:15, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I'm thinking maybe the best solution is to have a new class - say, CurlFile - and do this: $file = new CurlFile(myface.png, image/png); curl_setopt($ch, CURLOPT_POSTFIELDS, array(foo = bar, picture = $file); This would allow us to do two things: 1. Protect ourselves from injection since you can not inject objects (there's still a matter of serialized data, but this can be handled by the class itself). 2. Support much more options in the file - e.g., right now it does not support streams, but libcurl has CURLFORM_STREAM - maybe we could use it, or maybe just read in the stream data and use it as CURLFORM_BUFFER. Of course, that would not work for big files, but here we are able to use much more options than with old @-based API. Any holes in this idea? If not, I'll try to make an RFC for 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] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/13 6:36 AM, Clint Priest wrote: Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 The RFC does not specify whether it's a fatal error to define a class (directly or via extends/traits) which has both a traditional property and accessor with the same name, but I think this should be prohibited to avoid confusion. One might expect this to work if the traditional property is private in a parent class, but I think even if the patch allowed that special case (I've not tried it), it should not. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
Hi! What I wonder about in this thread: If we struggle here why not take the full step and abstract curl details comletely away and provide something like pecl/http by default instead? curl extension is widely used. So suggesting we just throw it away makes no sense to me. We need to fix this deficiency in the API, since it may break applications and expose users to hard-to-track security holes. As for developing other extensions and adding pecl/http by default, this is a valid issue but I'd rather discuss it separately. -- 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] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On Wed, Jan 2, 2013 at 10:41 AM, Steve Clay st...@mrclay.org wrote: On 1/2/13 6:36 AM, Clint Priest wrote: Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 The RFC does not specify whether it's a fatal error to define a class (directly or via extends/traits) which has both a traditional property and accessor with the same name, but I think this should be prohibited to avoid confusion. I think it is explained in the RFC: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#shadowing but the code example doesn't reflect that. Perhaps my understanding is flawed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
Also, I was under the impression that we wanted to remove the magic `$value` for the setter. It seems the RFC intentionally left it in there. Any real reason why? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
I am confused by one thing about the RFC. There is a section for default
accessor implementations where you specify an accessor without a body,
however many of the examples omit the isset and unset accessors. I would
assuming that omitting an accessor would provide the automagic
implementation. If this is the case what is the need for the special
syntax? If this is not the case then what is the effect of omitting an
accessor?
I do see that omitting the setter creates a read-only property, however I
think the syntax would be less ambiguous and easier to use by introducing a
`readonly` keyword:
class MyClass
{
public readonly $myProp {
// ...
}
}
This would also eliminate the need for additional syntax for default
accessors. There is one problem I see with this however, what happens when
a setter is provided for a readonly property?
If this has already been discussed, please accept my apologies and maybe
provide a link to the discussion.
Regards,
Philip
On Wed, Jan 2, 2013 at 6:36 AM, Clint Priest cpri...@zerocue.com wrote:
Here is the updated RFC incorporating the feedback from previous rounds of
discussion.
https://wiki.php.net/rfc/**propertynot
getsetsyntax-v1.2https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
I'm posting it for final review so I can move to voting on Jan 7th.
Please note that the current fork is not quite up-to-date with the RFC but
will be within a few more days.
-Clint
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/2013 11:08 AM, Steve Clay wrote: A few remaining questions. The RFC makes it clear that ReflectionClass::getMethods() does not return internal method names like __setSeconds. 1. Are these names visible via get_class_methods() / method_exists() / is_callable()? This is the only remaining point of contention but I would expect however it is resolved, all methods of reflection would match. 2. Inside an accessor, what do __FUNCTION__ and __METHOD__ evaluate as? I would have to test them but they are methods so they should evaluate as you would expect, I'll test. 3. What happens if a class/subclass contains a regular method __setSeconds? Same thing as a duplicate function declaration error, since that's what it is, remember that the prefix __ is reserved for php internal use, if I recall correctly userland code should not be using a double underscore. Steve Clay On 1/2/2013 11:41 AM, Steve Clay wrote: The RFC does not specify whether it's a fatal error to define a class (directly or via extends/traits) which has both a traditional property and accessor with the same name, but I think this should be prohibited to avoid confusion. One might expect this to work if the traditional property is private in a parent class, but I think even if the patch allowed that special case (I've not tried it), it should not. As of the current fork there is no difference between a property and a property with accessors except that a property with accessors will always route through the accessor methods. In other words a property_info structure is created for either type. Ergo, the same rules apply, a second declaration of a property with the same name will cause a compilation error. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/2013 12:44 PM, Philip Graham wrote:
I am confused by one thing about the RFC. There is a section for default
accessor implementations where you specify an accessor without a body,
however many of the examples omit the isset and unset accessors. I would
assuming that omitting an accessor would provide the automagic
implementation. If this is the case what is the need for the special
syntax? If this is not the case then what is the effect of omitting an
accessor?
Omitting get/set declaration (and body) makes the property read only or
write only.
Omitting isset/unset has the same effect as declaring it without a
body. This is described in the RFC under Automatic Implementations with
this line:
Note that isset/unset implementations will always be provided if they
are not defined or if they are explicitly auto-defined (as above).
I do see that omitting the setter creates a read-only property, however I
think the syntax would be less ambiguous and easier to use by introducing a
`readonly` keyword:
class MyClass
{
public readonly $myProp {
// ...
}
}
This would also eliminate the need for additional syntax for default
accessors. There is one problem I see with this however, what happens when
a setter is provided for a readonly property?
If this has already been discussed, please accept my apologies and maybe
provide a link to the discussion.
This point of contention was discussed ad nauseam and nobody wanted the
read-only/write-only keywords, they were removed from 1.1 - 1.2
Please see this document:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Which documents all points of contention from 1.1 and what their
resolution was.
Regards,
Philip
On Wed, Jan 2, 2013 at 6:36 AM, Clint Priest cpri...@zerocue.com wrote:
Here is the updated RFC incorporating the feedback from previous rounds of
discussion.
https://wiki.php.net/rfc/**propertynot
getsetsyntax-v1.2https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
I'm posting it for final review so I can move to voting on Jan 7th.
Please note that the current fork is not quite up-to-date with the RFC but
will be within a few more days.
-Clint
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/13 4:18 PM, Clint Priest wrote:
Omitting isset/unset has the same effect as declaring it without a body. This
is
described in the RFC under Automatic Implementations with this line:
Note that isset/unset implementations will always be provided if they are not
defined or
if they are explicitly auto-defined (as above).
I think the RFC could make this clearer: isset unset are always provided with the
default implementations unless the author provides his/her own.
Looking closer at the default implementations of isset/unset, I'm worried these could lead
to confusion. Consider this code:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
}
}
The RFC's default implementation is always bound to the shadow property, so here's what
you really get:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
// auto-generated
isset { return $this-Hours != NULL; }
unset { $this-Hours = NULL; }
}
}
Note the resulting behavior:
$t = new TimePeriod;
$t-Hours; // 1
isset($t-Hours); // false !?
unset($t-Hours);
$t-Hours; // still 1
Effectively, authors who don't base their getters/setters on the shadowed property must be
urged to create their own isset/unset because the default ones would be useless. I'm not
crazy about this.
I'd prefer these default implementations:
isset { return $this-__getHours() != NULL; }
unset { $this-__setHours(NULL); }
$t = new TimePeriod;
$t-Hours; // 1
isset($t-Hours); // true
unset($t-Hours);
$t-Hours; // null
isset($t-Hours); // false
Note these also work as expected when using the default get/set implementations. Of,
course, my implementations don't actually *work* because you can't call an accessor from
an accessor...
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/2013 4:18 PM, Steve Clay wrote:
On 1/2/13 4:18 PM, Clint Priest wrote:
Omitting isset/unset has the same effect as declaring it without a
body. This is
described in the RFC under Automatic Implementations with this line:
Note that isset/unset implementations will always be provided if they
are not defined or
if they are explicitly auto-defined (as above).
I think the RFC could make this clearer: isset unset are always
provided with the default implementations unless the author provides
his/her own.
I can do that, no problem.
Looking closer at the default implementations of isset/unset, I'm
worried these could lead to confusion. Consider this code:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
}
}
The RFC's default implementation is always bound to the shadow
property, so here's what you really get:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
// auto-generated
isset { return $this-Hours != NULL; }
unset { $this-Hours = NULL; }
}
}
Note the resulting behavior:
$t = new TimePeriod;
$t-Hours; // 1
isset($t-Hours); // false !?
unset($t-Hours);
$t-Hours; // still 1
Effectively, authors who don't base their getters/setters on the
shadowed property must be urged to create their own isset/unset
because the default ones would be useless. I'm not crazy about this.
Sorry, there was a typo in that RFC there, this line:
isset { return $this-Hours != NULL; }
Should have been with !==:
isset { return $this-Hours !== NULL; }
I've already updated the 1.2 doc to reflect the correct way.
Given what I mentioned above, I'm assuming you did not test this with
the fork, right? Just based your comments on how it should logically
work (with the incorrect != vs !==?)
One last thing about that, the isset/unset with $this-Hours calls the
getter to retrieve the $this-Hours value, so it behaves as your example
below indicates.
I'd prefer these default implementations:
isset { return $this-__getHours() != NULL; }
unset { $this-__setHours(NULL); }
$t = new TimePeriod;
$t-Hours; // 1
isset($t-Hours); // true
unset($t-Hours);
$t-Hours; // null
isset($t-Hours); // false
Note these also work as expected when using the default get/set
implementations. Of, course, my implementations don't actually *work*
because you can't call an accessor from an accessor...
Steve, are you testing these w/ the fork? Sounds like you are... But
your above sentence is not accurate, you can call an accessor from an
accessor. isset { return $this-Hours !== NULL; } calls the getter for
the value and compares it with NULL.
Steve Clay
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/13 6:08 PM, Clint Priest wrote:
Sorry, there was a typo in that RFC there, this line:
isset { return $this-Hours != NULL; }
Should have been with !==:
isset { return $this-Hours !== NULL; }
I've already updated the 1.2 doc to reflect the correct way.
Given what I mentioned above, I'm assuming you did not test this with the fork,
right?
Just based your comments on how it should logically work (with the incorrect !=
vs !==?)
I haven't tested the fork. I just borrowed your logic with the typo :)
One last thing about that, the isset/unset with $this-Hours calls the getter
to retrieve
the $this-Hours value, so it behaves as your example below indicates.
The RFC says, only the accessors themselves may directly access the shadowed property. I
read that as:
Within get, $this-Hours is the raw shadowed property.
Within set, $this-Hours is the raw shadowed property.
Within isset, $this-Hours is the raw shadowed property.
Within unset, $this-Hours is the raw shadowed property.
But you seem to imply:
Within get, $this-Hours is the raw shadowed property.
Within set, $this-Hours is the raw shadowed property.
Within isset, $this-Hours is accessed via __getHours()/__setHours().
Within unset, $this-Hours is accessed via __getHours()/__setHours().
So really the default implementations behave like this:
isset { return $this-__getHours() !== NULL; }
unset { $this-__setHours(NULL); }
I think the RFC should be much clearer about what property access actually means within
each accessor method, as I expect users to be very surprised by this behavior.
This is also looks like it could lead to surprises:
Within get, $this-Hours is the raw shadowed property.
Within get, parent::$Hours is accessed via
parent::__getHours()/parent::__setHours().
Also, is there no way to access the shadow property within isset/unset? If not, is there a
good reason to not allow it?
Also, do/should multiple property accessors interact? Consider:
class Foo {
public $a {
get { $this-a = 1; return 2; }
}
public $b {
get { return $this-a; }
}
}
$foo = new Foo;
$foo-a; // 2 (but shadowed property is 1)
$foo-b; // 1 or 2?
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
All great questions Steve, doesn't quite work the way you have here.
Specifically each get/set/isset/unset have their own guards (just like
__get(), __set(), __isset() and __unset()) which means that:
Within get: $this-Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this-Hours = 1 can write to the underlying property but a
read of the property would go through the getter.
Within isset/unset: the same rules apply, a read goes through the getter
and a write goes through the setter.
I've updated the Shadowing section of the RFC which I hope clears this
up, it also includes a slightly modified version of your example at the
bottom with comments.
More comments below:
On 1/2/2013 6:28 PM, Steve Clay wrote:
On 1/2/13 6:08 PM, Clint Priest wrote:
Sorry, there was a typo in that RFC there, this line:
isset { return $this-Hours != NULL; }
Should have been with !==:
isset { return $this-Hours !== NULL; }
I've already updated the 1.2 doc to reflect the correct way.
Given what I mentioned above, I'm assuming you did not test this with
the fork, right?
Just based your comments on how it should logically work (with the
incorrect != vs !==?)
I haven't tested the fork. I just borrowed your logic with the typo :)
One last thing about that, the isset/unset with $this-Hours calls
the getter to retrieve
the $this-Hours value, so it behaves as your example below indicates.
The RFC says, only the accessors themselves may directly access the
shadowed property. I read that as:
Within get, $this-Hours is the raw shadowed property.
Within set, $this-Hours is the raw shadowed property.
Within isset, $this-Hours is the raw shadowed property.
Within unset, $this-Hours is the raw shadowed property.
But you seem to imply:
Within get, $this-Hours is the raw shadowed property.
Within set, $this-Hours is the raw shadowed property.
Within isset, $this-Hours is accessed via __getHours()/__setHours().
Within unset, $this-Hours is accessed via __getHours()/__setHours().
So really the default implementations behave like this:
isset { return $this-__getHours() !== NULL; }
unset { $this-__setHours(NULL); }
Technically this is an accurate translation of what happens with the RFC
example, but this would work as well.
I think the RFC should be much clearer about what property access
actually means within each accessor method, as I expect users to be
very surprised by this behavior.
This is also looks like it could lead to surprises:
Within get, $this-Hours is the raw shadowed property.
Within get, parent::$Hours is accessed via
parent::__getHours()/parent::__setHours().
I'm not sure I understand what you mean here... within get the parent
accessor is accessed via parent::$Hours, internally that is translated
to what you have above but none of this parent::__getHours() needs to be
typed out, parent::$Hours will suffice.
Also, is there no way to access the shadow property within
isset/unset? If not, is there a good reason to not allow it?
Yes, it would bypass the getter and setter which may be dynamic and
never set the underlying property.
Also, do/should multiple property accessors interact? Consider:
class Foo {
public $a {
get { $this-a = 1; return 2; }
}
public $b {
get { return $this-a; }
}
}
$foo = new Foo;
$foo-a; // 2 (but shadowed property is 1)
$foo-b; // 1 or 2?
This would cause a Warning, unable to set property Foo::$a, no setter
defined. Both of your $foo-a and $foo-b lines would return the return
value of the Foo::$a getter which is always 2.
The reason it would produce that warning is because you do not have a
setter for $a defined and therefore it is read only, even to its-self.
Only the setter may set the underlying value.
Steve Clay
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On Jan 2, 2013, at 10:24 PM, Clint Priest cpri...@zerocue.com wrote: I've updated the Shadowing section of the RFC which I hope clears this up, it also includes a slightly modified version of your example at the bottom with comments. Updated RFC really helps. The notion of $this-prop access semantics depending on which accessor you're in seems important for the RFC as I think it will seem foreign to a lot of devs. When I make traditional PHP accessor methods, I have complete control; if I want getFoo() to set private $foo without calling setFoo(), I can. Not so with real accessors. Probably a good thing :) One more concern, sorry if it was covered already: will case-insensitivity of methods mean you can't define getters for both $foo and $Foo? Steve -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
Hi!
Within get: $this-Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this-Hours = 1 can write to the underlying property but a
read of the property would go through the getter.
Are the accesses also applying to called functions/accessors? I.e.
consider this:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t; $this-timestamp = $t; $this-date = new
DateTime(@$t); }
}
}
What happens to it? Would it get into infinite loop or will just set the
value twice? What would be the correct way to write such a code (note
the real code of course could be much more complicated and probably
involve dozen of properties with complex dependencies between them).
Also, if this applies to functions called from getter/setter (which
seems to be the case from the code, unless I miss something), consider this:
class UserContext {
protected $user;
public $logger;
public $username {
get() { $this-logger-log(Getting username); return
$user-name; }
set($n) { $this-user = User::get_by_name($n); }
}
}
class Logger {
protected $ctx;
public function __construct(UserContext $ctx) {
$this-ctx = $ctx;
$this-logfile = fopen(/tmp/log, a+);
}
public function log($message) {
fwrite($this-logfile, [$this-ctx-username] $message\n);
}
}
$u = new UserContext();
$u-logger = new Logger($u);
$u-username = johndoe;
echo $u-username;
What would happen with this code? Will the log be able to log the actual
user name, and if not, how you protect from such thing? $username is a
part of public API of UserContext, so whoever is writing Logger has
right to use it. On the other hand, whoever is using logger-log in
UserContext has absolutely no way to know that Logger is using
ctx-username internally, as these components can change completely
independently and don't know anything about each other besides public APIs.
What I am getting at here is that shadowing seems to create very tricky
hidden state that can lead to very bad error situations when using
public APIs without knowledge of internal implementation.
Within isset/unset: the same rules apply, a read goes through the getter
and a write goes through the setter.
With this code:
class Foo {
public $bar {
get;
set;
}
}
How could I make it set to 2 by default and isset() return true when I
instantiate the class? Currently, I see no way to assign default values
for properties. Is it planned?
--
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
