Levi,
>From what I understood it is a consensus to apply the change to PHP 5.6 as
it is (new flag and disabled by default). There is no consensus about how
should be in PHP 7, but was agreed to discuss that later.
On Fri, Nov 28, 2014 at 11:39 PM, Levi Morrison wrote:
> On Fri, Nov 28, 2014 at
On Fri, Nov 28, 2014 at 1:21 PM, Juan Basso wrote:
> Over 20 days since the last comment and seems there is a consensus about
> accept it to the next 5.6 patch version, right? Can it be merged?
After reading over the thread, there doesn't seem to be a consensus; I
am not sure how you arrived at t
> On 22 Sep 2014, at 23:42, Andrea Faulds wrote:
>
> Good evening again,
>
> Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow
>
> Thoughts appreciated, as is help with the patch, though I can probably manage
> on my own.
>
> Thanks!
At long last, we are at the point where I h
On 28/11/2014 01:13, Bostjan Skufca wrote:
A function called spl_object_hash() exists,
but it returns identical hashes for equal objects.
In case it's been lost in the noise, no it doesn't.
From http://php.net/spl_object_hash
> Return Values
> A string that is unique for each currently exist
On 28/11/2014 21:06, Marc Bennewitz wrote:
But to have a unique ID for objects sound like a very good idea and
would solve the object as array key issue.
I'm sure it's not as simple as the function prototype explained in
this thread previously.
Indeed. Fortunately, we already have one: it's c
Hi!
> this is a long spoken topic which is now embodied in
> https://wiki.php.net/rfc/native-tls . A preliminary implementation is
> there as well, thus we can discuss it.
This sounds great! \o/
I understand there's no practical performance impact? If so, code
simplification looks like a real win
Hi!
> I should be able to run some scratch build next week
That'd be great. I thought about merging them but since I don't have any
ppc64 hardware around I was not sure, but if you have some it'd be great.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing
Hi!
> Sorry, I missed this thread back when you posted.
> Personally I'm a bit hesitant about this change.
> Do we already have something additional/upcoming features which could be
> a good fit to lump together with allowed_classes?
There was talk about limiting depth or breadth to prevent hash
Hi!
> It confuses programmers that came from other languages, prevent APIs from
> having meaningful names on static methods and have no other benefit than
> supporting PHP 4 code.
I think this notion of "confuses programmers" sometimes goes too far,
and this is one of the examples. PHP prides its
>
> -- Forwarded message --
> From: Carlos Rodrigues
> To: internals@lists.php.net
> Cc:
> Date: Fri, 28 Nov 2014 17:29:37 -0200
> Subject: Static functions Vs Nonstatic functions
> PHP has evolved a lot in recent years but we still can't have a static and
> a nonstatic function wi
Am 28.11.2014 um 21:21 schrieb Levi Morrison:
Won't `$obj1 === $obj2` work for you ?
This works if you have two objects which are easily accessible in the same
scope.
Not that it can not be done this way, but it may require jumping through
hoops to get two object references into the common
2014.11.28. 9:24 ezt írta ("Dmitry Stogov" ):
>
> On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui wrote:
>
> > Hey:
> >
> > On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov wrote:
> > > Hi,
> > >
> > > I'm working on call/return sequence optimization. As part of this work
> > I'm
> > > minimizing the
Please read :
http://grokbase.com/t/php/php-internals/14acs23cpe/disallow-non-static-method-calls-with-self-static-in-php-7#20141026ct1np9k82bte2m9k9rtmq1c2jr
Am 28.11.2014 um 20:29 schrieb Carlos Rodrigues:
PHP has evolved a lot in recent years but we still can't have a static and
a nonstati
Over 20 days since the last comment and seems there is a consensus about
accept it to the next 5.6 patch version, right? Can it be merged?
Juan Basso
On Wed, Nov 5, 2014 at 9:37 PM, Juan Basso wrote:
> After the comments I see about deprecating the constant. Makes completely
> sense to keep it.
>> Won't `$obj1 === $obj2` work for you ?
>>
>
> This works if you have two objects which are easily accessible in the same
> scope.
>
> Not that it can not be done this way, but it may require jumping through
> hoops to get two object references into the common scope where you can
> compare them
> Please review the patch https://gist.github.com/dstogov/47a39aff37f0a6441ea0
Instead of duplicating logic in two places I'd rather grab the
relevant data first, then do the logic once:
zend_string *class_name;
if (fe->type == ZEND_INTERNAL_FUNCTION) {
class_name = zend_string_init(
Am 28.11.2014 20:23 schrieb "Bostjan Skufca" :
>
> On 28 November 2014 at 04:10, reeze wrote:
>
> > Won't `$obj1 === $obj2` work for you ?
> Think of it like this:
> - in file bootstrap.php I see this object initialized and passed somewhere
> - in file view.phtml I receive the object of the same
PHP has evolved a lot in recent years but we still can't have a static and
a nonstatic function with the same name:
class A {
function bla() { echo 'normal'; }
static function bla() { echo 'static'; }
}
A::bla();
## ERROR: Cannot redeclare A::bla()
And also PHP supports calling static
On 28 November 2014 at 07:04, Joe Watkins wrote:
>
> I don't think so, there is talk of removing object handles in 7.
Could you point me to a discussion about this? Tnx.
> Even if we intended to keep object handles, this leaks implementation
> details that we don't really want
On 28 November 2014 at 04:10, reeze wrote:
> Won't `$obj1 === $obj2` work for you ?
>
This works if you have two objects which are easily accessible in the same
scope.
Not that it can not be done this way, but it may require jumping through
hoops to get two object references into the common s
>>> > On Mon, Nov 10, 2014 at 12:02 PM, Johannes Schlüter <
>>> > johan...@schlueters.de> wrote:
>>> >
>>> >> On Thu, 2014-11-06 at 19:52 -0500, Peter Wolanin wrote:
>>> >> > Suggested solution: add a PDO attribute that could be set on a
>>> >> > connection or a driver option for PDO::prepare to en
Hi Levi,
if you remember, in my patch return_type was actually stored in
arg_info[-1].
it was mainly done for unification and to allow return type hinting for
internal functions (they already use arg_info[-1])
So the strictures may be compatible.
See https://gist.github.com/dstogov/8deb8b17e41c1a5
On Tue, Nov 18, 2014 at 9:34 PM, Stanislav Malyshev
wrote:
> Hi!
>
> The vote for https://wiki.php.net/rfc/secure_unserialize has been
> completed (actually, should be last week but I was busy, sorry for the
> delay) and the RFC is accepted 17 votes for to 6 votes against.
>
> Now, there were pro
On Fri, Nov 28, 2014 at 5:39 PM, Patrick Schaaf wrote:
>
> Am 28.11.2014 15:46 schrieb "Ferenc Kovacs" :
> >
> > from a quick test using spl_object_hash seems to be the slower with big
> number of elements in haystack.
>
> Your test only does the is-it-known test once. For an already-visited-set
> I prefer option (3) - invariant return types.
> Actually, return type compatibility check should follow all the rules for
> parameter type compatibility check (may be even reuse or share the code).
Realistically there isn't much code to share, especially since the two
structures are incompatible
Am 28.11.2014 15:46 schrieb "Ferenc Kovacs" :
>
> from a quick test using spl_object_hash seems to be the slower with big
number of elements in haystack.
Your test only does the is-it-known test once. For an already-visited-set
use case the test will run once for each visited element, and will usu
The vote is now closed; The RFC was accepted 34 to 2.
Zeev
*From:* Zeev Suraski [mailto:z...@zend.com]
*Sent:* Thursday, November 27, 2014 12:09 PM
*To:* PHP internals (internals@lists.php.net)
*Subject:* RE: [VOTE] [RFC] PHP 7.0 timeline
All,
The vote will end tomorrow at noon GMT – i
On Fri, Nov 28, 2014 at 3:02 PM, Patrick Schaaf wrote:
> On Friday 28 November 2014 14:51:55 Ferenc Kovacs wrote:
>
> >
>
> > I also used spl_object_hash() in the past when traversing/custom
>
> > serializing object structures which can have infinite recursions between
>
> > objects, but even th
Ferenc Kovacs wrote on 28/11/2014 13:51:
On Fri, Nov 28, 2014 at 2:14 PM, Sebastian Krebs
wrote:
2014-11-28 2:13 GMT+01:00 Bostjan Skufca :
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger librarie
On Friday 28 November 2014 14:51:55 Ferenc Kovacs wrote:
>
> I also used spl_object_hash() in the past when traversing/custom
> serializing object structures which can have infinite recursions
between
> objects, but even that could be simply solved by storing the already
> traversed objects in an
On Fri, Nov 28, 2014 at 2:14 PM, Sebastian Krebs
wrote:
> 2014-11-28 2:13 GMT+01:00 Bostjan Skufca :
>
> > Hello everyone,
> >
> > this is a proposal to add new function to PHP core: spl_object_id()
> >
> >
> > The story:
> >
> > Recently I was debugging some larger libraries and sorely
2014-11-28 2:13 GMT+01:00 Bostjan Skufca :
> Hello everyone,
>
> this is a proposal to add new function to PHP core: spl_object_id()
>
>
> The story:
>
> Recently I was debugging some larger libraries and sorely missed a function
> that would return an object ID. A function called spl_obj
Hello,
PHP 5.5.20RC1 is available for testing.
You can download it from
http://downloads.php.net/jpauli/
The Windows binaries are available at http://windows.php.net/qa/
This release contains a number of bugfixes, many of them about the PHP-FPM
IPV6 support feature.
We'd like to point you to t
> On 28 Nov 2014, at 12:27, Dmitry Stogov wrote:
>
> I didn't get what you mean.
> parameters are invariant, "invariance, which is safe for both" and " it
> shouldn't match parameters" are contradictory.
Well, that’s why I said “the exception is invariance”.
--
Andrea Faulds
http://ajf.me/
I didn't get what you mean.
parameters are invariant, "invariance, which is safe for both" and " it
shouldn't match parameters" are contradictory.
Thanks. Dmitry.
On Fri, Nov 28, 2014 at 1:57 PM, Andrea Faulds wrote:
>
> > On 28 Nov 2014, at 09:31, Dmitry Stogov wrote:
> >
> > I prefer option
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 28/11/2014 10:10, Dmitry Stogov a écrit :
> I see no problems with these patches. If all tests on PPC are
> passed, then they should be accepted. The patches won't affect
> other architectures.
>
> Anybody tested?
I should be able to run some scra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 28/11/2014 08:50, Remi Collet a écrit :
> 5.6.4RC1 already built in Fedora rawhide, which means Koschei [1]
> will run (slowly, in the next days) a scratch rebuild of all the
> PHP stack, with the test suites (various libraries, phpunit,
> symfony,
Andrea Faulds wrote on 28/11/2014 10:57:
On 28 Nov 2014, at 09:31, Dmitry Stogov wrote:
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
No, it shoul
> On 28 Nov 2014, at 09:31, Dmitry Stogov wrote:
>
> I prefer option (3) - invariant return types.
> Actually, return type compatibility check should follow all the rules for
> parameter type compatibility check (may be even reuse or share the code).
No, it shouldn't match parameters, that'd br
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
This solution may be implemented efficiently and consistently.
It also must be enough for 99% use cases.
I see no problems with these patches.
If all tests on PPC are passed, then they should be accepted.
The patches won't affect other architectures.
Anybody tested?
Thanks. Dmitry.
On Thu, Nov 27, 2014 at 3:39 PM, Gustavo Frederico Temple Pedrosa <
gustavo.pedr...@eldorado.org.br> wrote:
> Hi, int
On 28 November 2014 06:51:56 GMT, Stanislav Malyshev
wrote:
>Hi!
>
>> We already have the single-byte versions: chr() and ord(). It's been
>on
>
>Not really. chr(0xA1) is a byte with value 0xA1. The function I propose
>would instead produce "\xC2\xA1".
Ah, yes, so it would. According to MDN, the
On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui wrote:
> Hey:
>
> On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov wrote:
> > Hi,
> >
> > I'm working on call/return sequence optimization. As part of this work
> I'm
> > minimizing the size of call frame (zend_execute_data) and number of
> > read/write
43 matches
Mail list logo
