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

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 ne

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

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 acces

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 h

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

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 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

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

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote

On 3 January 2013 17:41, Clint Priest 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 Runt

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

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

[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 follow

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

Re: [PHP-DEV] strtr vs. str_replace runtime

Hi! On 3 January 2013 11:40, Gustavo Lopes 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 expect

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; $t

Re: [PHP-DEV] [RFC] zend_parse_parameters() improvements

On Wed, Jan 2, 2013 at 3:29 PM, Gustavo Lopes wrote: > 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'**. >>

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 : > 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 > > Ca

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 : > > > Gustavo Lopes wrote: >> I've written an RFC. It's available on: >> >> > > The patch is mssing an update to README.PARAMETER_PARSING and if you ant to

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 a

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 t

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

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