[PHP-DEV] Re: [RFC] Spaceship operator RFC

2015-04-19 Thread Stanislav Malyshev
Hi! > There is the following example in the RFC: > > // only values are compared > $a = (object) ["a" => "b"]; > $b = (object) ["b" => "b"]; > echo $a <=> $b; // 0 > > But the actual result is currently 1, not 0. Ahh, I see. I think it's the mistake in the RFC. These objects are

[PHP-DEV] Re: [RFC] Spaceship operator RFC

2015-04-19 Thread Christoph Becker
Hi! Stanislav Malyshev wrote: > >> A discrepancy between the actual behavior of the spaceship operator and >> an example given in its RFC has been reported recently (bug #69466[1]). > > I'm not sure what the discrepancy is, could you explain? There is the following example in the RFC: // on

Re: [PHP-DEV] Closure::call() to access private data, really ?

2015-04-19 Thread Stanislav Malyshev
Hi! > Just a simple use case showing how dangerous that is : > > $p = function($p) { $this->$p = new Stdclass; }; > $p->call($e = new Exception, 'trace'); > throw $e; Yes, this is not good, and this is the consequence of allowing to rebind closures. I'm not sure though how to fix it except for

[PHP-DEV] Re: [RFC] Spaceship operator RFC

2015-04-19 Thread Stanislav Malyshev
Hi! > A discrepancy between the actual behavior of the spaceship operator and > an example given in its RFC has been reported recently (bug #69466[1]). I'm not sure what the discrepancy is, could you explain? > To me it appears that there is a contradiction in the RFC (see my > comment on the re

Re: [PHP-DEV] Closure::call() to access private data, really ?

2015-04-19 Thread Jakub Kubíček
My opinion is, that we simply have to change PHP closures' scoping to be more similar with JavaScript functions' scope. That would solve the current challenge pointed on by @jpauli, thus closure would have access to private object's members only if it was defined in that object's class / method def

Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

2015-04-19 Thread Jakub Kubíček
So, get directly to your questions: > > 1) Can we still integrate this functionality to existing class CURLFile? I think it would be possible, because like @smalyshev said, CURLFile represents symbolic file, that is going to be uploaded with CURL. So my suggestion would be creating a static fact

Re: [PHP-DEV] RFC: spl_autoload_register() should provide kind of entity to load

2015-04-19 Thread georges
Yes, i finally rewritten major part of my code following the recommended SF2 standard for naming convention of trait/interfaces. Thanks Internals. Regards, Geo. Geolim4 2015-04-19 15:33 GMT+02:00 François Laupretre : > > De : georges [mailto:geol...@gmail.com] > > > > Currently spl_autoload_re

RE: [PHP-DEV] RFC: spl_autoload_register() should provide kind of entity to load

2015-04-19 Thread François Laupretre
> De : georges [mailto:geol...@gmail.com] > > Currently spl_autoload_register() pass the name of the class entity to the > first *Callable* argument​, but there is now way (as i far i know) to know > what kind of entity we're looking for. > -Class ? > -Interface ? > -Trait? As others already said,

[PHP-DEV] Re: [RFC] Spaceship operator RFC

2015-04-19 Thread Christoph Becker
Hi! Stanislav Malyshev wrote: > As expected, spaceship operator RFC > (https://wiki.php.net/rfc/combined-comparison-operator) passed 43 votes > to 11. I'll proceed with merging it soon. A discrepancy between the actual behavior of the spaceship operator and an example given in its RFC has been r