Re: [PHP-DEV] List comprehensions and generator expressions for PHP
On 28/06/12 23:45, Sebastian Krebs wrote: > Hi, > > 2012/6/28 David Muir > >> I'd assume that array_map() only works with arrays, while list >> comprehension should work with anything traversable. >> > That sounds more like a "bug" (better: "Missing feature") in array_map() > and less a missing language feature... All the array_* functions only work with arrays, and don't allow objects, even ones implementing ArrayAccess. It's been there as a feature request since 2007: https://bugs.php.net/bug.php?id=43650 Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re:[PHP-DEV] List comprehensions and generator expressions for PHP
On 29/06/12 14:06, minwei zhou wrote: > On Thu, Jun 28, 2012 at 6:48 PM, Nikita Popov wrote: >> Hi internals! >> >> Python and several other languages include support for list >> comprehensions and generator expressions and I'd like to see something > why PHP should going to like other language? Pretty much everything in PHP was "borrowed" from another language. This is nothing new. >> So, what do you think? Do we want something like this in PHP? > NO!!! > > PHP is not python please do not make PHP worse > > if you like python just go to use python > Try again, this time with less knee-jerk and more brain: Why is this a bad feature? How will it make PHP worse? What is so bad about it that it outweigh the benefits? Is it the syntax you don't like, or the concept? Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re:[PHP-DEV] List comprehensions and generator expressions for PHP
On Thu, Jun 28, 2012 at 6:48 PM, Nikita Popov wrote:
> Hi internals!
>
> Python and several other languages include support for list
> comprehensions and generator expressions and I'd like to see something
why PHP should going to like other language?
> similar in PHP too.
>
> I created a hacky proof of concept implementation here:
> https://github.com/nikic/php-src/tree/addListComprehensions. It's
> really dirty, but it implements both features in about ~150 lines of
> code.
>
> Currently I'm using the following syntax:
>
>$firstNames = [foreach ($users as $user) yield $user->firstName];
>
> This code is roughly equivalent to writing:
>
>$firstNames = [];
>foreach ($users as $user) {
>$firstNames[] = $user->firstName;
>}
>
> You may notice that this particular list comprehension provides the
> same functionality as array_column(), just in a little more
> generalized way. E.g. you could use all of the following without
> having special functions for them all:
>
>$firstNames = [foreach ($users as $user) yield $user->firstName];
>
>$firstNames = [foreach ($users as $user) yield $user->getFirstName()];
>
>$firstNames = [foreach ($users as $user) yield $user['firstName']];
>
> It's also possible to explicitly specify a key:
>
>$firstNames = [foreach ($users as $user) yield $user->id =>
> $user->firstName];
>
> It is also possible to filter elements using list comprehensions:
>
>$underageUsers = [foreach ($users as $user) if ($user->age < 18)
> yield $user];
>// or just the names
>$underageUserNames = [foreach ($users as $user) if ($user->age <
> 18) yield $user->firstName];
>
> It is also possible to nest multiple foreach loops:
>
>$aList = ['A', 'B'];
>$bList = [1, 2];
>$combinations = [foreach ($aList as $a) foreach ($bList as $b)
> yield [$a, $b]];
>// gives: [ ['A', 1], ['A', 2], ['B', 1], ['B', 2] ]
>
> All the above are list comprehensions (or in PHP rather array
> comprehensions), i.e. they create an array as the result.
>
> If this is not needed it is also possible to compute the values lazily
> using generator expressions, which use () instead of [].
>
>$firstNames = (foreach ($users as $user) yield $user->firstName);
>
> In this case $firstNames will no longer be an array of first names,
> but instead will be a generator producing first names.
>
> This is handy if you only need to iterate the resulting "list" only
> once as it saves you holding the whole list in memory.
>
> Also it allows you to work with infinite lists easily:
>
>function *naturalNumbers() {
>for ($i = 0; ; ++$i) {
>yield $i;
>}
>}
>
>// all natural numbers
>$numbers = naturalNumbers();
>// only the odd ones
>$oddNumbers = (foreach ($numbers as $n) if ($n % 2) yield $n);
>// ...
>
> (At this point I wonder whether one should include support for
> for-loops in list comprehensions. So the naturalNumbers() function
> could be replaced with (for ($i = 0;; ++$i) yield $i), etc)
>
> So, what do you think? Do we want something like this in PHP?
NO!!!
PHP is not python please do not make PHP worse
if you like python just go to use python
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Johannes,
> I haven't looked at your patch. But if it has to call another
> PHP_FuNCTION then it's not good. crypt implementation should be
> accessible via C.
I've refactored crypt() slightly to expose a PHP_API crypt_execute()
function that does just about everything except the argument parsing /
default randomizing.
https://github.com/ircmaxell/php-src/blob/hash_password/ext/standard/crypt.c
Now that I did that, I adjusted the implementation to call that instead...
>> I don't like the concept of core functions disappearing if they are
>> not implemented. I think that does nothing but make it harder on the
>> developers (now having to inject a function_exists(), etc).
>
> I think it's rather the opposite. In that case the user has no way to
> check whether the function is there without calling it and reacting to
> errors. If the function "disappears" there is a possibility to check.
I've now based this implementation on HAVE_CRYPT. If that's not
defined, neither are these functions...
>> Additionally, since this is a security issue, I think that always
>> defining the function is the better approach. Otherwise, you can wind
>> up in a situation where someone else comes in and implements function
>> password_verify($password, $hash) { return true; }, which would be all
>> sorts of bad... I can see the static linking to the function (instead
>> of the dynamic call that's there), So in this case, I personally think
>> the warning is appropriate.
>
> No, but a simple zend_parse_parameters with "s" modifier should be
> enough?
Well, that was enough for the main parsing. But I had to do a little
bit of copy/paste for the argument array parsing (not comfortable with
it):
https://github.com/ircmaxell/php-src/blob/hash_password/ext/standard/password.c#L262
> I don't see what makes password_verify special. If one wants a typesafe
> check one can go for true === password_verify.
I've changed all other parameter based error returns to NULL (even the
out of range checks). But I left password_verify for now as returning
false on any error. I still think this one case is significant enough
to always return false/true instead of a third parameter. But we can
talk about that more...
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
On Wed, Jun 27, 2012 at 2:19 PM, Nikita Popov wrote: > I looked at a few other error functions (of which we by the way we > have *loads*, which is a bad sign) and indeed it seems that they all > use a separate function to get the error message. Most use a > xyz_errno() + xyz_error() pair. > > So it seems reasonable to instead provide the functionality via > json_last_error_msg(). I replaced json_last_error(true) with json_last_error_msg() now (in https://github.com/php/php-src/commit/974324676b2436f159f42d9241c569f813471684). I kind of get the feeling that the changes turned out much more intrusive than originally thought. Maybe the best thing to do would be to revert all changes on 5.3/5.4 (including the very original one that landed only on 5.3) and only introduce the new behavior on master. Or do you think that the changes are okay for the release branches? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] List comprehensions and generator expressions for PHP
> No mention of yielding keys in the comprehensions. Presume that would
> work?
Yup, that works too. I also included an example in the mail:
$firstNames = [foreach ($users as $user) yield $user->id =>
$user->firstName];
This creates a map from ids to first names.
> The simplest example I could think of using Memcached
> (assuming libmemcached fetch() does return as soon as it recieves an
> item)
>
> Eg.
>
> function *getMulti(Memcached $memcached, array $keys)
> {
> if ($memcached->getDelayed($keys)) {
> while ($item = $memcached->fetch())
> yield $item['key'] => $item['value'];
> }
> }
>
> foreach(getMulti($memcached, ['foo', 'bar', ... ]) as $key => $value)
> {
> doSomeWork();
> }
>
> So doSomeWork would be called as soon as a single value is available,
> rather
> than having to wait til all values have returned.
>
> Should in theory work right?
Yup, that should work :)
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] List comprehensions and generator expressions for PHP
On Thu, Jun 28, 2012 at 2:43 PM, Sebastian Krebs wrote:
> Hi,
>
> Whats the difference to the (already existing) function array_map() (except
> the syntax and one more new keyword)?
>
>> $firstNames = array_map(function($user){return $user->firstname;},
> $users);
>
> Don't want to rewrite every example you gave, but you probably see my point.
They are roughly the same. List comprehensions are basically a way of
mapping + filtering. Their main advantage is a dedicated, more concise
syntax and also the ability to combine multiple maps and filters in
one expression.
Also PHP is not a particularly lambda-y language in general; using
array_map for that purpose would feel "wrong" to me. I'd probably
rather write out a full foreach loop than use map.
Generator expressions additionally bring the concept of lazy
evaluation into the mix. This is useful in several situations, e.g.
when processing large amounts of data, like log files.
The following Python example is taken from
http://www.dabeaz.com/generators/Generators.pdf:
wwwlog = open("access-log")
bytecolumn = (line.rsplit(None,1)[1] for line in wwwlog)
bytes = (int(x) for x in bytecolumn if x != '-')
print "Total", sum(bytes)
The code is written as a set of simple operations, which are all
defined in terms of iterating a whole file/list. But the actual
execution is lazy, thus basically applying all the operations in a
"pipeline". So the whole potentially multi-gig log file is never
loaded into memory.
The same could be done in PHP, just a different syntax :)
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Feature 55218 - SimpleXML namespaces
Currently, if you recursively call getDocNamespaces on any SimpleXML node it retrieves ALL the namespaces for the entire document, regardless of what node you call it on. This patch adds a second bool argument called `from_root` that allows you to specify if you want all the namespaces from the root (default for BC) or only the namespaces from and below the node you call it on. I submitted this patch a while ago and haven't heard anything. I was recently contacted by someone asking if this feature was released b/c they needed this functionality. I've updated the patch against PHP-5.4 on github (https://github.com/php/php-src/pull/112). Is there some procedure I am missing for getting this committed? Is there some place I should be going for this discussion? I couldn't find an IRC channel that was helpful w/ core php development. Thank you, -- Lonny Kapelushnik http://lonnylot.com (732) 807-5509
Re: [PHP-DEV] Resume keyword
Saying that "the exception handler shouldn't have called resume" in
the case where the exception was originally thrown in a deeper stack
frame sounds good until you consider that this requires exception
handlers to know whether the code preceding them has been refactored
or not, which makes it tough to separate concerns and invites
situations where it is harder than ever to figure out the side effects
of what you're doing. Exception handlers ought to be able to look at
the exception object alone in order to figure out what to do.
On Thu, Jun 21, 2012 at 8:11 AM, Michael Morris wrote:
> On Thu, Jun 21, 2012 at 2:59 AM, Sebastian Krebs
> wrote:
>> 2012/6/20 Michael Morris
>>
>>> [/snip]
>>>
>>> An example for additional clarity.
>>>
>>> set_exception_handler(function ($e) {
>>> echo $e->getMessage();
>>> // Don't know if this is correct - but should be able to illustrate here
>>> if ($e->getCode() == E_NOTICE & E_STRICT) {
>>> resume null;
>>> }
>>>
>>> echo 'Dying now'; exit;
>>> });
>>>
>>> throw new Exception('A test', E_NOTICE);
>>>
>>> echo "We didn't die";
>>>
>>> The code above when run would echo "A test. We didn't die.";
>>>
>>>
>>>
>> Whats about
>>
>> $user = $this->getUser(); // Throws exception
>> echo $user->getName();
>>
>>
>> Now the second one will fail too, but in reality it shouldn't even get
>> executed...
>>
>> Regards,
>> Sebastian
>>
>>
>
> Then the error handler shouldn't have called resume. The error
> handler should only call the keyword if its safe to do so. And now
> that I think about it, not having the ability to return anything would
> be for the best since it would keep the usefulness of this to a
> minimum and avoid magic headaches.
>
> Cause the last thing we need is for people to start using the
> exception handling mechanism as additional control structure tree.
>
> What about what I'd mentioned before that this would allow? With this
> in place the existing PHP Errors could all be converted to Exceptions.
> The default exception handler would resume after catching any low
> level exceptions (E_NOTICE, E_WARNING, etc) but a custom one can be
> free to do whatever.
>
> Unifying the mechanisms also would allow for exceptions for other
> fatal events. This would be highly useful.
>
> try {
> require( 'path/to/file.php' );
> } catch ( PARSE_EXCEPTION $e ) {
> // some logging then pretty death
> }
>
> Most of the time you'd never want to resume after such an
> exception Most of the time.
>
> In any event "resume" would allow PHP to get back to having only one
> exception mechanism instead of two since the behavior of errors could
> be emulated under exceptions. That is the principle boon of resume.
>
> Does that balance the two drawbacks
> 1) It's a new keyword, so BC breaks occur with code that used it as a
> function name.
> 2) The spaghetti possibilities increase.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] List comprehensions and generator expressions for PHP
Hi,
2012/6/28 David Muir
> I'd assume that array_map() only works with arrays, while list
> comprehension should work with anything traversable.
>
That sounds more like a "bug" (better: "Missing feature") in array_map()
and less a missing language feature...
Regards,
Sebastian
>
> David
>
>
> On 28/06/2012, at 10:43 PM, Sebastian Krebs wrote:
>
> > Hi,
> >
> > Whats the difference to the (already existing) function array_map()
> (except
> > the syntax and one more new keyword)?
> >
> >> $firstNames = array_map(function($user){return $user->firstname;},
> > $users);
> >
> > Don't want to rewrite every example you gave, but you probably see my
> point.
> >
> > Regards,
> > Sebastian
> >
> > 2012/6/28 Nikita Popov
> >
> >> Hi internals!
> >>
> >> Python and several other languages include support for list
> >> comprehensions and generator expressions and I'd like to see something
> >> similar in PHP too.
> >>
> >> I created a hacky proof of concept implementation here:
> >> https://github.com/nikic/php-src/tree/addListComprehensions. It's
> >> really dirty, but it implements both features in about ~150 lines of
> >> code.
> >>
> >> Currently I'm using the following syntax:
> >>
> >> $firstNames = [foreach ($users as $user) yield $user->firstName];
> >>
> >> This code is roughly equivalent to writing:
> >>
> >> $firstNames = [];
> >> foreach ($users as $user) {
> >> $firstNames[] = $user->firstName;
> >> }
> >>
> >> You may notice that this particular list comprehension provides the
> >> same functionality as array_column(), just in a little more
> >> generalized way. E.g. you could use all of the following without
> >> having special functions for them all:
> >>
> >> $firstNames = [foreach ($users as $user) yield $user->firstName];
> >>
> >> $firstNames = [foreach ($users as $user) yield $user->getFirstName()];
> >>
> >> $firstNames = [foreach ($users as $user) yield $user['firstName']];
> >>
> >> It's also possible to explicitly specify a key:
> >>
> >> $firstNames = [foreach ($users as $user) yield $user->id =>
> >> $user->firstName];
> >>
> >> It is also possible to filter elements using list comprehensions:
> >>
> >> $underageUsers = [foreach ($users as $user) if ($user->age < 18)
> >> yield $user];
> >> // or just the names
> >> $underageUserNames = [foreach ($users as $user) if ($user->age <
> >> 18) yield $user->firstName];
> >>
> >> It is also possible to nest multiple foreach loops:
> >>
> >> $aList = ['A', 'B'];
> >> $bList = [1, 2];
> >> $combinations = [foreach ($aList as $a) foreach ($bList as $b)
> >> yield [$a, $b]];
> >> // gives: [ ['A', 1], ['A', 2], ['B', 1], ['B', 2] ]
> >>
> >> All the above are list comprehensions (or in PHP rather array
> >> comprehensions), i.e. they create an array as the result.
> >>
> >> If this is not needed it is also possible to compute the values lazily
> >> using generator expressions, which use () instead of [].
> >>
> >> $firstNames = (foreach ($users as $user) yield $user->firstName);
> >>
> >> In this case $firstNames will no longer be an array of first names,
> >> but instead will be a generator producing first names.
> >>
> >> This is handy if you only need to iterate the resulting "list" only
> >> once as it saves you holding the whole list in memory.
> >>
> >> Also it allows you to work with infinite lists easily:
> >>
> >> function *naturalNumbers() {
> >> for ($i = 0; ; ++$i) {
> >> yield $i;
> >> }
> >> }
> >>
> >> // all natural numbers
> >> $numbers = naturalNumbers();
> >> // only the odd ones
> >> $oddNumbers = (foreach ($numbers as $n) if ($n % 2) yield $n);
> >> // ...
> >>
> >> (At this point I wonder whether one should include support for
> >> for-loops in list comprehensions. So the naturalNumbers() function
> >> could be replaced with (for ($i = 0;; ++$i) yield $i), etc)
> >>
> >> So, what do you think? Do we want something like this in PHP?
> >>
> >> Nikita
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
RE: [PHP-DEV] List comprehensions and generator expressions for PHP
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: 28 June 2012 11:49
> To: PHP internals
> Subject: [PHP-DEV] List comprehensions and generator
> expressions for PHP
>
> Hi internals!
>
> Python and several other languages include support for list
> comprehensions and generator expressions and I'd like to see
something
> similar in PHP too.
>
> I created a hacky proof of concept implementation here:
> https://github.com/nikic/php-src/tree/addListComprehensions. It's
> really dirty, but it implements both features in about ~150 lines of
> code.
>
> Currently I'm using the following syntax:
>
> $firstNames = [foreach ($users as $user) yield
$user->firstName];
>
> This code is roughly equivalent to writing:
>
> $firstNames = [];
> foreach ($users as $user) {
> $firstNames[] = $user->firstName;
> }
>
> You may notice that this particular list comprehension provides the
> same functionality as array_column(), just in a little more
> generalized way. E.g. you could use all of the following without
> having special functions for them all:
>
> $firstNames = [foreach ($users as $user) yield
$user->firstName];
>
> $firstNames = [foreach ($users as $user) yield
> $user->getFirstName()];
>
> $firstNames = [foreach ($users as $user) yield
> $user['firstName']];
>
> It's also possible to explicitly specify a key:
>
> $firstNames = [foreach ($users as $user) yield $user->id =>
> $user->firstName];
>
> It is also possible to filter elements using list comprehensions:
>
> $underageUsers = [foreach ($users as $user) if ($user->age < 18)
> yield $user];
> // or just the names
> $underageUserNames = [foreach ($users as $user) if ($user->age <
> 18) yield $user->firstName];
>
> It is also possible to nest multiple foreach loops:
>
> $aList = ['A', 'B'];
> $bList = [1, 2];
> $combinations = [foreach ($aList as $a) foreach ($bList as $b)
> yield [$a, $b]];
> // gives: [ ['A', 1], ['A', 2], ['B', 1], ['B', 2] ]
>
> All the above are list comprehensions (or in PHP rather array
> comprehensions), i.e. they create an array as the result.
>
> If this is not needed it is also possible to compute the values
lazily
> using generator expressions, which use () instead of [].
>
> $firstNames = (foreach ($users as $user) yield
$user->firstName);
>
> In this case $firstNames will no longer be an array of first names,
> but instead will be a generator producing first names.
>
> This is handy if you only need to iterate the resulting "list" only
> once as it saves you holding the whole list in memory.
>
> Also it allows you to work with infinite lists easily:
>
> function *naturalNumbers() {
> for ($i = 0; ; ++$i) {
> yield $i;
> }
> }
>
> // all natural numbers
> $numbers = naturalNumbers();
> // only the odd ones
> $oddNumbers = (foreach ($numbers as $n) if ($n % 2) yield $n);
> // ...
>
> (At this point I wonder whether one should include support for
> for-loops in list comprehensions. So the naturalNumbers() function
> could be replaced with (for ($i = 0;; ++$i) yield $i), etc)
>
> So, what do you think? Do we want something like this in PHP?
No mention of yielding keys in the comprehensions. Presume that would
work?
I would definitely like to see generators in, the amount of
boilerplate
code required for the current Iterator interface is not nice.
Also have been playing with your addGeneratorsSupport branch, trying
to see
If can get any benefits from using asynchronous operations.
The simplest example I could think of using Memcached
(assuming libmemcached fetch() does return as soon as it recieves an
item)
Eg.
function *getMulti(Memcached $memcached, array $keys)
{
if ($memcached->getDelayed($keys)) {
while ($item = $memcached->fetch())
yield $item['key'] => $item['value'];
}
}
foreach(getMulti($memcached, ['foo', 'bar', ... ]) as $key => $value)
{
doSomeWork();
}
So doSomeWork would be called as soon as a single value is available,
rather
than having to wait til all values have returned.
Should in theory work right?
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] List comprehensions and generator expressions for PHP
I'd assume that array_map() only works with arrays, while list comprehension
should work with anything traversable.
David
On 28/06/2012, at 10:43 PM, Sebastian Krebs wrote:
> Hi,
>
> Whats the difference to the (already existing) function array_map() (except
> the syntax and one more new keyword)?
>
>> $firstNames = array_map(function($user){return $user->firstname;},
> $users);
>
> Don't want to rewrite every example you gave, but you probably see my point.
>
> Regards,
> Sebastian
>
> 2012/6/28 Nikita Popov
>
>> Hi internals!
>>
>> Python and several other languages include support for list
>> comprehensions and generator expressions and I'd like to see something
>> similar in PHP too.
>>
>> I created a hacky proof of concept implementation here:
>> https://github.com/nikic/php-src/tree/addListComprehensions. It's
>> really dirty, but it implements both features in about ~150 lines of
>> code.
>>
>> Currently I'm using the following syntax:
>>
>> $firstNames = [foreach ($users as $user) yield $user->firstName];
>>
>> This code is roughly equivalent to writing:
>>
>> $firstNames = [];
>> foreach ($users as $user) {
>> $firstNames[] = $user->firstName;
>> }
>>
>> You may notice that this particular list comprehension provides the
>> same functionality as array_column(), just in a little more
>> generalized way. E.g. you could use all of the following without
>> having special functions for them all:
>>
>> $firstNames = [foreach ($users as $user) yield $user->firstName];
>>
>> $firstNames = [foreach ($users as $user) yield $user->getFirstName()];
>>
>> $firstNames = [foreach ($users as $user) yield $user['firstName']];
>>
>> It's also possible to explicitly specify a key:
>>
>> $firstNames = [foreach ($users as $user) yield $user->id =>
>> $user->firstName];
>>
>> It is also possible to filter elements using list comprehensions:
>>
>> $underageUsers = [foreach ($users as $user) if ($user->age < 18)
>> yield $user];
>> // or just the names
>> $underageUserNames = [foreach ($users as $user) if ($user->age <
>> 18) yield $user->firstName];
>>
>> It is also possible to nest multiple foreach loops:
>>
>> $aList = ['A', 'B'];
>> $bList = [1, 2];
>> $combinations = [foreach ($aList as $a) foreach ($bList as $b)
>> yield [$a, $b]];
>> // gives: [ ['A', 1], ['A', 2], ['B', 1], ['B', 2] ]
>>
>> All the above are list comprehensions (or in PHP rather array
>> comprehensions), i.e. they create an array as the result.
>>
>> If this is not needed it is also possible to compute the values lazily
>> using generator expressions, which use () instead of [].
>>
>> $firstNames = (foreach ($users as $user) yield $user->firstName);
>>
>> In this case $firstNames will no longer be an array of first names,
>> but instead will be a generator producing first names.
>>
>> This is handy if you only need to iterate the resulting "list" only
>> once as it saves you holding the whole list in memory.
>>
>> Also it allows you to work with infinite lists easily:
>>
>> function *naturalNumbers() {
>> for ($i = 0; ; ++$i) {
>> yield $i;
>> }
>> }
>>
>> // all natural numbers
>> $numbers = naturalNumbers();
>> // only the odd ones
>> $oddNumbers = (foreach ($numbers as $n) if ($n % 2) yield $n);
>> // ...
>>
>> (At this point I wonder whether one should include support for
>> for-loops in list comprehensions. So the naturalNumbers() function
>> could be replaced with (for ($i = 0;; ++$i) yield $i), etc)
>>
>> So, what do you think? Do we want something like this in PHP?
>>
>> Nikita
>>
>> --
>> 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] List comprehensions and generator expressions for PHP
Hi,
Whats the difference to the (already existing) function array_map() (except
the syntax and one more new keyword)?
> $firstNames = array_map(function($user){return $user->firstname;},
$users);
Don't want to rewrite every example you gave, but you probably see my point.
Regards,
Sebastian
2012/6/28 Nikita Popov
> Hi internals!
>
> Python and several other languages include support for list
> comprehensions and generator expressions and I'd like to see something
> similar in PHP too.
>
> I created a hacky proof of concept implementation here:
> https://github.com/nikic/php-src/tree/addListComprehensions. It's
> really dirty, but it implements both features in about ~150 lines of
> code.
>
> Currently I'm using the following syntax:
>
>$firstNames = [foreach ($users as $user) yield $user->firstName];
>
> This code is roughly equivalent to writing:
>
>$firstNames = [];
>foreach ($users as $user) {
>$firstNames[] = $user->firstName;
>}
>
> You may notice that this particular list comprehension provides the
> same functionality as array_column(), just in a little more
> generalized way. E.g. you could use all of the following without
> having special functions for them all:
>
>$firstNames = [foreach ($users as $user) yield $user->firstName];
>
>$firstNames = [foreach ($users as $user) yield $user->getFirstName()];
>
>$firstNames = [foreach ($users as $user) yield $user['firstName']];
>
> It's also possible to explicitly specify a key:
>
>$firstNames = [foreach ($users as $user) yield $user->id =>
> $user->firstName];
>
> It is also possible to filter elements using list comprehensions:
>
>$underageUsers = [foreach ($users as $user) if ($user->age < 18)
> yield $user];
>// or just the names
>$underageUserNames = [foreach ($users as $user) if ($user->age <
> 18) yield $user->firstName];
>
> It is also possible to nest multiple foreach loops:
>
>$aList = ['A', 'B'];
>$bList = [1, 2];
>$combinations = [foreach ($aList as $a) foreach ($bList as $b)
> yield [$a, $b]];
>// gives: [ ['A', 1], ['A', 2], ['B', 1], ['B', 2] ]
>
> All the above are list comprehensions (or in PHP rather array
> comprehensions), i.e. they create an array as the result.
>
> If this is not needed it is also possible to compute the values lazily
> using generator expressions, which use () instead of [].
>
>$firstNames = (foreach ($users as $user) yield $user->firstName);
>
> In this case $firstNames will no longer be an array of first names,
> but instead will be a generator producing first names.
>
> This is handy if you only need to iterate the resulting "list" only
> once as it saves you holding the whole list in memory.
>
> Also it allows you to work with infinite lists easily:
>
>function *naturalNumbers() {
>for ($i = 0; ; ++$i) {
>yield $i;
>}
>}
>
>// all natural numbers
>$numbers = naturalNumbers();
>// only the odd ones
>$oddNumbers = (foreach ($numbers as $n) if ($n % 2) yield $n);
>// ...
>
> (At this point I wonder whether one should include support for
> for-loops in list comprehensions. So the naturalNumbers() function
> could be replaced with (for ($i = 0;; ++$i) yield $i), etc)
>
> So, what do you think? Do we want something like this in PHP?
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] List comprehensions and generator expressions for PHP
Heya, > So, what do you think? Do we want something like this in PHP? I think it looks great, especially the generator functions would be useful to avoid having to create a full blown iterator for simple stuff. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] List comprehensions and generator expressions for PHP
Hi internals!
Python and several other languages include support for list
comprehensions and generator expressions and I'd like to see something
similar in PHP too.
I created a hacky proof of concept implementation here:
https://github.com/nikic/php-src/tree/addListComprehensions. It's
really dirty, but it implements both features in about ~150 lines of
code.
Currently I'm using the following syntax:
$firstNames = [foreach ($users as $user) yield $user->firstName];
This code is roughly equivalent to writing:
$firstNames = [];
foreach ($users as $user) {
$firstNames[] = $user->firstName;
}
You may notice that this particular list comprehension provides the
same functionality as array_column(), just in a little more
generalized way. E.g. you could use all of the following without
having special functions for them all:
$firstNames = [foreach ($users as $user) yield $user->firstName];
$firstNames = [foreach ($users as $user) yield $user->getFirstName()];
$firstNames = [foreach ($users as $user) yield $user['firstName']];
It's also possible to explicitly specify a key:
$firstNames = [foreach ($users as $user) yield $user->id =>
$user->firstName];
It is also possible to filter elements using list comprehensions:
$underageUsers = [foreach ($users as $user) if ($user->age < 18)
yield $user];
// or just the names
$underageUserNames = [foreach ($users as $user) if ($user->age <
18) yield $user->firstName];
It is also possible to nest multiple foreach loops:
$aList = ['A', 'B'];
$bList = [1, 2];
$combinations = [foreach ($aList as $a) foreach ($bList as $b)
yield [$a, $b]];
// gives: [ ['A', 1], ['A', 2], ['B', 1], ['B', 2] ]
All the above are list comprehensions (or in PHP rather array
comprehensions), i.e. they create an array as the result.
If this is not needed it is also possible to compute the values lazily
using generator expressions, which use () instead of [].
$firstNames = (foreach ($users as $user) yield $user->firstName);
In this case $firstNames will no longer be an array of first names,
but instead will be a generator producing first names.
This is handy if you only need to iterate the resulting "list" only
once as it saves you holding the whole list in memory.
Also it allows you to work with infinite lists easily:
function *naturalNumbers() {
for ($i = 0; ; ++$i) {
yield $i;
}
}
// all natural numbers
$numbers = naturalNumbers();
// only the odd ones
$oddNumbers = (foreach ($numbers as $n) if ($n % 2) yield $n);
// ...
(At this point I wonder whether one should include support for
for-loops in list comprehensions. So the naturalNumbers() function
could be replaced with (for ($i = 0;; ++$i) yield $i), etc)
So, what do you think? Do we want something like this in PHP?
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Hi, 2012/6/28 Rasmus Lerdorf : > On 06/27/2012 08:45 PM, Yasuo Ohgaki wrote: >> Hi, >> >> I forgot to mention MySQL's query cache. >> This change may have negative performance impact, since prepared >> query is not cached and native prepared query may not be used by >> other requests. > > That's not really true anymore. There are some limitations, yes, but in > general prepared statements are cached since MySQL version 5.1.21 Good to know! Thank you. -- Yasuo Ohgaki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Property get/set syntax
What is the state here with regard to merge into php-src?
On Sun, Apr 22, 2012 at 5:48 AM, Clint M Priest wrote:
>
>
> > -Original Message-
> > From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> > Sent: Saturday, April 21, 2012 10:33 PM
> > To: Clint M Priest
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] RFC: Property get/set syntax
> >
> > Hi!
> >
> > > empty() - Returns true for a property retrieved via __get() or via a
> > > getter -- Any idea why this would be the case for __get()? Is this a
> > > bug?
> >
> > isset() calls __isset(), empty() calls __isset() and __get(). I'm not
> sure what exactly you consider to be a bug.
>
> I see, well the only way to resolve this would be to add isset and unset
> property functions as well.
>
> Anyone against it?
>
> >
> > > unset() - Would unset a temporary variable (the one returned by the
> > > getter) -- see previous email re: adding unset/isset property
> > > functions.
> >
> > unset() calls __unset().
> >
> > > sort() - Does the same thing as with __get()/__set() which is to say,
> > > the array is sorted but the property is not updated with the value.
> > > Should accessor behave differently than the magic methods? Should
> > > this just be documents or should this be fixed?
> >
> > sort() works just fine if you define __get to return by-ref.
>
> Returning by reference was not documented in the original RFC, would this
> syntax work for everyone?
>
> public $Hours {
>&get { return $this->a; }
> }
>
> >
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
On Wed, 2012-06-27 at 22:00 -0400, Anthony Ferrara wrote:
> Johannes,
>
> > Some comments on the "error behavior" part:
> >
> >E_WARNING - When CRYPT is not included in core (was disabled
> >compile-time, or is listed in disabled_functions declaration)
> >
> > Disabling a different function should have no effect. This is not
> > intuitive. If crypt is a dependency and is not available this function
> > shouldn't be available either.
>
> Hrm. Well, then I guess I could re-implement against crypt internally.
> That would take either a slight re-implementation of the crypt()
> internals, or slight refactoring of the PHP_FUNCTION(crypt) function
> to enable c calls to it (even if it's disabled).
I haven't looked at your patch. But if it has to call another
PHP_FuNCTION then it's not good. crypt implementation should be
accessible via C.
> I don't like the concept of core functions disappearing if they are
> not implemented. I think that does nothing but make it harder on the
> developers (now having to inject a function_exists(), etc).
I think it's rather the opposite. In that case the user has no way to
check whether the function is there without calling it and reacting to
errors. If the function "disappears" there is a possibility to check.
> Additionally, since this is a security issue, I think that always
> defining the function is the better approach. Otherwise, you can wind
> up in a situation where someone else comes in and implements function
> password_verify($password, $hash) { return true; }, which would be all
> sorts of bad... I can see the static linking to the function (instead
> of the dynamic call that's there), So in this case, I personally think
> the warning is appropriate.
Who should be the bad person in that scenario? The developer himself? I
think even the security goes the other way round - deelopers don't do
error checking, so they store an empty password in case of error. If the
function does not exist and is being called the script temrinates and
nothing further ad happens.
> >E_WARNING - When supplied an incorrect number of arguments.
> >E_WARNING - When supplied a non-string first parameter (password)
> >
> > This should follow common semantics of zend_parse_parameters(... "s").
> > i.e. it has to support objects with __toString(). Also other scalars are
> > fine. (if they can be casted to string)
> >
> >E_WARNING - If a non-string salt option is provided
> >
> > As above.
>
> Yeah, I guess that's fair. Is there a macro or function like
> Z_REPRESENTABLE_AS_STRING_P() or something? To make it easier to
> check?
No, but a simple zend_parse_parameters with "s" modifier should be
enough?
> >If any error is raise, false is returned by the function.
> >
> > In http://de.php.net/functions.internal it is documented that internal
> > functions return NULL on error during parameter parsing. New exceptions
> > for that should have a good reason.
>
> The good reason is consistency. Otherwise there would be three return
> values, `null`, `false` and `true` for password_verify(). Therefore, a
> check of `false === password_verify($foo)` would actually fail
> inadvertantly.
>
> My opinion is that it should do what's appropriate. The other 2 I can
> live with returning null (although I disagree with it significantly),
> but password_verify I think really should only ever return a
> boolean...
I don't see what makes password_verify special. If one wants a typesafe
check one can go for true === password_verify.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Hi Anthony! On Thu, Jun 28, 2012 at 4:00 AM, Anthony Ferrara wrote: > Hrm. Well, then I guess I could re-implement against crypt internally. > That would take either a slight re-implementation of the crypt() > internals, or slight refactoring of the PHP_FUNCTION(crypt) function > to enable c calls to it (even if it's disabled). We would have to expose the crypt implementation, it is not the case right now. But you could still use it using func call. Let me know if you need to expose it and which parts, we will need to refactor it a bit (which should be a good thing to do anyway). > I don't like the concept of core functions disappearing if they are > not implemented. Well, that's the case for extensions altogether so... :) However if I remember correctly, I made crypt always available from php 5.3 and later, for all algorithms. >> E_WARNING - When supplied an incorrect number of arguments. >> E_WARNING - When supplied a non-string first parameter (password) I would not use warnings at all but return false on error. Maybe add an argument or a function to fetch the error messages. In case you call other PHP functions, you can push/pop the errors easily as well. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
