Re: [PHP-DEV] openssl_seal new param

[Jakub Zelenka]

Hi Anatol

On Mon, Aug 31, 2015 at 10:16 PM, Anatol Belski 
wrote:
>
> >
> > > > There also is an another thing for TS Win build (probably question
> > > > for
> > > Anatol and
> > > > Pierre :) ). The thing is that EVP_SealInit uses internally
> RAND_bytes.
> > > IIRC there is
> > > > some locking issue with openssl RAND on TS win ( the reason why
> > > > openssl_random_pseudo_bytes uses Win random) so I was wondering if
> > > > it should be disabled on win? The thing is that it is already a case
> > > > for
> > > other
> > > > functions. One example is generating key params in
> > > > openssl_pkey_new:
> > > >
> > > > openssl_pkey_new(array( 'dh'=> array( 'p' => $bin_prime, 'g' => '2'
> > > > )));
> > > >
> > > > This will also call RAND_bytes when generating priv key.
> > > >
> > > If you look into crypto/rand/rand_lib.c within the openssl src - it is
> > > not thread safe even in 1.0.2 branch. It is a good catch, but has only
> > > to do with the thread safety. And the issue is exactly that there is
> > > no locking around RAND_bytes() affected codes in PHP. So the issue is
> cross
> > platform.
> > >
> > > A quick solution could be using the mutex functionality exported from
> > > TSRM
> > > (tsrm_mutex_*() functions) in the thread safe builds for affected
> functions.
> > >
> > >
> > >
> > Yeah I was thinking about that after I sent an email yesterday. I will
> check if
> > there are more places where this can be an issue and try to put together
> a patch.
> >
> TSRM is probably the best we have in the core right now. Mutex will sure
> have a performance impact, but probably no way around it as openssl is
> always external. After yet looking at the APIs, maybe one could setup the
> default rand in MINIT, or force it to be always RAND_SSLeay(), but not sure
> it is a better idea than locking.
>

We could maybe set a different RAND method in MINIT using
RAND_set_default_method . However this is not recommended as it might be
rewritten by the engine API (when/if we add support for loading engines).

There also is an alternative way of locking. Rather than use mutex around
the function call in openssl.c, we could use CRYPTO_set_locking_callback
and register locking there. That should be faster as it locks just places
when the race condition can happen. However not sure if that will work for
Win as there is some issue with polling entropy as documented in [1] and
more info including proposed patch can be found in [2].

I will try to think about it a bit more later to see if I can come up with
anything.


[1] https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues

[2] https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Rowan Collins]

On 01/09/2015 10:29, Craig Francis wrote:

Personally I still like the idea of an exists(), because I feel that is how 
many programmers treat and use the isset() function - simply because they do 
use NULL as a valid value, and either haven't read the manual, or forget the 
exception that is mentioned on line 1 (something I've done a couple of times).


I'm still not sure how exists() would be anything other than an alias 
for array_key_exists().


Once again, this is NOT about "using NULL as a valid value"; it's about 
"using a variable's NON-EXISTENCE as a valid state". I think that is the 
fundamental mistake people make - they think the "quirk" is that isset() 
returns false for a null value, when that is the most rational part of 
it. The "quirk" is that you don't get a warning when passing a 
completely undefined variable to isset().


Obviously, that's not something that's likely to change, but as you say, 
what we are really testing is "the value pointed at by some identifier". 
In an array, that identifier can be dynamic, but in plain variable 
scope, that identifier is something you the programmer have defined long 
before the program executed, so its existence is never in question.


Looked at that way, the handling of unitialised variables is just a 
side-effect of the handling of NULLs, since all unitialised variables 
have a default/implicit value of NULL.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] openssl_seal new param

[Jakub Zelenka]

Hi Scott,

On Mon, Aug 31, 2015 at 10:56 PM, Scott Arciszewski 
wrote:
>
>
> At the risk of sounding silly, can we just use random_bytes()? :)
>
>
This is about internal calls in OpenSSL so we would have to register our
RAND methods. That can be however problematic with potential using of
engine API.


> Additionally, I'd like to (for example) be able to use ChaCha20
> instead of RC4. Is that what the (currently undocumented) $method
> parameter is for?
>
>
The $method param is for setting a cipher algorithm (the same name that you
can pass to openssl_encrypt for example). Only the algorithms returned
from openssl_get_cipher_methods() can be used though - atm only the ones
with empty IV...

Cheers

Jakub

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Xinchen Hui]

Hey:

On Tue, Sep 1, 2015 at 2:51 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> I agree that at first it will feel a little bit weird, especially
>> given that PHP in general lacks syntactic sugar (we still don't have a
>> short-hand to initialize stdclass objects). We introduced [] back in
>> 5.4, and largely it has made readability FAR better (despite some
>> people saying it wouldn't at the time).
>
> That doesn't mean now we have to drop all keywords and switch to
> write-only style. Even [] was somewhat controversial, though it is the
> most elementary syntax construct. Function call is in no way elementary
> - it has non-trivial structure, and obscuring this structure by removing
> keywords does not help readability.
>
>> tool isn't always appropriate in all situations. You can craft code
>> that makes this new syntax look unreadable. But you can craft code
>
> The problem is not that I can. The problem is that anybody can, and a
> lot of people would, unwittingly, once the expressions get more complex
> that $x+1.
>
>> that makes this look far more readable.
>>
>> Example:
>>
>> function partial(callable $cb) {
>> return function($left) use ($cb) {
>> return function($right) use ($cb, $left) {
>> return $cb($left, $right);
>> };
>> };
>> }
>
> It is a bit verbose but pretty clear what's going on here - function
> returns a function that returns a function, and you can easily track
> which variable goes where and how it gets to the end.
>
>>
>> vs:
>>
>> function partial(callable $cb) {
>> return $left ~> $right ~> $cb($left, $right);
>> }
>
> It looks very pretty as the ASCII art, and no entry-level programmer
> would have any idea at all what these arrows actually do and how this
> thing is supposed to work. At least not without studying the manual very
> closely for extended time. That's exactly the problem. People start
> writing overly clever code that looks so pretty - and then other people
> are left scratching their heads about what actually is happening there.
> That's what I mean by write-only code.
>
>> It may look weird at first, but consider that's because you're not
>> used to the syntax. To me, the top is far harder to follow because of
>
> Of course, with enough training you can get fluent even in APL. I know
> people that are. But PHP is supposed to be on the other end of the
> spectrum.
>
>> the shear number of tokens to follow, not to mention that I need to
>> pay attention to the use-blocks which may or may not be importing
>> certain variables. The bottom reads exactly how I would expect it to.
>
> That's because you wrote it and know in advance what it is supposed to
> do. It's not a good test of readability.

+1, that is what readable(guessable) means.

thanks
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Ferenc Kovacs]

On Tue, Sep 1, 2015 at 9:36 AM, Yasuo Ohgaki  wrote:

> Hi Anthony and Bob,
>
> On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara 
> wrote:
> > Most programming languages today have a "short form" closure or lambda
> syntax
> >
> > HackLang: ($x) ==> $x + 1;
> > C++: [](int x) -> int { return x + 1; }
> > Java: (int x) -> x + 1;
> > Python: lambda x: x+1
> > Ruby: lambda |x| { x + 1 }
> > Rust: |x| x + 1
> > JavaScript (ES6): x => x + 1
> > C#: x => x + 1
> > Objective C: ^(int x) { return x + 1; }
>
> Nice summary!
> The syntax may look strange at first, but proposed syntax is close enough
> to
> other languages. There will be no barrier for our users in the long run.
>
> I thought scope variables enabled by default is destructive at first,
> but Bob clarify
> they are passed by value. Therefore, it would not be issue.
>
> Bob, is there reason not to use the same syntax as Hack "==>"?
>

https://wiki.php.net/rfc/short_closures#symbol_choice

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Yasuo Ohgaki]

Hi Anthony and Bob,

On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara  wrote:
> Most programming languages today have a "short form" closure or lambda syntax
>
> HackLang: ($x) ==> $x + 1;
> C++: [](int x) -> int { return x + 1; }
> Java: (int x) -> x + 1;
> Python: lambda x: x+1
> Ruby: lambda |x| { x + 1 }
> Rust: |x| x + 1
> JavaScript (ES6): x => x + 1
> C#: x => x + 1
> Objective C: ^(int x) { return x + 1; }

Nice summary!
The syntax may look strange at first, but proposed syntax is close enough to
other languages. There will be no barrier for our users in the long run.

I thought scope variables enabled by default is destructive at first,
but Bob clarify
they are passed by value. Therefore, it would not be issue.

Bob, is there reason not to use the same syntax as Hack "==>"?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Stanislav Malyshev]

Hi!

> I agree that at first it will feel a little bit weird, especially
> given that PHP in general lacks syntactic sugar (we still don't have a
> short-hand to initialize stdclass objects). We introduced [] back in
> 5.4, and largely it has made readability FAR better (despite some
> people saying it wouldn't at the time).

That doesn't mean now we have to drop all keywords and switch to
write-only style. Even [] was somewhat controversial, though it is the
most elementary syntax construct. Function call is in no way elementary
- it has non-trivial structure, and obscuring this structure by removing
keywords does not help readability.

> tool isn't always appropriate in all situations. You can craft code
> that makes this new syntax look unreadable. But you can craft code

The problem is not that I can. The problem is that anybody can, and a
lot of people would, unwittingly, once the expressions get more complex
that $x+1.

> that makes this look far more readable.
> 
> Example:
> 
> function partial(callable $cb) {
> return function($left) use ($cb) {
> return function($right) use ($cb, $left) {
> return $cb($left, $right);
> };
> };
> }

It is a bit verbose but pretty clear what's going on here - function
returns a function that returns a function, and you can easily track
which variable goes where and how it gets to the end.

> 
> vs:
> 
> function partial(callable $cb) {
> return $left ~> $right ~> $cb($left, $right);
> }

It looks very pretty as the ASCII art, and no entry-level programmer
would have any idea at all what these arrows actually do and how this
thing is supposed to work. At least not without studying the manual very
closely for extended time. That's exactly the problem. People start
writing overly clever code that looks so pretty - and then other people
are left scratching their heads about what actually is happening there.
That's what I mean by write-only code.

> It may look weird at first, but consider that's because you're not
> used to the syntax. To me, the top is far harder to follow because of

Of course, with enough training you can get fluent even in APL. I know
people that are. But PHP is supposed to be on the other end of the
spectrum.

> the shear number of tokens to follow, not to mention that I need to
> pay attention to the use-blocks which may or may not be importing
> certain variables. The bottom reads exactly how I would expect it to.

That's because you wrote it and know in advance what it is supposed to
do. It's not a good test of readability.
-- 
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] [Discussion] Short Closures

[Ferenc Kovacs]

2015. aug. 31. 21:29 ezt írta ("Bob Weinand" ):
>
> I had this RFC in draft since some time, but delayed it due to all the
ongoing PHP 7 discussions. Also we have no master branch to merge features
in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to
be the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

+1 for having short closure operator, -1 for autocopying everything from
the current scope.

[PHP-DEV] Heads up: merging security patches to 7

[Stanislav Malyshev]

Hi!

I've recently committed a number of fixes to 5.x branch. These fixes
mainly concern (un)serialization scenarios, you can see the full list in
5.4/5.5 NEWS. These changes are not merged yet to master/7.0 since due
to extensive differences between 5.x and 7 in zval handling, they
basically must be rewritten for 7. I don't want to commit completely
broken code to master, so I'll work on at least getting it to a state
where there is no new breakage and then porting the fixes properly to 7,
but that can take a couple of days. In the meantime, please be aware
that 5.x and master may not be in full sync and exercise caution if you
merge stuff from 5 to 7.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Heads up: merging security patches to 7

[Yasuo Ohgaki]

Hi Stas,

There are many fixes regarding unserialize.
We also had many fixes regarding type mismatches.
I suppose many 3rd party modules have same issues.

How about have a doc for secure PHP internal coding?

--
Yasuo Ohgaki
yohg...@ohgaki.net


On Wed, Sep 2, 2015 at 5:55 AM, Stanislav Malyshev  wrote:
> Hi!
>
> I've recently committed a number of fixes to 5.x branch. These fixes
> mainly concern (un)serialization scenarios, you can see the full list in
> 5.4/5.5 NEWS. These changes are not merged yet to master/7.0 since due
> to extensive differences between 5.x and 7 in zval handling, they
> basically must be rewritten for 7. I don't want to commit completely
> broken code to master, so I'll work on at least getting it to a state
> where there is no new breakage and then porting the fixes properly to 7,
> but that can take a couple of days. In the meantime, please be aware
> that 5.x and master may not be in full sync and exercise caution if you
> merge stuff from 5 to 7.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Kingsquare.nl - Robin Speekenbrink]

Dear all,

Just to throw in my 2 cents as a userland developer: having multiple
ways to write the same thing isnt always right, but does have
advantages. (i.e. the [] shorthand is gaining alot of popularity as
already noted) (and might even force array() into deprecation imho)

But it does also add clutter since a developer has to have _more_
syntax knowledge in order to read the code. In this case, chaining
alot of short hand closures would require a bit of a learning curve
where the function() syntax is already everywhere... Reading the
functions is more self-explanatory...

But anyway, with regard to the type hints and such: I saw the [draft]
Callable-types RFC ( https://wiki.php.net/rfc/callable-types ) which
before this discussion really sparked my interest of having types
_everywhere_ (yy!) and with this shorthand closure RFC the two
might even get all the FP guys back into PHP ;)

In anycase, Anthony, you might want to have a look at the draft RFC,
since from a userland view, this seems a really good way to go.

Good luck with this development people! Looking forward to whatever
comes out of it!
Met vriendelijke groet,

Robin Speekenbrink
Kingsquare BV


2015-09-01 10:44 GMT+02:00 Anthony Ferrara :
> Pavel
>
> On Tue, Sep 1, 2015 at 4:32 AM, Pavel Kouřil  wrote:
>> On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand  wrote:
>>> I had this RFC in draft since some time, but delayed it due to all the 
>>> ongoing PHP 7 discussions. Also we have no master branch to merge features 
>>> in until 5.4 EOL. Thus I'm reviving this now.
>>>
>>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be 
>>> the next version ;-)):
>>>
>>> The short Closures RFC:
>>> https://wiki.php.net/rfc/short_closures
>>>
>>> Hoping for constructive feedback,
>>> Bob
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>> Hi,
>>
>> as a purely userland developer, I would definitely appreciate the
>> shorthand function for anonymous functions; having tons of stuff like
>> "function ($x) { return $x * 2; }"  makes the code less readable in
>> the end.
>>
>> I'm not sure about the "auto using" of all variables though; wouldnt
>> it be possible to statically check for the used variables and only
>> import what's needed, for performance reasons?
>
> That's precisely what's happening. Not all variables are bound, only
> those that are used. Somehow somewhere in this thread the confusion
> was implied that the entire scope is copied.
>
>> Also, how hard would it be to add type hints (only for parameters)?
>> Sometimes they are needed to make the IDE know the variable type
>> because it can't be guessed automatically. I know about your note in
>> RFC,this is just a question to other internal members.Return type can
>> be infered by IDEs from the simple expresion quite easily.
>>
>> PS: would "() ~> foo()" work? I think it should, but I couldn't find a
>> mention about it in RFC. :)
>
> Typing on closures is outside the scope of this RFC.
>
> With that said, I'd love to hear and see examples of this. It's
> something I definitely want to do, just haven't come up with a good
> enough way to do it...
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Tue, Sep 1, 2015 at 10:45 AM, Tony Marston  wrote:
>
> This argument is irrelevant for several reasons:
> (1) I am not familiar with any of those languages, nor are many PHP users.
> (2) Just because other languages have such a feature is not a good reason
> for adding it into PHP.
> (3) Introducing write-only (less readable or completely unreadable) code
> will ALWAYS be a barrier to those who have used nothing but PHP for the last
> 10+ years.
>
> As H. Abelson and G. Sussman wrote in 1984: "Programs must be written for
> people to read, and only incidentally for machines to execute." Writing
> compact code which has several functions compressed into a single line may
> be clever where you come from, but it leaves new readers scratching their
> heads saying "WTF!!".
>
> As a follower of the KISS principle I always aim to write simple, readable
> code, and my critics always say "It is too simple. Proper OO is supposed to
> be more complex than that".  The mark of genius is to achieve complex things
> in a simple manner, not to achieve simple things in a complex manner.
>

The thing is, every feature and syntax can be used to create some
unreadable "monstrosity". And often, at the same time, they can be
used to create readable elegant code. :)

Sure, "elegant" and "readable" is subjective, and for someone who
never heard of FP, this might be befuddling. But so is probably the
entire concept of anonymous functions and high order functions. Does
it mean PHP shouldn't support passing functions to functions at all? I
think not.

Also, once you know ~> is a syntax sugar for anonymous functions (and
understand them), I don't think there's any general readability
problem, and in some cases, it makes the code even more readable
(subjective experience from other languages). And if the programmer
doesn't understand the concept of anonymous functions at all, he will
be lost anyways and shorter or longer syntax doesn't matter.

I personally wouldn't even mind just having a version that supports
[variables] ~> [single expression], but since other languages support
having whole function body with return statement, I think it's worth
considering adding it too.

Regards
Pavel Kouril

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Scott Arciszewski]

On Tue, Sep 1, 2015 at 5:29 AM, Craig Francis  wrote:
> Hi Rowan, Ryan, James, Bishop, Stas, Lester,
>
> I've been giving this some thought over the weekend, and I agree with what 
> you are all saying, but I think there is an element of confusion in the PHP 
> programming community that needs to be addressed (somehow).
>
> Yes, we probably should not be giving special meaning to NULL, as James 
> mentions (although I probably still will).
>
> And to be fair, I still can't think of an example where isset() can be used 
> on a standard variable. All my examples are really array based, and better 
> addressed with array_key_exists() - where Rowan does a great job of 
> explaining the different examples on stackoverflow:
>
>   http://stackoverflow.com/a/18646568/2908724
>
> Trying to get to route of the confusion though, I think it might be down to 
> how the code can be read. So if we take:
>
>$a = 1;
>   $b = NULL;
>   var_dump($a);
>   var_dump($b);
>   var_dump($c);
>   var_dump(isset($a));
>   var_dump(isset($b));
>   var_dump(isset($c));
> ?>
>
> Or using an array instead:
>
>$v['a'] = 1;
>   $v['b'] = NULL;
>   var_dump($v['a']);
>   var_dump($v['b']);
>   var_dump($v['c']);
>   var_dump(isset($v['a']));
>   var_dump(isset($v['b']));
>   var_dump(isset($v['c']));
> ?>
>
> In both cases (and ignoring the undefined variable error), we get:
>
>   int(1)
>   NULL
>   NULL
>
>   bool(true)
>   bool(false)
>   bool(false)
>
> But if we ignore the manual for a minute:
>
>   http://php.net/isset
>
> I think a good comparison to what that code reads as, vs what PHP does, can 
> be summarised as:
>
>   Read as: The variable is set (exists).
>
>   Executed as: The variables *value* is set.
>
> Where NULL is not considered a set value.
>
> So when we have:
>
>   if (isset($v['a'])) {
>   }
>
> It's not saying that the key 'a' is set (exists) on the array $v.
>
> Instead its saying that the key 'a' has a set value (not NULL) on the array 
> $v.
>
> Where this is made more of a common problem because there are many array_* 
> functions, and they rarely come to mind when your not thinking of an array 
> like operation.
>
> This situation might be improved by re-wording the manual a bit.
>
> Having headings like "This also work[s] for elements in arrays", makes it 
> sound all inclusive and *the* function to use.
>
> Whereas I'm starting to get the feeling that isset() is actually a function 
> that probably should be avoided (I'll skip this tangent for now).
>
> Personally I still like the idea of an exists(), because I feel that is how 
> many programmers treat and use the isset() function - simply because they do 
> use NULL as a valid value, and either haven't read the manual, or forget the 
> exception that is mentioned on line 1 (something I've done a couple of times).
>
> Although I realise it will take many years before anyone can start using it.
>
> Craig
>
>
>
>
>
>
>
>
> On 26 Aug 2015, at 19:44, Rowan Collins  wrote:
>
>> Craig Francis wrote on 26/08/2015 18:07:
>>> I provide examples to help explain that I (and I suspect most developers) 
>>> default to using isset which works on either.
>>>
>>> Just because there is a function, which does not exactly roll off the 
>>> tongue (plus the fun of the needle/haystack ordering issue), does not mean 
>>> it gets used (even if it is the correct thing to use).
>>
>>
>> That's all very well, but what is the Internals community supposed to do 
>> about it? Does the documentation need to be improved to point out that there 
>> is a better function to use for this case?
>>
>>> I say "or key" because developers use the isset function on both $var and 
>>> $var['key']... yes, I know they are different, but when you are coding in 
>>> PHP an isset check is an isset check (well it isn't, because the variable 
>>> may technically exist).
>>>
>>> If this is a problem, maybe PHP should raise a notice when isset is used on 
>>> arrays?
>>
>>
>> It's only a problem in the same way that using file_exists() is a problem 
>> when you actually wanted the functionality of is_readable() - both functions 
>> exist, and it's not the language's responsibility to guess which you meant.
>>
>>
>>
> where NULL may be a perfectly valid value.
 It's not that NULL isn't a valid value; it's that "doesn't exist" isn't a 
 meaningful state for a variable. It's like checking if the current line 
 number is greater than 100, it shouldn't mean anything to the compiled 
 program. See the SO answer I linked earlier for more thought experiments 
 along these lines.
>>>
>>> I think you have been spending too much time in C.
>>>
>>> Most of the PHP code bases I've worked on set variables to NULL at some 
>>> point (and they are not calling unset, because that isn't the intention).
>>
>>
>> Perhaps my double negative made it unclear, so I will restate: there is 
>> nothing wrong with setting a variable to NULL. There is 

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Lester Caine]

On 01/09/15 07:51, Stanislav Malyshev wrote:
>> function partial(callable $cb) {
>> > return $left ~> $right ~> $cb($left, $right);
>> > }
> It looks very pretty as the ASCII art, and no entry-level programmer
> would have any idea at all what these arrows actually do and how this
> thing is supposed to work.

Only entry level programmers?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Tony Marston]

"Yasuo Ohgaki"  wrote in message 
news:caga2bxzpud0j86d-vlsc+fukhzrjk_3qu_5afkg0bm+de7x...@mail.gmail.com...


Hi Anthony and Bob,

On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara  
wrote:
Most programming languages today have a "short form" closure or lambda 
syntax


HackLang: ($x) ==> $x + 1;
C++: [](int x) -> int { return x + 1; }
Java: (int x) -> x + 1;
Python: lambda x: x+1
Ruby: lambda |x| { x + 1 }
Rust: |x| x + 1
JavaScript (ES6): x => x + 1
C#: x => x + 1
Objective C: ^(int x) { return x + 1; }


Nice summary!
The syntax may look strange at first, but proposed syntax is close enough 
to

other languages. There will be no barrier for our users in the long run.


This argument is irrelevant for several reasons:
(1) I am not familiar with any of those languages, nor are many PHP users.
(2) Just because other languages have such a feature is not a good reason 
for adding it into PHP.
(3) Introducing write-only (less readable or completely unreadable) code 
will ALWAYS be a barrier to those who have used nothing but PHP for the last 
10+ years.


As H. Abelson and G. Sussman wrote in 1984: "Programs must be written for 
people to read, and only incidentally for machines to execute." Writing 
compact code which has several functions compressed into a single line may 
be clever where you come from, but it leaves new readers scratching their 
heads saying "WTF!!".


As a follower of the KISS principle I always aim to write simple, readable 
code, and my critics always say "It is too simple. Proper OO is supposed to 
be more complex than that".  The mark of genius is to achieve complex things 
in a simple manner, not to achieve simple things in a complex manner.


--
Tony Marston



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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Lester Caine]

On 01/09/15 10:29, Craig Francis wrote:
> Personally I still like the idea of an exists(), because I feel that is how 
> many programmers treat and use the isset() function - simply because they do 
> use NULL as a valid value, and either haven't read the manual, or forget the 
> exception that is mentioned on line 1 (something I've done a couple of times).
> 
> Although I realise it will take many years before anyone can start using it.

For those of us starting from a base of SQL data, NULL has always been
'not set' and so a binary field can have three values 'yes', 'no' and
'don't know' so when that data is transferred into PHP it has always
been natural to maintain that distinction so NULL === not set.

That this data exists in an array in PHP is a natural development, but
the object orientated/class approach would be that the data is loaded
into an object and the values in that object are no longer considered as
array elements, but discrete variables with all the overheads of getters
and setters, so an 'isset' to check if the value HAS been converted from
NULL to a live value is what is NOW the preferred style of working?
While the older style of working would simply directly read the elements
of the array?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Tue, Sep 1, 2015 at 10:44 AM, Anthony Ferrara  wrote:
>> I'm not sure about the "auto using" of all variables though; wouldnt
>> it be possible to statically check for the used variables and only
>> import what's needed, for performance reasons?
>
> That's precisely what's happening. Not all variables are bound, only
> those that are used. Somehow somewhere in this thread the confusion
> was implied that the entire scope is copied.
>

Oh, nice - thanks for explaining that. :)

>> Also, how hard would it be to add type hints (only for parameters)?
>> Sometimes they are needed to make the IDE know the variable type
>> because it can't be guessed automatically. I know about your note in
>> RFC,this is just a question to other internal members.Return type can
>> be infered by IDEs from the simple expresion quite easily.
>>
>> PS: would "() ~> foo()" work? I think it should, but I couldn't find a
>> mention about it in RFC. :)
>
> Typing on closures is outside the scope of this RFC.
>
> With that said, I'd love to hear and see examples of this. It's
> something I definitely want to do, just haven't come up with a good
> enough way to do it...
>

Yeah, I know it's outside of the scope of the RFC, it was more of a
general question whether or not it would be possible in the future.
Also, exactly what examples would you want to see?

Pavel

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

[PHP-DEV] Requesting RFC karma for wiki account

[AllenJB]

Wiki account: allenjb

I wish to submit an RFC for my notice on array-access on non-arrays pull 
request.


Draft RFC: https://gist.github.com/AllenJB/793d54a86ac182ef61f5
PR: https://github.com/php/php-src/pull/1269

Thanks in advance,

AllenJB

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Craig Francis]

Hi Rowan, Ryan, James, Bishop, Stas, Lester,

I've been giving this some thought over the weekend, and I agree with what you 
are all saying, but I think there is an element of confusion in the PHP 
programming community that needs to be addressed (somehow).

Yes, we probably should not be giving special meaning to NULL, as James 
mentions (although I probably still will).

And to be fair, I still can't think of an example where isset() can be used on 
a standard variable. All my examples are really array based, and better 
addressed with array_key_exists() - where Rowan does a great job of explaining 
the different examples on stackoverflow:

  http://stackoverflow.com/a/18646568/2908724

Trying to get to route of the confusion though, I think it might be down to how 
the code can be read. So if we take:



Or using an array instead:



In both cases (and ignoring the undefined variable error), we get:

  int(1)
  NULL
  NULL

  bool(true)
  bool(false)
  bool(false)

But if we ignore the manual for a minute:

  http://php.net/isset

I think a good comparison to what that code reads as, vs what PHP does, can be 
summarised as:

  Read as: The variable is set (exists).

  Executed as: The variables *value* is set.

Where NULL is not considered a set value.

So when we have:

  if (isset($v['a'])) {
  }

It's not saying that the key 'a' is set (exists) on the array $v.

Instead its saying that the key 'a' has a set value (not NULL) on the array $v.

Where this is made more of a common problem because there are many array_* 
functions, and they rarely come to mind when your not thinking of an array like 
operation.

This situation might be improved by re-wording the manual a bit.

Having headings like "This also work[s] for elements in arrays", makes it sound 
all inclusive and *the* function to use.

Whereas I'm starting to get the feeling that isset() is actually a function 
that probably should be avoided (I'll skip this tangent for now).

Personally I still like the idea of an exists(), because I feel that is how 
many programmers treat and use the isset() function - simply because they do 
use NULL as a valid value, and either haven't read the manual, or forget the 
exception that is mentioned on line 1 (something I've done a couple of times).

Although I realise it will take many years before anyone can start using it.

Craig








On 26 Aug 2015, at 19:44, Rowan Collins  wrote:

> Craig Francis wrote on 26/08/2015 18:07:
>> I provide examples to help explain that I (and I suspect most developers) 
>> default to using isset which works on either.
>> 
>> Just because there is a function, which does not exactly roll off the tongue 
>> (plus the fun of the needle/haystack ordering issue), does not mean it gets 
>> used (even if it is the correct thing to use).
> 
> 
> That's all very well, but what is the Internals community supposed to do 
> about it? Does the documentation need to be improved to point out that there 
> is a better function to use for this case?
> 
>> I say "or key" because developers use the isset function on both $var and 
>> $var['key']... yes, I know they are different, but when you are coding in 
>> PHP an isset check is an isset check (well it isn't, because the variable 
>> may technically exist).
>> 
>> If this is a problem, maybe PHP should raise a notice when isset is used on 
>> arrays?
> 
> 
> It's only a problem in the same way that using file_exists() is a problem 
> when you actually wanted the functionality of is_readable() - both functions 
> exist, and it's not the language's responsibility to guess which you meant.
> 
> 
> 
 where NULL may be a perfectly valid value.
>>> It's not that NULL isn't a valid value; it's that "doesn't exist" isn't a 
>>> meaningful state for a variable. It's like checking if the current line 
>>> number is greater than 100, it shouldn't mean anything to the compiled 
>>> program. See the SO answer I linked earlier for more thought experiments 
>>> along these lines.
>> 
>> I think you have been spending too much time in C.
>> 
>> Most of the PHP code bases I've worked on set variables to NULL at some 
>> point (and they are not calling unset, because that isn't the intention).
> 
> 
> Perhaps my double negative made it unclear, so I will restate: there is 
> nothing wrong with setting a variable to NULL. There is also nothing wrong 
> with calling unset() on a plain variable, e.g. to make it obvious to readers 
> of the code that this variable should not be used below this point.
> 
> There IS something wrong with any code which needs to distinguish which of 
> those two things happened, at run-time, because such code would be incredibly 
> fragile and hard to follow.
> 
> You could, if you wanted, emulate a boolean variable by using $foo=null for 
> true, and unset($foo) for false, but why not simply have a boolean variable?
> 
> [Incidentally, I know barely any C, but program PHP for a living.]
> 
> Regards,

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Derick Rethans]

On Mon, 31 Aug 2015, Bob Weinand wrote:

> I had this RFC in draft since some time, but delayed it due to all the 
> ongoing PHP 7 discussions. Also we have no master branch to merge features in 
> until 5.4 EOL. Thus I'm reviving this now.
> 
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be 
> the next version ;-)):
> 
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures

The RFC writes:

> The symbol ~> was chosen as it is a mnemonic device to help 
> programmers understand that the variable is being brought to a 
> function.

I don't see how this is a mnemonic. I am also struggeling seeing the 
difference between -> and ~> in certain fonts.

> Currently Hack has implemented shorthand anonymous functions using the 
> ==> symbol to define them.

> Additionally, ==> in Hack has slightly different semantics, hence we 
> decided, it's better to not reuse that symbol

What are the difference in semantics?
Why not just copy the Hack semantics (and hence, then also use it's symbol)?

cheers,
Derick

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand  wrote:
> I had this RFC in draft since some time, but delayed it due to all the 
> ongoing PHP 7 discussions. Also we have no master branch to merge features in 
> until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be 
> the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi,

as a purely userland developer, I would definitely appreciate the
shorthand function for anonymous functions; having tons of stuff like
"function ($x) { return $x * 2; }"  makes the code less readable in
the end.

I'm not sure about the "auto using" of all variables though; wouldnt
it be possible to statically check for the used variables and only
import what's needed, for performance reasons?

Also, how hard would it be to add type hints (only for parameters)?
Sometimes they are needed to make the IDE know the variable type
because it can't be guessed automatically. I know about your note in
RFC,this is just a question to other internal members.Return type can
be infered by IDEs from the simple expresion quite easily.

PS: would "() ~> foo()" work? I think it should, but I couldn't find a
mention about it in RFC. :)

Regards
Pavel Kouril

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

Re: [PHP-DEV] Generic classes and methods RFC

[Pavel Kouřil]

On Mon, Aug 31, 2015 at 10:31 PM, Ben Scholzen 'DASPRiD'
 wrote:
> Hello,
>
> I've written up an RFC for supporting generic classes and methods in PHP,
> and I'd love to hear your thoughts about it.
>
> https://wiki.php.net/rfc/generics
>
> Cheers,
> --
> Ben Scholzen 'DASPRiD'
> Community Review Team Member | m...@dasprids.de
> Zend Framework   | http://www.dasprids.de
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

I would love to see generics in PHP, but I have a few questions for your RFC.

class Bazz

Why did you use this syntax for forcing extending/implementation? I
know this is the syntax C# uses, but it doesn't fit PHP. I think it
should be "extends" or "implements", because in PHP : has a different
meaning.

Also, how do you specify multiple constraints?

Do you have any idea how it would work internally and if there was
some performance hit while using generics, and if it would also slow
down existing apps that don't use generics?

I hope this RFC will have positive comments, and someone who is
capable of writing C will help you out with it so there's a patch for
people to review - because I'm not sure if this RFC can get anywhere
without a patch. :(

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Anthony Ferrara]

Pavel

On Tue, Sep 1, 2015 at 4:32 AM, Pavel Kouřil  wrote:
> On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand  wrote:
>> I had this RFC in draft since some time, but delayed it due to all the 
>> ongoing PHP 7 discussions. Also we have no master branch to merge features 
>> in until 5.4 EOL. Thus I'm reviving this now.
>>
>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be 
>> the next version ;-)):
>>
>> The short Closures RFC:
>> https://wiki.php.net/rfc/short_closures
>>
>> Hoping for constructive feedback,
>> Bob
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> Hi,
>
> as a purely userland developer, I would definitely appreciate the
> shorthand function for anonymous functions; having tons of stuff like
> "function ($x) { return $x * 2; }"  makes the code less readable in
> the end.
>
> I'm not sure about the "auto using" of all variables though; wouldnt
> it be possible to statically check for the used variables and only
> import what's needed, for performance reasons?

That's precisely what's happening. Not all variables are bound, only
those that are used. Somehow somewhere in this thread the confusion
was implied that the entire scope is copied.

> Also, how hard would it be to add type hints (only for parameters)?
> Sometimes they are needed to make the IDE know the variable type
> because it can't be guessed automatically. I know about your note in
> RFC,this is just a question to other internal members.Return type can
> be infered by IDEs from the simple expresion quite easily.
>
> PS: would "() ~> foo()" work? I think it should, but I couldn't find a
> mention about it in RFC. :)

Typing on closures is outside the scope of this RFC.

With that said, I'd love to hear and see examples of this. It's
something I definitely want to do, just haven't come up with a good
enough way to do it...

Anthony

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

RE: [PHP-DEV] [RFC] [Discussion] Short Closures

[Thomas Punt]

Hi Bob,

> I had this RFC in draft since some time, but delayed it due to all the 
> ongoing PHP 7 discussions. Also we have no master branch to merge features in 
> until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be 
> the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob

Whilst I'd like to see a more expressive syntax for closures (and many other
things) in PHP, I'm personally -1 on your proposal. The feature feels too
inconsistent with the syntax and semantics of current PHP constructs for the
following reasons:
1) The automatic binding of variables from the outer scope to the inner scope.
2) The optional use of parentheses for parameter definitions, but only when a
single argument is used.
3) The optional use of braces for the function body, but only when a single
expression is used.
4) The automatic returning of the expression, but only when it is alone, and
only if the braces are omitted.

These four differences create further special cases for people to learn and
have no precedence in the language at all. They seem more like Rubyisms than
PHPisms.

Whilst we're on the topic of a terser syntax for closures though, Elixir has an
even shorter syntax:
&(&1 + &2)

The &() denotes an closure definition; the  is used to create placeholders,
where N corresponds to the argument number. The ampersand obviously cannot be
reused for this in PHP, but the dollar sign could:
$func = $($1 + $2);
var_dump($func(3, 4)); // int(7)

This syntax should only be used in trivial scenarios, though, and comes with
the disadvantage of no type information.

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

[PHP-DEV] Add HTTP/2 Multiplexing-related constants to ext/curl

[Davey Shafik]

Hi,

I've been poking around at HTTP/2 a lot lately, and it seems that so long
as you are using libcurl 7.43.0+ it's possible to do request multiplexing.

This change simply introduces three constants, CURLPIPE_NOTHING (0),
CURLPIPE_HTTP1 (1), and CURLPIPE_MULTIPLEX (2) which represent possible
values passed into curl_multi_setopt() for the CURLMOPT_PIPELINING option.
Current behavior of passing in 0 and 1 map to the first two constants,
while the third allows for multiplexing.

Now, of course, being constants, you can just pass in 0, 1, or 2, but this
brings the consistency and explicitness of exposing them as with all the
other curl constants.

I'd love to see this make it into PHP 7.0 if it's not too late? It's
extremely trivial, but whatever — not that fussed :)

PR is here: https://github.com/php/php-src/pull/1497

I'm not sure if there is some way to ensure that libcurl is compiled with
nghttp, but we don't check for the other HTTP/2 stuff so either it's done
elsewhere and I missed it, or we're making assumptions that the right
version is enough. Any input on this would be good.

FTR, multiplexing can bring substantial performance improvements,
especially when factoring in SSL:

379 HTTP SSL requests

Using HTTP/2 in serial: 63.293796062469 (HTTP/1.1 in serial should be even
slower)
Using HTTP/1.1 with curl_multi: 12.383034944534
Using HTTP/2 w/multiplexing: 2.7933928966522

Thanks,

- Davey

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Rowan Collins]

Anthony Ferrara wrote on 01/09/2015 06:53:

function partial(callable $cb) {
 return $left ~> $right ~> $cb($left, $right);
}


The thing that is most unreadable to me in this is the associativity. 
Someone from, say, a Haskell background might be used to mentally 
grouping X -> Y -> Z into a series of steps but to an untrained eye it 
looks almost like there's a list of terms with ~> as the separator. As I 
understand it, an expanded form would be:


return ($left) ~> { return ($right) ~> { return $cb($left, $right) } };

...which is a bit easier to mentally group, but not much prettier than 
current PHP syntax.


What about something a bit more "enclosed" but still short. A 
for-loop-style construct occured to me:


# lambda(params; expression)
lambda($a, $b; $a * $b)
lambda($x; { while(foo()) { $x ++; } return $x; })

The curly braces don't look very natural in that last example, but I'm 
not sure what else to use. Maybe just use the existing function() syntax 
if you want a block rather than an expression?


A nice expansion of this would be to have an explicit use clause without 
any extra keywords:


# lambda(params; bound vars; expression)
$double = lambda($a;; 2*$a)
$x=3; $triple = lambda($a; $x; $x * $a)

Taking one of the RFC's examples:

function sumEventScores($events, $scores) {
$types = array_map(lambda($event;; $event['type']), $events);
return array_reduce($types, lambda($sum, $type; $scores; $sum + 
$scores[$type]));

}


The next example benefits less if we allow only expressions, but you 
could still write this:


function reduce(callable $fn) {
return lambda($initial; $fn;
function($input) use ($fn, $initial) {
$accumulator = $initial;
foreach ($input as $value) {
$accumulator = $fn($accumulator, $value);
}
return $accumulator;
}
);
}


I'll leave it to others to judge if this is better or worse than the 
current proposal, just playing with ideas...


Regards,
Rowan Collins
--
[IMSoP]

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