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.
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/
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
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:
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
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
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:
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.
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
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,
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,
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
27 matches
Mail list logo
