[PHP-DEV] interesting read about challenges in the drupal organization

[Ferenc Kovacs]

Hi,

while readon through http://www.garfieldtech.com/blog/on-drupals-leadership,
I've realized that there is a bunch of similarities between php internals
and drupal (which isn't that surprising), so I thought they guys around
there perceive the challenges/problems and the different possible solutions
for those.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] interesting read about challenges in the drupal organization

[Florian Margaine]

Hi,

Le 17 déc. 2014 09:54, "Ferenc Kovacs"  a écrit :
>
> Hi,
>
> while readon through
http://www.garfieldtech.com/blog/on-drupals-leadership,
> I've realized that there is a bunch of similarities between php internals
> and drupal (which isn't that surprising), so I thought they guys around
> there perceive the challenges/problems and the different possible
solutions
> for those.
>

I haven't read the article yet, but there is a fundamental difference
between Drupal and php: Drupal has a BDFL.

> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

Cheers,
Florian

Re: [PHP-DEV] interesting read about challenges in the drupal organization

[Ferenc Kovacs]

On Wed, Dec 17, 2014 at 10:23 AM, Florian Margaine 
wrote:
>
> Hi,
>
> Le 17 déc. 2014 09:54, "Ferenc Kovacs"  a écrit :
> >
> > Hi,
> >
> > while readon through
> http://www.garfieldtech.com/blog/on-drupals-leadership,
> > I've realized that there is a bunch of similarities between php internals
> > and drupal (which isn't that surprising), so I thought they guys around
> > there perceive the challenges/problems and the different possible
> solutions
> > for those.
> >
>
> I haven't read the article yet, but there is a fundamental difference
> between Drupal and php: Drupal has a BDFL.
>
you should check out the article, Larry also goes into details about the
topic, and how Drupal seem to try avoiding focusing to much power in one
hand and potential abuse which also has negative effects (lack of clarity
and the fear of making decisions).
relevant parts are:
"A good formal structure offers something that an informal structure
cannot: Clarity. If a new contributor wants to ask someone in a
"leadership" position if what they're proposing is consistent with the
project direction, goals, or software design, who should they ask? Me?
Gábor? catch? xjm? Daniel Wehner? Tim Plunkett? Angie Byron? Alex
Bronstein? chx? Dries himself? Depending on the question the answer could
be very different; even among those "leaders" I doubt there's consensus on
which of them to ask, much less what the answer should be. That's actively
hostile to new contributors, because then they don't know if what they're
suggesting (be it big or small) would even be accepted until it's committed
(and occasionally not even then
). That is, it makes
most contributions spec work, even for those in de facto leadership
positions."

and

"If the movement continues deliberately to not select who shall exercise
power, it does not thereby abolish power. All it does is abdicate the right
to demand that those who do exercise power and influence be responsible for
it. If the movement continues to keep power as diffuse as possible because
it knows it cannot demand responsibility from those who have it... it
insures that the movement is as ineffective as possible."

really interesting read.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] Re: [RFC] pecl_http

[Michael Wallner]

On 19/08/14 09:49, Michael Wallner wrote:
> Hi PHP internals!
> 
> I've created an RFC for discussion:
> 
>   Whether it is feasible to add pecl_http v2 to the core.
> 
> https://wiki.php.net/rfc/pecl_http
> 

Just a minor update: the two PECL depencies have been ported to ZE3.

-- 
Regards,
Mike

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP 5.7

[Michael Wallner]

On 17/12/14 00:45, Andrea Faulds wrote:
> Hi Pierre,
> 
>> On 16 Dec 2014, at 23:42, Pierre Joye 
>> wrote:
>> 
>> 
>> On Dec 17, 2014 4:19 AM, "Andrea Faulds"  wrote:
>>> 
>>> Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's
>>> support by a year sounds like a better solution. If others agree,
>>> I might withdraw this RFC.
>> 
>> Please do not.
>> 
> 
> I’m not considering dropping the RFC because of opposition. Rather, I
> think that suggestion is actually better than having a 5.7 release.
> 

I'd definitely be in favor of concentrating on 7.0 and rather have
external supportive tools instead of an 5.7 release.

-- 
Regards,
Mike

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Rowan Collins]

Stanislav Malyshev wrote on 17/12/2014 02:14:

No, it's not possible. It is possible to call object method in an
expression, and then use the result of the expression as an array key.
But to do that you'd have to check that you're dealing with the object
and the call the special method.


I think what Christoph was getting at is that you could implement an 
object map pretty simply by requiring the objects being added to 
implement a particular interface, as in:


...
function add ( Hashable $obj ) {
$this->data[ $obj->getHash() ] = $obj;
}
...

The main thing that the current RFC would simplify is being able to 
accept a mixture of objects and scalars without performing an extra 
check; currently, you'd have to write something like this:


...
function add ( $scalar_or_obj ) {
if ( is_scalar($scalar_or_obj) ) {
$this->data[ $scalar_or_obj ] = $scalar_or_obj;
} elseif ( $scalar_or_obj instanceOf Hashable ) {
$this->data[ $obj->getHash() ] = $obj;
} else {
throw new InvalidArgumentException;
}
}
...

Which is certainly uglier, any maybe was the case that Guilherme had in 
mind, but it's not like you have to build a whole new type of data 
structure, just add a few lines of implementation.


Compare that to trying to store the actual objects as keys, which would 
require a lot more than a few lines of code to emulate in pure PHP. 
Luckily, we have SplObjectStorage, which maybe makes that rather less 
urgent as well.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Derick Rethans]

On Tue, 16 Dec 2014, Stanislav Malyshev wrote:

> I'd like to initiate a vote on "objects as keys" RFC:
> https://wiki.php.net/rfc/objkey

I wonder why you opened voting on this, before resolving the "Open 
Issues":

Open Issues

Should SplFixedArray support object indexes?
Should SplObjectStorage support calling __hash for an object if it exists?

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP 5.7

[Derick Rethans]

On Tue, 16 Dec 2014, Ferenc Kovacs wrote:

> > > - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not 
> > >   new features cancels point number one
> > >
> > > What else ?
> >
> > Do nothing is still (IMHO) the most sensible option IMHO.  We're not 
> > seeing major compatibility breakages in 7.0 (at least not at this 
> > time), to the level that upgrading through some middle version is 
> > really all that necessary.
> 
> we don't have much or really big ones(yet), we have a couple of nasty 
> ones (eg. doesn't blow up, but behaves differently, check the mails 
> from Derick complaining about those).

Those should never have made it into PHP 7 at all. It's like a big "fuck 
you" to users.

> and there are a couple ones upcoming/likely to make it through:
> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7

I think we should bump up the granularity of the voting options there. 
As some I think are ok, for example:

- dl on fpm-fcgi (since PHP 5.3)

But others are not:

- CN_match and SNI_server_name stream context option (since PHP 5.6; 
  use peer_name instead) [TODO]

> >   The one option that could be relevant to these scenarios is a 
> > separate analysis tool, but it's much more difficult to pull off, 
> > and I don't think the level of breakage (as it appears right now) 
> > justifies the effort.
>
> fortunately we already have a couple of those for some of the nasty changes
> like https://gist.github.com/nikic/ffd019ef78b72934c7cc for finding code
> which would be affected by the behavior change of
> https://wiki.php.net/rfc/uniform_variable_syntax
> I do think that while those kind of extra steps are not mandatory per se,
> but they help a lot when convincing people to jump the ship and upgrade.

I would go as far as making it mandatory if you change bahaviour of 
existing syntax that can't be detected through a simple "php -l".

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[guilhermebla...@gmail.com]

Hi,

Answering the question of Christopher Becker. It is not possible to
traverse and get your desired elements.
How would you achieve a foreach by key (returning object) without having to
store a separate list and track by hash or through an interface?

Cheers,

On Wed, Dec 17, 2014 at 10:04 AM, Derick Rethans  wrote:
>
> On Tue, 16 Dec 2014, Stanislav Malyshev wrote:
>
> > I'd like to initiate a vote on "objects as keys" RFC:
> > https://wiki.php.net/rfc/objkey
>
> I wonder why you opened voting on this, before resolving the "Open
> Issues":
>
> Open Issues
>
> Should SplFixedArray support object indexes?
> Should SplObjectStorage support calling __hash for an object if it
> exists?
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Christoph Becker]

guilhermebla...@gmail.com wrote:

> Answering the question of Christopher Becker. It is not possible to
> traverse and get your desired elements.
> How would you achieve a foreach by key (returning object) without having to
> store a separate list and track by hash or through an interface?

AIUI, the RFC proposes that __hash() returns a string or an int, and
this value (not the object itself) will be stored and retrieved as key
of the array.

:

| Create a new magic method, __hash() which is called when object is
| supplied as a hash key, and returns string or integer that is used as
| the hash key.

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Etienne Kneuss]

On Wed Dec 17 2014 at 1:44:13 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Hi,
>
> Answering the question of Christopher Becker. It is not possible to
> traverse and get your desired elements.
> How would you achieve a foreach by key (returning object) without having to
> store a separate list and track by hash or through an interface?
>
>
Which is one of the main problem with this very RFC.

What ends up being stored in the array is the hash, not the object. And
there is no immediate way of getting the key object back. The user writes:
  $arr = array($obj => 2);  but key($arr) returns the hash only.

As I said in the original discussion: this RFC is actually about having an
implicit call to __hash() whenever an object is used as an array key. You
can achieve exactly the same in userland with an explicit call.

I would rather wait (maybe indefinitely) to have a proper implementation of
objects as keys than have this compromise.

Best,

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Christoph Becker]

Rowan Collins wrote:

> Stanislav Malyshev wrote on 17/12/2014 02:14:
>> No, it's not possible. It is possible to call object method in an
>> expression, and then use the result of the expression as an array key.
>> But to do that you'd have to check that you're dealing with the object
>> and the call the special method.
> 
> I think what Christoph was getting at is that you could implement an
> object map pretty simply by requiring the objects being added to
> implement a particular interface, as in:
> 
> 
> function add ( Hashable $obj ) {
> $this->data[ $obj->getHash() ] = $obj;
> }
> 
> 
> The main thing that the current RFC would simplify is being able to
> accept a mixture of objects and scalars without performing an extra
> check; currently, you'd have to write something like this:
> 
> 
> function add ( $scalar_or_obj ) {
> if ( is_scalar($scalar_or_obj) ) {
> $this->data[ $scalar_or_obj ] = $scalar_or_obj;
> } elseif ( $scalar_or_obj instanceOf Hashable ) {
> $this->data[ $obj->getHash() ] = $obj;
> } else {
> throw new InvalidArgumentException;
> }
> }
> 
> 
> Which is certainly uglier, any maybe was the case that Guilherme had in
> mind, but it's not like you have to build a whole new type of data
> structure, just add a few lines of implementation.

Yes, that is what I was trying to convey. :)

> Compare that to trying to store the actual objects as keys, which would
> require a lot more than a few lines of code to emulate in pure PHP.
> Luckily, we have SplObjectStorage, which maybe makes that rather less
> urgent as well.

I agree.  However, the RFC mentions a related open issue[1]:

| Should SplObjectStorage support calling __hash for an object if it
| exists?

It might be good to discuss and resolve this issue, as Derick has
already pointed out[2].

[1] 
[2] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Rowan Collins]

guilhermebla...@gmail.com wrote on 17/12/2014 12:43:

Answering the question of Christopher Becker. It is not possible to
traverse and get your desired elements.
How would you achieve a foreach by key (returning object) without having to
store a separate list and track by hash or through an interface?


SplObjectStorage supports that mechanism, although it's not the most 
intuitive design. See this comment in the manual: 
http://php.net/manual/en/class.splobjectstorage.php#114059


As others have pointed out, this proposal does *not* support that usage, 
because the hash function is one-way, and you cannot get back the object 
based only on the calculated key. All it does is reduce the boilerplate 
needed for hashing an object to produce a suitable array key.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] PHP 5.7

[Zeev Suraski]

could you clarify one thing for me?

from that sentence it seems that you aren't really against having small new
features (as those are already happened/happening in 5.6.x and you did not
mention that you have a problem with that) but you think that there would
be more/bigger features happening if there would be an 5.7 version?



I’m opposed to having a 5.7 release that has new features on top of 5.6.x.
There should be no new feature release in the 5.x line beyond 5.6.x.

I also think we should minimize any new work on 5.6.x as much as possible,
and focus all of our efforts on 7.0.

[PHP-DEV] Re: PHPT curl tests - PHP 5.3.4 branch misses the skipif.inc file

[Lior Kaplan]

Hi,

Can someone please do this minor change in the PHP 5.4 tests ?

Kaplan

On Wed, Dec 3, 2014 at 6:08 PM, Lior Kaplan  wrote:
>
> Hi Stas,
>
> I don't have permissions to fix this myself as the 5.4 branch is closed
> for security only.
>
> You've added ext/curl/tests/bug68089.phpt which includes skipif.inc in the
> same directory.
>
> Could you either copy the file from 5.5 branch or put its contents instead
> of the include ?
>
>
> $ git show PHP-5.5:ext/curl/tests/skipif.inc
>  if (!extension_loaded("curl")) exit("skip curl extension not loaded");
> if(false === getenv('PHP_CURL_HTTP_REMOTE_SERVER')) {
> if (php_sapi_name() != "cli") {
> die("skip PHP_CURL_HTTP_REMOTE_SERVER env variable is not
> defined");
> }
>
>
> Thanks,
>
> Kaplan
>
>
> -- Forwarded message --
> From: Eyal Teutsch 
> Date: Thu, Oct 30, 2014 at 9:21 AM
> Subject: PHPT curl tests - PHP 5.3.4 branch misses the skipif.inc file
> To: Lior Kaplan 
> Cc: Gadi Goldbarg 
>
>
> Kaplan,
>
> We noticed here that the 5.4.34 branch 9
> https://github.com/php/php-src/tree/PHP-5.4.34/ext/curl/tests) misses the
> skipif.inc file which is required by some of the tests, and which exists in
> the master (https://github.com/php/php-src/tree/master/ext/curl/tests) .
>
> As our PHP ambassador, could you please fix that?
>
> thx
> T
>
>

[PHP-DEV] Re: PHPT curl tests - PHP 5.3.4 branch misses the skipif.inc file

[Lior Kaplan]

Ignore this, already fixed by Stas... didn't notice.

http://git.php.net/?p=php-src.git;a=commitdiff;h=b75867fff0d141bf2f81646dd5fae991e85b26ca

Kaplan

On Wed, Dec 17, 2014 at 4:05 PM, Lior Kaplan  wrote:
>
> Hi,
>
> Can someone please do this minor change in the PHP 5.4 tests ?
>
> Kaplan
>
> On Wed, Dec 3, 2014 at 6:08 PM, Lior Kaplan  wrote:
>>
>> Hi Stas,
>>
>> I don't have permissions to fix this myself as the 5.4 branch is closed
>> for security only.
>>
>> You've added ext/curl/tests/bug68089.phpt which includes skipif.inc in
>> the same directory.
>>
>> Could you either copy the file from 5.5 branch or put its contents
>> instead of the include ?
>>
>>
>> $ git show PHP-5.5:ext/curl/tests/skipif.inc
>> > if (!extension_loaded("curl")) exit("skip curl extension not loaded");
>> if(false === getenv('PHP_CURL_HTTP_REMOTE_SERVER')) {
>> if (php_sapi_name() != "cli") {
>> die("skip PHP_CURL_HTTP_REMOTE_SERVER env variable is not
>> defined");
>> }
>>
>>
>> Thanks,
>>
>> Kaplan
>>
>>
>> -- Forwarded message --
>> From: Eyal Teutsch 
>> Date: Thu, Oct 30, 2014 at 9:21 AM
>> Subject: PHPT curl tests - PHP 5.3.4 branch misses the skipif.inc file
>> To: Lior Kaplan 
>> Cc: Gadi Goldbarg 
>>
>>
>> Kaplan,
>>
>> We noticed here that the 5.4.34 branch 9
>> https://github.com/php/php-src/tree/PHP-5.4.34/ext/curl/tests) misses
>> the skipif.inc file which is required by some of the tests, and which
>> exists in the master (
>> https://github.com/php/php-src/tree/master/ext/curl/tests) .
>>
>> As our PHP ambassador, could you please fix that?
>>
>> thx
>> T
>>
>>

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Christoph Becker]

Stanislav Malyshev wrote:

>> Yes, but it is already possible to call an object's method in array key
>> context, so in combination with an appropriate interface the same can be
>> accomplished.
> 
> No, it's not possible. It is possible to call object method in an
> expression, and then use the result of the expression as an array key.
> But to do that you'd have to check that you're dealing with the object
> and the call the special method.

Sorry for expressing myself imprecisely.  Thanks to Rowan this is
hopefully clarified now, see
.

> Looks like you don't understand why PHP has magic methods - since your
> argument applies to every one of them. Why have __toString if you can
> just call object method? Why have __call if you could just check if
> method exists and call a special method if it doesn't? Why have __isset
> if you could just call special method on an object and pass it the
> property name? Of course, it's "just sugar". All programming languages
> are "just sugar" by that definition.

I'm neither arguing against having magic methods and other (syntactic)
sugar in general, nor against having __hash() or __toKey() in
particular.  It's perfectly fine for me, if the RFC passes.

>> I didn't mean to argue against the RFC, but merely wanted to point out
>> that one could have object hashes without the proposed magic method
>> (albeit in a more contrived way).
> 
> You could have *everything* in a more contrived way. PHP 2 was Turing
> complete, I am sure. Were we just wasting time these last 15 or so years
> because everything was done in PHP since then was already possible,
> albeit "in a more contrived way"? Or maybe there's some value in making
> the ways significantly less contrived? IMO, that's the whole point of
> what we're doing here.

I do really appreciate your work, and I enjoy having a more expressive
language.  I justed wanted to point out Guilherme's apparent
misinterpretation of your RFC, see
.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] interesting read about challenges in the drupal organization

[Larry Garfield]

On 12/17/14, 3:30 AM, Ferenc Kovacs wrote:

On Wed, Dec 17, 2014 at 10:23 AM, Florian Margaine 
wrote:


Hi,

Le 17 déc. 2014 09:54, "Ferenc Kovacs"  a écrit :


Hi,

while readon through

http://www.garfieldtech.com/blog/on-drupals-leadership,

I've realized that there is a bunch of similarities between php internals
and drupal (which isn't that surprising), so I thought they guys around
there perceive the challenges/problems and the different possible

solutions

for those.



I haven't read the article yet, but there is a fundamental difference
between Drupal and php: Drupal has a BDFL.


you should check out the article, Larry also goes into details about the
topic, and how Drupal seem to try avoiding focusing to much power in one
hand and potential abuse which also has negative effects (lack of clarity
and the fear of making decisions).
relevant parts are:
"A good formal structure offers something that an informal structure
cannot: Clarity. If a new contributor wants to ask someone in a
"leadership" position if what they're proposing is consistent with the
project direction, goals, or software design, who should they ask? Me?
Gábor? catch? xjm? Daniel Wehner? Tim Plunkett? Angie Byron? Alex
Bronstein? chx? Dries himself? Depending on the question the answer could
be very different; even among those "leaders" I doubt there's consensus on
which of them to ask, much less what the answer should be. That's actively
hostile to new contributors, because then they don't know if what they're
suggesting (be it big or small) would even be accepted until it's committed
(and occasionally not even then
). That is, it makes
most contributions spec work, even for those in de facto leadership
positions."

and

"If the movement continues deliberately to not select who shall exercise
power, it does not thereby abolish power. All it does is abdicate the right
to demand that those who do exercise power and influence be responsible for
it. If the movement continues to keep power as diffuse as possible because
it knows it cannot demand responsibility from those who have it... it
insures that the movement is as ineffective as possible."

really interesting read.


Thanks for the shout-out, Ferenc. :-)

While Drupal has a BDFL (Dries Buytaert), he is a very soft-touch BDFL. 
 Soft-touch to the point that he may as well not be there more often 
than not.  There's a very few number of appointees that he names that 
are more active and impactful, but even they have almost no official 
formal power or authority.  (I am one of them.)  This is a lengthy, 
ongoing discussion about the need for structure as a project scales, 
something that many people really really don't like to think about.


I've been collecting installments in this discussion within Drupal going 
back years:


http://www.garfieldtech.com/drupal/leadership

And yes, I do believe  much of the discussion applies to PHP Internals, 
too (with some caveats of course, since they are different projects).  I 
especially recommend Lisa Welchman's "The Paradox of Open Growth" talk, 
linked from about the middle of the document, which applies to any 
growing community.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP 5.7

[Sebastian Bergmann]

Am 17.12.2014 um 15:54 schrieb Zeev Suraski:
> I’m opposed to having a 5.7 release that has new features on
> top of 5.6.x.

 Same here; 5.7 should only add deprecations etc. and must not add new
 features.

> I also think we should minimize any new work on 5.6.x as much as
> possible, and focus all of our efforts on 7.0.

 PHP 5.6.X must not get any more new features and should only receive
 bug fixes. The only real work I see for PHP 5.7 is to decide which
 deprecations etc. to add. The actual implementation of those should
 be trivial.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Stanislav Malyshev]

Hi!

> I wonder why you opened voting on this, before resolving the "Open 
> Issues":
> 
> Open Issues
> 
> Should SplFixedArray support object indexes?
> Should SplObjectStorage support calling __hash for an object if it exists?

These issues are not part of the RFC's target, they are possible
improvements to SPL *if* the RFC is accepted. I don't want to spend time
on them if it is not. If it is, then we can see how to improve SPL
classes to support it, but it's a different questions from the main RFC.
I just mentioned it in order to not forget these things need to be
discussed if the RFC is accepted.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Stanislav Malyshev]

Hi!

> As I said in the original discussion: this RFC is actually about having
> an implicit call to __hash() whenever an object is used as an array key.
> You can achieve exactly the same in userland with an explicit call.

It's like nobody have ever seen __toString before... Of course you can
do that 10-line boilerplate that Rowan outlined. The whole point of this
RFC is so you don't have to do the boilerplate.

> I would rather wait (maybe indefinitely) to have a proper implementation
> of objects as keys than have this compromise.

I have hard time to understand this - it's like somebody offering to
give you $100, with no conditions, and you say "no, I'd rather wait for
somebody giving me a billion dollars, until then I won't take the $100".
Having object as keys does not contradict this RFC in any way - though
the probability of it happening in PHP 7 is pretty much nil so you'd
have to wait at least several years, but most probably - forever. So you
pretty much choosing to have nothing over having something with no
upside at all. Why?
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Levi Morrison]

This RFC proposes that we store the hash of an object instead of the
actual object. That's simply not useful to me and likely prevents us
from adding support for objects as keys in the future should we want
it.

In addition, it adds yet another behavior to arrays which do so many
things already. I would much rather have structures that focus on
narrow responsibilities and do that well, such as an improved Map
structure instead of SplObjectStorage. This isn't some pie-in-the-sky
wishing, either; I've been working on this for years now in my spare
time.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Stanislav Malyshev]

Hi!

> This RFC proposes that we store the hash of an object instead of the
> actual object. That's simply not useful to me 

Fair enough, but this is not only about what is useful personally to you.

> and likely prevents us
> from adding support for objects as keys in the future should we want

No it does not. It was already explained several times. If it is ever
introduced, it can be used for objects that do not explicitly request
functionality in this RFC by enabling __hash() with no BC issues, since
this RFC only affects classes that explicitly ask for this specific
functionality. So if you, according to the above, would never use
__hash, absolutely nothing would prevent you from using objects as keys
if it ever happens (which it probably won't in the next 2-3 years).

> In addition, it adds yet another behavior to arrays which do so many
> things already. I would much rather have structures that focus on

It's exactly the same behavior, just available for select objects now.
Arrays don't do anything new, they still store key/value pairs, objects
do something new to enable you doing more things with value objects.

> I would much rather have structures that focus on
narrow responsibilities and do that well, such as an improved Map
structure instead of SplObjectStorage

Nothing in this RFC prevents you from having such structures. In fact,
this RFC would enable more convenient handling of such structures,
providing common method for requesting the programmable hash value of
the object - a feature which most languages have, but PHP does not.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Levi Morrison]

>> and likely prevents us
>> from adding support for objects as keys in the future should we want
>
> No it does not. It was already explained several times. If it is ever
> introduced, it can be used for objects that do not explicitly request
> functionality in this RFC by enabling __hash() with no BC issues, since
> this RFC only affects classes that explicitly ask for this specific
> functionality. So if you, according to the above, would never use
> __hash, absolutely nothing would prevent you from using objects as keys
> if it ever happens (which it probably won't in the next 2-3 years).

Just because you say it doesn't affect it doesn't mean it doesn't. I
think it would be quite silly to support storing hashes and/or storing
objects and to me that blocks the latter since you are proposing the
former.

> Nothing in this RFC prevents you from having such structures. In fact,
> this RFC would enable more convenient handling of such structures,
> providing common method for requesting the programmable hash value of
> the object - a feature which most languages have, but PHP does not.

Programmable hashes of objects should be external to the object anyway
because eventually someone wants to store the same object in a
different way in two different structures.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE][RFC] Native TLS

[Anatol Belski]

Hi,

On Wed, December 10, 2014 20:04, Anatol Belski wrote:
> Hi,
>
>
> hereby the voting on https://wiki.php.net/rfc/native-tls#vote is opened.
> The vote starts on 12/10/2014 at 21:00 CET and ends on 12/17/2014 at
> 21:00
> CET.
>
>
this RFC was accepted, thanks everyone! I'm going to merge it next days.

Regards

Anatol


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Leigh]

On 16 December 2014 at 08:34, Stanislav Malyshev  wrote:
> Hi!
>
> I'd like to initiate a vote on "objects as keys" RFC:
> https://wiki.php.net/rfc/objkey
>
> I know this is a holiday season but it was extensively discussed and I
> think most people already formed their opinions. I've put the voting
> period as 3 weeks to have some time for people to vote even with the
> holidays, etc.
>
> The vote includes choice for the name. Vote for either name is counted
> as the vote for the overall proposal, and 2/3 majority is required as
> it's a language change.
>
> Some more expanded summary of the arguments is here:
> http://php100.wordpress.com/2014/12/14/objects-as-keys/ in case you're
> interested.

I've not read the whole email thread, but I have read the RFC, sorry
if I missed something in the emails.

I've voted no, I really don't see any benefit to automatically calling
a magic method for a key, this is a kind of unintuitive magic for me.

For objects as keys to be useful (in my opinion), a foreach loop or
array_search must be able to return the object as the key component.
The RFC doesn't offer a way to retrieve the original object from the
stored hash, indeed without a refcount++ the object may not even exist
any more.

I honestly like the idea of "objects as keys", but this RFC doesn't offer that.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE][RFC] Unicode Codepoint Escape Syntax

[Pascal Martin, AFUP]

On 09/12/2014 00:51, Andrea Faulds wrote:

Please read through the RFC and cast your vote if you wish to do so:

https://wiki.php.net/rfc/unicode_escape

Voting starts today (2014-12-08) and ends in 10 days’ time (2014-12-18).


Hi,

A more complete and "long term" approach might come from a better/deeper 
integration of Unicode into PHP itself -- but that won't happen for PHP 
7 (it failed with PHP 6).


That being said, the feature described here is quite small and concise, 
simple to use, useful in some situations, and shouldn't break BC too much.

So, after discussing with other members of AFUP, we are on the +1 side.

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Stanislav Malyshev]

Hi!

> Just because you say it doesn't affect it doesn't mean it doesn't. I
> think it would be quite silly to support storing hashes and/or storing
> objects and to me that blocks the latter since you are proposing the
> former.

I don't know why you think it's "quite silly" to have both scalar and
object keys, as that's exactly what would you need to implement with you
want object keys - scalar keys are not going to go anywhere. So your
assumption that this RFC somehow blocks objects as keys is still wrong.

> Programmable hashes of objects should be external to the object anyway
> because eventually someone wants to store the same object in a
> different way in two different structures.

That is the requirement that no language I can think of implements -
Java, Python, Ruby, C# all have programmatic hash method, and none of
them changes it for different structures.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Rowan Collins]

On 17/12/2014 17:03, Stanislav Malyshev wrote:

Hi!


As I said in the original discussion: this RFC is actually about having
an implicit call to __hash() whenever an object is used as an array key.
You can achieve exactly the same in userland with an explicit call.

It's like nobody have ever seen __toString before... Of course you can
do that 10-line boilerplate that Rowan outlined. The whole point of this
RFC is so you don't have to do the boilerplate.


Just to clarify, I in no way wanted to say that reducing that 
boilerplate was not a good thing. I was responding to the concept that 
this allows things which weren't previously possible. I definitely think 
syntactic sugar can be a good thing, and can see the advantage of this 
proposal.




I would rather wait (maybe indefinitely) to have a proper implementation
of objects as keys than have this compromise.

I have hard time to understand this - it's like somebody offering to
give you $100, with no conditions, and you say "no, I'd rather wait for
somebody giving me a billion dollars, until then I won't take the $100".
Having object as keys does not contradict this RFC in any way - though
the probability of it happening in PHP 7 is pretty much nil so you'd
have to wait at least several years, but most probably - forever. So you
pretty much choosing to have nothing over having something with no
upside at all. Why?


Yes, there are versions of objects-as-keys which are compatible with 
this proposal; however, there are also versions which are not.


For instance, without this proposal we could implement something so that 
*for any object*, $foo[$obj] = 42 stores the object as the key. If this 
RFC is already in place, then any object which uses __hash (or whatever 
name we give it) to return a scalar key cannot also be used in that way. 
That may not be a big deal - the creator of the object can choose which 
behaviour to use - but the creator of the containing structure couldn't, 
which might be a nuisance.


I guess the other way in which it reduces the chance of a more 
"complete" solution is a psychological one - once this is in there, the 
number of cases that need object-as-key support will be even lower, 
leaving those that aren't served by this version less likely to be 
approached.


I'm on the fence on this one. For one thing, I think it might be 
interesting to explore whether real objects as keys is actually as 
difficult as some people are assuming. I can naively imagine a few ways 
it could be implemented that seem in my mind to have minimal impact on 
any array that doesn't use it, but haven't yet seen anyone seriously 
discuss any possible approaches.


--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Rowan Collins]

On 17/12/2014 16:58, Stanislav Malyshev wrote:

Hi!


I wonder why you opened voting on this, before resolving the "Open
Issues":

Open Issues

 Should SplFixedArray support object indexes?
 Should SplObjectStorage support calling __hash for an object if it exists?

These issues are not part of the RFC's target, they are possible
improvements to SPL *if* the RFC is accepted. I don't want to spend time
on them if it is not. If it is, then we can see how to improve SPL
classes to support it, but it's a different questions from the main RFC.
I just mentioned it in order to not forget these things need to be
discussed if the RFC is accepted.



That makes sense. They should probably have gone under "Future Scope" 
rather than "Open Issues" in that case, looking at the wording on the 
template, but not a big deal.


--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Rowan Collins]

On 17/12/2014 22:05, Rowan Collins wrote:
For one thing, I think it might be interesting to explore whether real 
objects as keys is actually as difficult as some people are assuming. 
I can naively imagine a few ways it could be implemented that seem in 
my mind to have minimal impact on any array that doesn't use it, but 
haven't yet seen anyone seriously discuss any possible approaches. 


In fact, to expand on this, I'm going to stick my neck out and tell 
everyone my crackpot theory, which someone who actually understands the 
engine will probably demolish in 5 seconds flat, but makes sense in my 
mind. :P


The implementation of arrays could remain the same, with a single 
pointer to a second "shadow" HashTable, which would only be initialised 
when an object was actually added as a key. Thus the memory overhead 
would be reserving a single pointer per array (not per item), and the 
execution overhead (for any existing array usage) would be a single 
if(shadowPointer) check in a few key places.


The idea would be that the object would still be hashed - e.g. by 
default with spl_object_hash, but with __hash if set - and that key 
would be stored in the normal way. However, an extra entry would be 
added to the shadow array, as though you had also called $shadow[ 
$obj->__hash() ] = $obj.


We might want to do something tricksy to the key, like adding a null 
byte at the beginning, to make it less likely for a scalar key and an 
object hash to collide. This would also allow further short-cutting in 
lookups, since if the first byte was not \0, there would be no chance of 
a match in the shadow array. (If it was \0, there might still not be a 
shadow object, because null-prefixed strings are actually valid scalar 
keys, but this seems unlikely to be a common occurrence.)


Whenever an array key is taken as *input* (e.g. $foo[$bar], 
array_key_exists()), the hash function would be called (much as in the 
current RFC), and the corresponding value could be returned directly - 
the shadow table would not need to be touched, so performance would be 
identical to that of the current proposal.


A lookup in the shadow array would need to happen only when writing to 
the array, and when a key was being given as *output* (e.g. foreach ( $a 
as $k => $v ), array_search(), key()). This would happen at the speed of 
normal random access, and scale with the number of objects used as keys, 
not the number of items in the main array.


Like I say, I'm sure this is full of holes, and I'll leave it there 
before I get too far down a dead end, but I thought it might be a more 
productive line of thought than "this will probably never happen".


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Levi Morrison]

>> Programmable hashes of objects should be external to the object anyway
>> because eventually someone wants to store the same object in a
>> different way in two different structures.
>
> That is the requirement that no language I can think of implements -
> Java, Python, Ruby, C# all have programmatic hash method, and none of
> them changes it for different structures.

C++ commonly does this. You pass a "hash function" as a template or
constructor argument and use that for the structure. Additionally,
this allows you to easily support types that don't natively provide
internal hashing functions (such as objects from a third party
library).

In this case, doing it like Java, C# et al is an example of most
languages getting it wrong, not them getting it right.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[guilhermebla...@gmail.com]

Hi,

I originally considered you could retrieve the object key, but if it is not
possible by this RFC, I will switch my vote to no.

By storing hash one way it introduces a huge wtf to the language.

Cheers,
On Dec 17, 2014 8:40 PM, "Rowan Collins"  wrote:

> On 17/12/2014 22:05, Rowan Collins wrote:
>
>> For one thing, I think it might be interesting to explore whether real
>> objects as keys is actually as difficult as some people are assuming. I can
>> naively imagine a few ways it could be implemented that seem in my mind to
>> have minimal impact on any array that doesn't use it, but haven't yet seen
>> anyone seriously discuss any possible approaches.
>>
>
> In fact, to expand on this, I'm going to stick my neck out and tell
> everyone my crackpot theory, which someone who actually understands the
> engine will probably demolish in 5 seconds flat, but makes sense in my
> mind. :P
>
> The implementation of arrays could remain the same, with a single pointer
> to a second "shadow" HashTable, which would only be initialised when an
> object was actually added as a key. Thus the memory overhead would be
> reserving a single pointer per array (not per item), and the execution
> overhead (for any existing array usage) would be a single if(shadowPointer)
> check in a few key places.
>
> The idea would be that the object would still be hashed - e.g. by default
> with spl_object_hash, but with __hash if set - and that key would be stored
> in the normal way. However, an extra entry would be added to the shadow
> array, as though you had also called $shadow[ $obj->__hash() ] = $obj.
>
> We might want to do something tricksy to the key, like adding a null byte
> at the beginning, to make it less likely for a scalar key and an object
> hash to collide. This would also allow further short-cutting in lookups,
> since if the first byte was not \0, there would be no chance of a match in
> the shadow array. (If it was \0, there might still not be a shadow object,
> because null-prefixed strings are actually valid scalar keys, but this
> seems unlikely to be a common occurrence.)
>
> Whenever an array key is taken as *input* (e.g. $foo[$bar],
> array_key_exists()), the hash function would be called (much as in the
> current RFC), and the corresponding value could be returned directly - the
> shadow table would not need to be touched, so performance would be
> identical to that of the current proposal.
>
> A lookup in the shadow array would need to happen only when writing to the
> array, and when a key was being given as *output* (e.g. foreach ( $a as $k
> => $v ), array_search(), key()). This would happen at the speed of normal
> random access, and scale with the number of objects used as keys, not the
> number of items in the main array.
>
> Like I say, I'm sure this is full of holes, and I'll leave it there before
> I get too far down a dead end, but I thought it might be a more productive
> line of thought than "this will probably never happen".
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC] pecl_http

[Pierre Joye]

On Dec 17, 2014 5:26 PM, "Michael Wallner"  wrote:
>
> On 19/08/14 09:49, Michael Wallner wrote:
> > Hi PHP internals!
> >
> > I've created an RFC for discussion:
> >
> >   Whether it is feasible to add pecl_http v2 to the core.
> >
> > https://wiki.php.net/rfc/pecl_http
> >
>
> Just a minor update: the two PECL depencies have been ported to ZE3.
>

Btw, I still wonder if their features could be provided as part of php
instead of having to add 3 exts. Thoughts?