Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
That has not been covered and it is a problem, just tested it.
Anyone have any preferences on a resolution?
Only thing that really needs to occur is that the function names need to
be unique, we could prefix any capitals in a variable name with an
additional _ such that:
class A {
public $Foo { get; set; }
public $foo { get; set; }
}
Would mean there would be these function names:
A::__get_Foo();
A::__set_Foo();
A::__getfoo();
A::__setfoo();
Along w/ their unset/isset'rs.
This is what happens as of right now:
Fatal error: Cannot redeclare a::__getfoo() in
/opt/php-core/git/trunk-accessor/cpriest/php/quick2.php on line 9
Good catch on that one.
On 1/2/2013 11:52 PM, Steve Clay wrote:
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
--
-Clint
Re: [PHP-DEV] strtr vs. str_replace runtime
Em 2013-01-02 16:53, Nicolai Scheer escreveu: 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... Please open a bug to track this. The algorithm behaves very poorly in this case because at each position of the text, all the substrings starting there and with size between m and n (where m is the size of the smallest pattern and n is the largest) are checked, even if there are only two patterns with size m and n. We could fix this easily by building a set of the pattern sizes found and try only with those. The hashing of the substrings could also be improved; we don't have to recalculate everything when we advance in the text. -- Gustavo Lopes -- 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/3/2013 12:48 AM, Stas Malyshev wrote:
Hi!
Within get: $this-Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this-Hours = 1 can write to the underlying property but a
read of the property would go 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).
This recursion is protected in the same way that the code above would be
protected using __get/__set in that the first set::$date locks the
setter, so technically in this case the 2nd call to $this-date = new
DateTime(...); would directly access the underlying date property.
I don't like this personally (because now the $timestamp setter is
directly accessing the underlying $date variable) but this is precisely
what would happen if this same code were implemented with __get() and
__set().
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.
Again this is creating recursion and the same rules that apply to
__get()/__set() apply here, your fwrite() access of
UserContext::$username when called through the getter for $username is
already locked and thus the fwrite() line directly accesses the
underlying property.
Same as before, this is exactly the same behavior you would get with
__get() and __set(). These guard mechanisms were put in place with a
revision to __get()/__set() shortly after they were first released
(first release didn't allow recursion at all).
We could possibly also catch this scenario and either show a warning on
the fwrite() direct access or a fatal error or just allow the direct
access. Since __get() and __set() already work this way, it's probably
fine as-is, even if not perfect OO.
Anyone know what would happen in such a case with another language that
supports accessors? My guess would be infinite recursion... (no guards)...
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?
In the changing over to accessors being distinct from properties into
properties with accessors I had considered this and think it would be
great. Unless I had some trouble with the lexer it should be trivial to
add, would be something like this:
class Foo {
public $bar = 2 {
get;
set;
}
}
Anyone object to this addition to the spec?
--
-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
Just getting back to you on #1 and #2...
#1: It seems the majority want to have these internally created accessor
functions visible, which they presently are through get_class_methods,
etc. They are currently hidden by Reflection. I favor the latter, as is
implemented in Reflection since an accessor is like a method but is
not quite a method. At any rate, unless anyone voices support for
accessors being hidden from the non-reflection methods, then the current
Reflection changes regarding filtering them from getMethods() will go away.
One alternative here is that I could add a parameter to getMethods()
which would either filter or not filter accessors, which would let
whomever work the way they want to. Defaulting to... which way?
#2:
class a {
public $Foo {
get {
echo Getting \$Foo, __FUNCTION__ = .__FUNCTION__.,
__METHOD__ = .__METHOD__.PHP_EOL;
return 5;
}
}
}
$o= new a();
echo $o-Foo;
Outputs:
Getting $Foo, __FUNCTION__ = __getFoo, __METHOD__ = a::__getFoo
5
I will add to the RFC that __FUNCTION__ and __METHOD__ work as expected.
On 1/2/2013 3:08 PM, Clint Priest wrote:
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
Re: [PHP-DEV] [RFC] zend_parse_parameters() improvements
The is_null feature is really helpful. Thanks! Am 02.01.2013 um 16:26 schrieb Johannes Schlüter johan...@schlueters.de: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #23815: Added extra ImageCopyMergeAlpha function
No objection from my POV. Going to merge it in around a week, if no one objects. Am 02.01.2013 um 10:35 schrieb matt clegg cleggm...@gmail.com: 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] zend_parse_parameters() improvements
On Wed, Jan 2, 2013 at 3:29 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: 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_**improvhttps://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 could you please also update README.PARAMETER_PARSING_API in your branch to match the updated behavior? thanks! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t; $this-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
I think infinite recursion is a potential issue for lots of logging setups (let's log
when someone calls the logger!) and situations where you have multiple values to keep in
sync. The accessor implementation shouldn't try to solve these design problems.
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.
Again, the problem is not shadowing (not even in use here) but really general information
hiding. You can create these problems anytime you have hidden information and
interdependent objects, and it's an API design problem.
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] strtr vs. str_replace runtime
Hi! On 3 January 2013 11:40, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Em 2013-01-02 16:53, Nicolai Scheer escreveu: 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... Please open a bug to track this. The algorithm behaves very poorly in this case because at each position of the text, all the substrings starting there and with size between m and n (where m is the size of the smallest pattern and n is the largest) are checked, even if there are only two patterns with size m and n. We could fix this easily by building a set of the pattern sizes found and try only with those. The hashing of the substrings could also be improved; we don't have to recalculate everything when we advance in the text. Ok, here it goes: https://bugs.php.net/bug.php?id=63893 Greetings, Nico
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value; }
}
}
Here, initializing the shadow property is useless. It's similar to the case where you want
to have the initial value of a traditional property be the result of an expression (and
you can't because it would create a chicken-egg problem during construction).
Option 1: The most powerful solution I see is to have an init function that's implicitly
called before first access (and with direct write access to the shadow property if
needed). Consider trying to emulate the crazy document.cookie API:
class Document {
private $cookieProps;
public $cookie {
get { return /* based on cookieProps */; }
set { /* set some cookieProps */ }
// called implicitly before the first access (not before the
constructor runs)
// and would have direct access to the shadow property.
init { /* set up cookieProps */ }
}
}
Pros: can run any code necessary to initialize the property
Cons: must make a function just to have a default
Option 2: Keep the traditional syntax, but instead of always setting the shadow property,
call the setter with the given initial value directly before the first access.
Pros: familiar syntax; more expected behavior in some cases
Cons: what if there's no setter?; cannot run arbitrary setup code; setter can't
distinguish between a user set and the implicitly set before first access.
Option 3: A mix of both. The shadow property is always initialized with the value from the
traditional syntax. If needed, you can have an init that's called before first access.
Pros: For simple shadowed properties, just works as you'd expect and with familiar syntax;
Still allows robust initialization before first access if needed.
Cons: Author must remember that traditional syntax only useful for shadow prop.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zip stream looping issue
Before I look into this further, can someone confirm that fopen on a zip
stream should return something other than a null?
I've a zip called test.zip which contains 5 files,
a.txt,b.txt,c.txt,d.txt and yes, e.txt
The zip is valid and can be unzipped using unzip on linux.
Running the following code returns a null for each of the pointers reads
the first and 2nd files and finally loops somewhere in the fgets code at
100% cpu at the end of b.txt:-
$names=array('a.txt',
'b.txt',
'c.txt',
'd.txt',
'e.txt');
foreach($names as $name)
{
$fp=fopen('zip:///tmp/test.zip#'.$name,'r');
echo $name.':'.var_export($fp).\n;
while(!feof($fp))
{
$r=fgets($fp);
echo '.';
};
fclose($fp);
};
The information contained in this email is intended for the personal and
confidential use
of the addressee only. It may also be privileged information. If you are not
the intended
recipient then you are hereby notified that you have received this document in
error and
that any review, distribution or copying of this document is strictly
prohibited. If you have
received this communication in error, please notify Brendata immediately on:
+44 (0)1268 466100, or email 'techni...@brendata.co.uk'
Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK
Registered Office as above. Registered in England No. 2764339
See our current vacancies at www.brendata.co.uk
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/2013 8:21 AM, Steve Clay wrote:
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t; $this-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
I think infinite recursion is a potential issue for lots of logging
setups (let's log when someone calls the logger!) and situations
where you have multiple values to keep in sync. The accessor
implementation shouldn't try to solve these design problems.
__get()/__set() already implement infinite recursion guards, Accessors
are just doing the same thing.
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.
Again, the problem is not shadowing (not even in use here) but really
general information hiding. You can create these problems anytime you
have hidden information and interdependent objects, and it's an API
design problem.
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/3/2013 9:33 AM, Steve Clay wrote:
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value; }
}
}
What would be the point of this? Why not just do this:
class Foo {
private $realbar = 2;
public $bar {
get { return $this-realbar; }
set { $this-realbar = $value; }
}
}
Here, initializing the shadow property is useless. It's similar to the
case where you want to have the initial value of a traditional
property be the result of an expression (and you can't because it
would create a chicken-egg problem during construction).
Option 1: The most powerful solution I see is to have an init function
that's implicitly called before first access (and with direct write
access to the shadow property if needed). Consider trying to emulate
the crazy document.cookie API:
class Document {
private $cookieProps;
public $cookie {
get { return /* based on cookieProps */; }
set { /* set some cookieProps */ }
// called implicitly before the first access (not before the
constructor runs)
// and would have direct access to the shadow property.
init { /* set up cookieProps */ }
}
}
Pros: can run any code necessary to initialize the property
Cons: must make a function just to have a default
Option 2: Keep the traditional syntax, but instead of always setting
the shadow property, call the setter with the given initial value
directly before the first access.
Pros: familiar syntax; more expected behavior in some cases
Cons: what if there's no setter?; cannot run arbitrary setup code;
setter can't distinguish between a user set and the implicitly set
before first access.
Option 3: A mix of both. The shadow property is always initialized
with the value from the traditional syntax. If needed, you can have an
init that's called before first access.
Pros: For simple shadowed properties, just works as you'd expect and
with familiar syntax; Still allows robust initialization before first
access if needed.
Cons: Author must remember that traditional syntax only useful for
shadow prop.
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
Adding the ability to specify an = X value to a property with accessors
would be trivial.
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 3 January 2013 17:41, Clint Priest cpri...@zerocue.com wrote: I like the idea of an init function, but that would have to wait for a further release I think, or delay this whole project a year. We have constructors, shouldn't those be sufficient for that task? -- Regards, Mike -- PHP Internals - PHP 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/3/13 11:41 AM, Clint Priest wrote:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value; }
}
}
What would be the point of this?
I think it would be more readable for someone using the class. As a user it helps to know
the default of the property I'll actually be interacting with. In a non-trivial getter the
default may be much harder to tease out.
But yes, I agree that it's straightforward enough for the class author to set defaults as
needed, so I see no problem moving forward. The RFC should make clear that only the shadow
value is set (a setter, if present, is not used).
In the features docs I suggest finding a term for a non-traditional property, like
guarded property.
Also I think you should eliminate all shadowing language. IMO it adds more confusion
than it removes. Here's some language that may/may not be useful:
Almost all interaction with a guarded property is proxied, meaning the getter and setter
methods are used instead of direct reading/writing of the value. There are only two
exceptions:
1. Within a getter's scope, reads are not proxied: the property is read
directly.
2. Within a setter's scope, writes are not proxied; the property is written to
directly.
Accessors are free to interact with other properties which are visible to them, but access
to other guarded properties is always proxied.
Accessors are not required to use the property value, but it always exists.
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/3/13 12:42 PM, Michael Wallner wrote: On 3 January 2013 17:41, Clint Priest cpri...@zerocue.com wrote: I like the idea of an init function, but that would have to wait for a further release I think, or delay this whole project a year. We have constructors, shouldn't those be sufficient for that task? My initial view was that property inits would encourage encapsulation of property setup logic, and make sure the property was ready before access in the constructor. Basically the same reasons we allow initializing regular properties now. But now I think it would embolden authors to make overly complex properties (like document.cookie) that should really be separate objects. Lets not do that. 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
Clint, ...snip... I like the idea of an init function, but that would have to wait for a further release I think, or delay this whole project a year. Well, just speaking in general, we should not try to rush through these kinds of design decisions. They should only be done incrementally if it makes sense to do it incrementally. That really needs to be thought out. IMHO there's no problem delaying anything a year. We're in yearly releases now, so it's not like the 5.1 and 5.2 days where the next release it may get in was literally 5 or 10 years off... I'd much rather see it done right, even if later, rather than rushed in and sticking us with the implementation forever... Just pointing it out (in case it needed to be said)... Anthony
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
Hi! I think infinite recursion is a potential issue for lots of logging setups (let's log when someone calls the logger!) and situations where you have multiple values to keep in sync. The accessor implementation shouldn't try to solve these design problems. The whole problem here is that the only reason why it is a problem is because of the accessors that have hidden state in guards. If it were regular variables (and for all the API consumer knows, they are) there wouldn't be any question about if we're allowed to read $user-username or not - if it's public, of course we can read it. So the problem exists because the hidden state exists. It's not the problem of the code that uses public APIs in completely legal way, it is the problem of our implementation that we have hidden state that changes how variable access works. With __get we mostly ignored it since recursion blocker leads to the same result as if the variable did not exist - which is the case for __get anyway, kind of - so it was less explicit. With accessors it may become more painful. -- 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
Not really sure what to say about this, we can either guard against recursion or not, I see no reason *not* to guard against recursion except that it could allow unauthorized direct access when the guard is active. I guess a third option could be that if the property is attempted to be accessed while being guarded and that access is not from within the accessor, then it issues a warning (or not) and returns NULL. Thoughts? On 1/3/2013 4:43 PM, Stas Malyshev wrote: Hi! I think infinite recursion is a potential issue for lots of logging setups (let's log when someone calls the logger!) and situations where you have multiple values to keep in sync. The accessor implementation shouldn't try to solve these design problems. The whole problem here is that the only reason why it is a problem is because of the accessors that have hidden state in guards. If it were regular variables (and for all the API consumer knows, they are) there wouldn't be any question about if we're allowed to read $user-username or not - if it's public, of course we can read it. So the problem exists because the hidden state exists. It's not the problem of the code that uses public APIs in completely legal way, it is the problem of our implementation that we have hidden state that changes how variable access works. With __get we mostly ignored it since recursion blocker leads to the same result as if the variable did not exist - which is the case for __get anyway, kind of - so it was less explicit. With accessors it may become more painful. -- -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 : parent::$foo Issue
Note, there has been a show stopper of an issue with the current RFC that many minds have been talking about how to solve. The problem is with parent::$foo accessing the parent accessor. In summary, the difficulty is that this is parsed as a static property access and during compilation there is no guarantee that the parent class structure can be accessed (to confirm/deny that it's really an accessor and not a static property reference). This guarantee is not possible because you can define the parent class after the subclass. So... on to solutions that have been discussed and shot down. 1) Change the zend opcodes for static property references to identify the true state at run-time. This would be a hack to be certain and has been shot-down for that exact reason. This is also the reason that static accessors has been abandoned for this first iteration of the feature, because static properties are handled entirely differently from object based properties. 2) Rewrite the way static property references work, such that they make calls into zend_object_handler.c, which is probably something that should be done anyways as a separate RFC and project, at which point this problem would probably be trivial to solve. 3) Introduce a new opcode which could somehow solve this problem by introducing an additional step to determine whether its a parent accessor reference or a static property reference. This would also be hackish because the proper solution is #2 and beyond the scope of this RFC. A recent suggestion from Stas is to use parent-$foo (note the use of - rather than ::) Pros: - It should not have any problems being implemented - It would move this RFC to completion Cons: - It does create an inconsistency in that nowhere else (that I know of) does parent-$foo do something. It may also sound like it should work because parent::__construct() works just fine, but that works fine because it goes through a different opcode system than static accessors do. Really, other than doing something like the above, the only other way would be for a getter to access it's parent by calling the function directly, such as parent::__getFoo() but this is undesirable for a number of reasons: 1) It forces the user to access the parent property accessor in a different way than is used everywhere else 2) It forces the user to utilize an underlying implementation detail that is not guaranteed to stay the same (it may change) 3) It's certainly not as syntactically nice as parent-$foo would be. As a final alternative to this problem, we could simply not allow a parents accessor to be used, which I think is probably the worst choice of all. Thoughts? There is a github ticket discussing this issue as well here if you'd like to chime in there on some more technical conversation about this issue: https://github.com/cpriest/php-src/issues/8 If anyone can think of any other way to solve this such that parent::$foo could work, I'm all ears but I'm out of ideas on this one and I think Stas's idea is just fine. On 1/2/2013 5: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 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 Updates / Clarifications
Please note that I have updated and clarified v1.2 with some recent feedback: 1) Steve Clay suggested the term Guarded Property and dropping Shadowing. The Shadowing section has been renamed to Guarding, some of the wording was updated and the For Additional Clarity was updated with nearly identical wording Steve suggested which I think brings even greater clarity. 2) The parent::$foo issue I recently posted about was changed near the end of the Overloading Properties section, which shows the proposed parent-$Milliseconds form. Seeing it color coded in this light makes it even more appealing and apparent I feel. 3) Removal of Accessor section was added. This was brought up as a question as to what happens and I felt what should be done is what is defined there. Other possible alternatives to number 3: 3a) The public $Foo = 5 declaration would not shed it's inherited accessors, they would remain or could be re-defined (but not removed). 3b) The public $Foo = 5 declaration would not be allowed with the = 5 and it would not shed its inherited accessors as 3a For maximum flexibility, I favor the proposed solution as it provides for the most flexibility, it would allow sub-classes to re-define a guarded property as a traditional property, or keep it as a guarded property (modifying the getter, adding a setter, etc). On 1/2/2013 5: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 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
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi! A recent suggestion from Stas is to use parent-$foo (note the use of - rather than ::) I actually proposed parent-foo. parent-$foo implies the name of the variable is $foo, not foo - just as in $this-$foo. Yes, I know it does not match parent::$foo - but I can't do much about it. In any case, better not to add another inconsistency to the list of existing ones. -- 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
