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

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

On Jan 2, 2013, at 10:24 PM, Clint Priest 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 depend

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 attempt

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 ment

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

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 exp

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

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

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.

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

On Wed, Jan 2, 2013 at 10:41 AM, Steve Clay 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 e

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 th

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 bo

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

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 metho

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 dis

Re: [PHP-DEV] CURL file posting

On Wed, Jan 2, 2013 at 4:39 PM, Johannes Schlüter wrote: > > > Stas Malyshev 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("

Re: [PHP-DEV] CURL file posting

On Wed, Jan 2, 2013 at 8:39 AM, Johannes Schlüter wrote: > Stas Malyshev 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", "p

[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

Re: [PHP-DEV] release frequency?

On 02.01.2013, at 16:33, Johannes Schlüter wrote: > > > Alexey Zakhlestin 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". Segfaul

Re: [PHP-DEV] CURL file posting

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

Re: [PHP-DEV] release frequency?

Alexey Zakhlestin 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 thin

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

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 truly export zend_parse_parameter() please mark it as ZENDAPI so it's available from shared extensions and such.

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

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

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

Re: [PHP-DEV] release frequency?

On 02.01.2013, at 7:26, Stas Malyshev 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?