Re: [PHP-DEV] [RFC] Generators
Morgan L. Owens wrote:
For the third one ... I'm still waiting for some clarification on how
yield is SUPPOSED to work anyway? If you are using a 'generator' to
return a sequence of data elements, then just what does happen between
each call to the generator ... DOES the generator get called for each
value until something flags there are no more? I still don't see the
advantage of restructuring how things are called to get around a problem
which can just as easily be solved by proper design in the first place.
Have you even read the RFC yet? Calling a generator function returns an instance
of a Generator object. That object has a method interface - described in the
RFC. That interface is accessible to the foreach() construct so the loop can
iterate over the successive values returned by the object.
If by "proper design" you mean your own personal preference for using callbacks,
that's also discussed in the RFC. You were told this last month:
You see that is my problem ... WHY is using an existing object instance so
wrong?
$handle = fopen("../data/clientdatabase.csv", "r");
if ( $handle == FALSE) {
$row = -999;
} else {
while (($data = fgetcsv($handle, 800, ",")) !== FALSE) {
if ( $row ) $contact->ContactRecordLoad( $data );
$row++;
}
fclose($handle);
}
$contact->ContactRecordLoad( $data ); simply processes the data and then throws
it away, so why is this so bad? I am just trying to understand why my long time
method of working is so frond upon, and understand if generators will improve
the performance of the above 'very heavy' code. ContactRecordLoad identifies the
'line type' and then extracts the data based on the line type. My NLPG data
importer has a dozen processor functions selected by the base 'RecordLoad',
normally the only problem area is translating different date formats into
something generic, so the basic iteration loop isn't a problem. How will the use
of 'yield' make this better? Or more important - based on the rfc - why is this
so wrong?
--
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] re: removing an item from an array
On Tue, Aug 21, 2012 at 10:31 AM, Rasmus Schultz wrote:
> Thank you, but this isn't really anything like what I had in mind.
>
> What I had in mind is more like set-semantics for arrays, e.g. designed to
> work with sets of distinct values/objects.
>
> Since I do not have permission to write on the wiki, I posted an initial
> draft here:
>
> https://gist.github.com/321ad9b4b8c4e1713488
Just an idea, since array_delete() may remove multiple values, I would
change the return value to (int) and return how many elements were removed
from the array.
>
>
>
> On Mon, Aug 20, 2012 at 10:10 PM, Yasuo Ohgaki wrote:
>
> > Hi,
> >
> > 2012/8/21 Rasmus Schultz :
> > > I have a login (mindplay) but I do not have permission to post or edit
> > > anything on the wiki...
> >
> > I've created RFC for this
> >
> > https://wiki.php.net/rfc/array_delete
> >
> > Get wiki account and finish discussion.
> > I may write patch for this with my spare time, but
> > it may take while to find time. I suggest write patch
> > and send pull request.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
> > >
> > > On Mon, Aug 20, 2012 at 8:01 PM, Will Fitch wrote:
> > >
> > >> Please let this die until someone is serious enough to come up with an
> > >> rfc. This has been nothing but counterproductive arguing. If someone
> > feels
> > >> strongly about it, write an rfc then we can discuss?
> > >> On Aug 20, 2012 7:53 PM, "Yasuo Ohgaki" wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> 2012/8/21 Herman Radtke :
> > >>> >>> May be we should have something like
> > >>> >>
> > >>> >> >>
> > >>> >> >> array_delete_if($array, function($v, $k=null) { if ($v == 300)
> > >>> return
> > >>> >> >> true; })
> > >>> >> >
> > >>> >> > So array_filter?
> > >>> >>
> > >>> >> I'll use it or like for deleting, but the point of this thread is
> > >>> >> "intuitive function for deleting element(s)"
> > >>> >>
> > >>> >> array_delete($array, $value|callable)
> > >>> >>
> > >>> >> would be nicer for users, perhaps.
> > >>> >
> > >>> >
> > >>> > You are basically asking to alias array_filter with "array_delete".
> > >>> That is
> > >>> > a very slippery slope. I think array_filter is very a very obvious
> > >>> choice to
> > >>> > remove something from an array. The "filter" function/method is
> > common
> > >>> in
> > >>> > functional languages (and functional frameworks like Underscore).
> > >>> >
> > >>> > These are things developers just need to learn as part of
> > development.
> > >>> > Really, this is entire thread should be on stack overflow, not
> > >>> internals.
> > >>>
> > >>> I guess you haven't read later post.
> > >>>
> > >>> You've also made a novice mistake.
> > >>> array_filter() DO NOT delete elements, but creates new array.
> > >>> array_delete() is another form of array_walk(), not array_filter().
> > >>> See my posts.
> > >>>
> > >>> Having a API for dedicated task is good thing.
> > >>> Who would argue array_pop()/array_push() isn't needed?
> > >>>
> > >>> Regards,
> > >>>
> > >>> --
> > >>> Yasuo Ohgaki
> > >>> yohg...@ohgaki.net
> > >>>
> > >>> --
> > >>> PHP Internals - PHP Runtime Development Mailing List
> > >>> To unsubscribe, visit: http://www.php.net/unsub.php
> > >>>
> > >>>
> >
>
--
--
Tjerk
Re: [PHP-DEV] re: removing an item from an array
On Mon, Aug 20, 2012 at 8:47 PM, Levi Morrison wrote: > On Mon, Aug 20, 2012 at 8:31 PM, Rasmus Schultz wrote: >> Thank you, but this isn't really anything like what I had in mind. >> >> What I had in mind is more like set-semantics for arrays, e.g. designed to >> work with sets of distinct values/objects. >> >> Since I do not have permission to write on the wiki, I posted an initial >> draft here: >> >> https://gist.github.com/321ad9b4b8c4e1713488 >> >> > > I'll update the RFC with your information, Rasmus. Done. I suggest that you start a new emaili thread based on the RFC when you feel the RFC is ready. If you have not already, you should ask for wiki karma (see https://wiki.php.net/rfc/array_delete?do=register). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On Mon, Aug 20, 2012 at 8:31 PM, Rasmus Schultz wrote: > Thank you, but this isn't really anything like what I had in mind. > > What I had in mind is more like set-semantics for arrays, e.g. designed to > work with sets of distinct values/objects. > > Since I do not have permission to write on the wiki, I posted an initial > draft here: > > https://gist.github.com/321ad9b4b8c4e1713488 > > I'll update the RFC with your information, Rasmus. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
Thank you, but this isn't really anything like what I had in mind.
What I had in mind is more like set-semantics for arrays, e.g. designed to
work with sets of distinct values/objects.
Since I do not have permission to write on the wiki, I posted an initial
draft here:
https://gist.github.com/321ad9b4b8c4e1713488
On Mon, Aug 20, 2012 at 10:10 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/8/21 Rasmus Schultz :
> > I have a login (mindplay) but I do not have permission to post or edit
> > anything on the wiki...
>
> I've created RFC for this
>
> https://wiki.php.net/rfc/array_delete
>
> Get wiki account and finish discussion.
> I may write patch for this with my spare time, but
> it may take while to find time. I suggest write patch
> and send pull request.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> >
> > On Mon, Aug 20, 2012 at 8:01 PM, Will Fitch wrote:
> >
> >> Please let this die until someone is serious enough to come up with an
> >> rfc. This has been nothing but counterproductive arguing. If someone
> feels
> >> strongly about it, write an rfc then we can discuss?
> >> On Aug 20, 2012 7:53 PM, "Yasuo Ohgaki" wrote:
> >>
> >>> Hi,
> >>>
> >>> 2012/8/21 Herman Radtke :
> >>> >>> May be we should have something like
> >>> >>
> >>> >> >>
> >>> >> >> array_delete_if($array, function($v, $k=null) { if ($v == 300)
> >>> return
> >>> >> >> true; })
> >>> >> >
> >>> >> > So array_filter?
> >>> >>
> >>> >> I'll use it or like for deleting, but the point of this thread is
> >>> >> "intuitive function for deleting element(s)"
> >>> >>
> >>> >> array_delete($array, $value|callable)
> >>> >>
> >>> >> would be nicer for users, perhaps.
> >>> >
> >>> >
> >>> > You are basically asking to alias array_filter with "array_delete".
> >>> That is
> >>> > a very slippery slope. I think array_filter is very a very obvious
> >>> choice to
> >>> > remove something from an array. The "filter" function/method is
> common
> >>> in
> >>> > functional languages (and functional frameworks like Underscore).
> >>> >
> >>> > These are things developers just need to learn as part of
> development.
> >>> > Really, this is entire thread should be on stack overflow, not
> >>> internals.
> >>>
> >>> I guess you haven't read later post.
> >>>
> >>> You've also made a novice mistake.
> >>> array_filter() DO NOT delete elements, but creates new array.
> >>> array_delete() is another form of array_walk(), not array_filter().
> >>> See my posts.
> >>>
> >>> Having a API for dedicated task is good thing.
> >>> Who would argue array_pop()/array_push() isn't needed?
> >>>
> >>> 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] re: removing an item from an array
Hi,
2012/8/21 Rasmus Schultz :
> I have a login (mindplay) but I do not have permission to post or edit
> anything on the wiki...
I've created RFC for this
https://wiki.php.net/rfc/array_delete
Get wiki account and finish discussion.
I may write patch for this with my spare time, but
it may take while to find time. I suggest write patch
and send pull request.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
>
> On Mon, Aug 20, 2012 at 8:01 PM, Will Fitch wrote:
>
>> Please let this die until someone is serious enough to come up with an
>> rfc. This has been nothing but counterproductive arguing. If someone feels
>> strongly about it, write an rfc then we can discuss?
>> On Aug 20, 2012 7:53 PM, "Yasuo Ohgaki" wrote:
>>
>>> Hi,
>>>
>>> 2012/8/21 Herman Radtke :
>>> >>> May be we should have something like
>>> >>
>>> >> >>
>>> >> >> array_delete_if($array, function($v, $k=null) { if ($v == 300)
>>> return
>>> >> >> true; })
>>> >> >
>>> >> > So array_filter?
>>> >>
>>> >> I'll use it or like for deleting, but the point of this thread is
>>> >> "intuitive function for deleting element(s)"
>>> >>
>>> >> array_delete($array, $value|callable)
>>> >>
>>> >> would be nicer for users, perhaps.
>>> >
>>> >
>>> > You are basically asking to alias array_filter with "array_delete".
>>> That is
>>> > a very slippery slope. I think array_filter is very a very obvious
>>> choice to
>>> > remove something from an array. The "filter" function/method is common
>>> in
>>> > functional languages (and functional frameworks like Underscore).
>>> >
>>> > These are things developers just need to learn as part of development.
>>> > Really, this is entire thread should be on stack overflow, not
>>> internals.
>>>
>>> I guess you haven't read later post.
>>>
>>> You've also made a novice mistake.
>>> array_filter() DO NOT delete elements, but creates new array.
>>> array_delete() is another form of array_walk(), not array_filter().
>>> See my posts.
>>>
>>> Having a API for dedicated task is good thing.
>>> Who would argue array_pop()/array_push() isn't needed?
>>>
>>> Regards,
>>>
>>> --
>>> Yasuo Ohgaki
>>> yohg...@ohgaki.net
>>>
>>> --
>>> 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] re: removing an item from an array
I have a login (mindplay) but I do not have permission to post or edit
anything on the wiki...
On Mon, Aug 20, 2012 at 8:01 PM, Will Fitch wrote:
> Please let this die until someone is serious enough to come up with an
> rfc. This has been nothing but counterproductive arguing. If someone feels
> strongly about it, write an rfc then we can discuss?
> On Aug 20, 2012 7:53 PM, "Yasuo Ohgaki" wrote:
>
>> Hi,
>>
>> 2012/8/21 Herman Radtke :
>> >>> May be we should have something like
>> >>
>> >> >>
>> >> >> array_delete_if($array, function($v, $k=null) { if ($v == 300)
>> return
>> >> >> true; })
>> >> >
>> >> > So array_filter?
>> >>
>> >> I'll use it or like for deleting, but the point of this thread is
>> >> "intuitive function for deleting element(s)"
>> >>
>> >> array_delete($array, $value|callable)
>> >>
>> >> would be nicer for users, perhaps.
>> >
>> >
>> > You are basically asking to alias array_filter with "array_delete".
>> That is
>> > a very slippery slope. I think array_filter is very a very obvious
>> choice to
>> > remove something from an array. The "filter" function/method is common
>> in
>> > functional languages (and functional frameworks like Underscore).
>> >
>> > These are things developers just need to learn as part of development.
>> > Really, this is entire thread should be on stack overflow, not
>> internals.
>>
>> I guess you haven't read later post.
>>
>> You've also made a novice mistake.
>> array_filter() DO NOT delete elements, but creates new array.
>> array_delete() is another form of array_walk(), not array_filter().
>> See my posts.
>>
>> Having a API for dedicated task is good thing.
>> Who would argue array_pop()/array_push() isn't needed?
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
Re: Re: [PHP-DEV] [RFC] Generators
On 2012-08-21 01:10, Lester Caine wrote: For the third one ... I'm still waiting for some clarification on how yield is SUPPOSED to work anyway? If you are using a 'generator' to return a sequence of data elements, then just what does happen between each call to the generator ... DOES the generator get called for each value until something flags there are no more? I still don't see the advantage of restructuring how things are called to get around a problem which can just as easily be solved by proper design in the first place. Have you even read the RFC yet? Calling a generator function returns an instance of a Generator object. That object has a method interface - described in the RFC. That interface is accessible to the foreach() construct so the loop can iterate over the successive values returned by the object. If by "proper design" you mean your own personal preference for using callbacks, that's also discussed in the RFC. You were told this last month: On Sat, Jul 28, 2012 as 05:34 AM, Nikita Popov wrote > On Wed, Jul 25, 2012 at 10:36 PM, Lester Caine wrote: >> But WHY would you not simply put the function that is handling the returned >> data in place of the yield? >> Why do you want to keep exiting and re-entering the 'do loop' when the data >> can simply be forwarded direct to a function to handle it? > >This question has come up a few times now, i.e. why one can't just use >callbacks. So I added a section about this, explaining it with a few >examples: https://wiki.php.net/rfc/generators#why_not_just_use_callback_functions > >Hope it helps, >Nikita But let's compare the two side-by-side. So there is a "producer" that has or generates the successive elements of a sequence, and a "consumer" that does something with each element in turn. One can make a choice about which of the two - producer or consumer - gets to drive the process. In one (basically the Observer pattern), the producer drives, and the consumer gets to observe by supplying a callback that the producer calls for each new element. Since the producer has no idea about the internal workings of the consumer, the consumer has to ensure that it can properly resume the next time it is called. In the other (basically the Iterator pattern), the consumer drives, calling the producer each time a new element is required. Since the consumer has no idea about the internal workings of the producer, the producer has to ensure that it can properly resume the next time it is called. There are a couple of differences between using an observer and using an iterator. The main difference is because at least one of the producer or consumer needs to maintain its own state between iterations. For the producer-driven observer approach, it is the consumer's job to maintain state. - the producer's state is safe on the call stack. For the consumer-driven iterator approach, it is the producer's job to maintain state - the consumer's state is safe on the call stack. In the observer approach, writing the state-maintenance code falls to whoever is writing the consumer; the producer is unable to help with that at all because it's different for each consumer. In the iterator approach, writing the state-maintenance code falls to whoever is writing the producer; that code is the same regardless of the consumer. As this proposal and existing implementations show, it is possible, given the kernel behaviour of the iteration, to mechanically generate all the state-handling and other boilerplate necessary to produce a Generator object. That's the main difference. The other difference is that in the case of the iterator, in part because the code generation can be mechanised, the iteration mechanism can be done in such a way that it fits in with the iteration mechanisms that PHP already has built into the language: the foreach() statement doesn't care whether it's iterating over an array or an iterator or a generator. Either could be supplied at runtime. In contrast, to achieve the analogous effect with an observer mechanism would involve (among other things) searching for occurrences of control flow statements that reference the sequence, excising those statements and using them as the kernel for a callback method to be supplied to the sequence producer ... but only if the sequence in question wants all that done in the first place. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shared mysqlnd extension ...
On 08/20/2012 08:12 PM, Lester Caine wrote: > Rasmus Lerdorf wrote: >> On 08/20/2012 06:51 PM, Lester Caine wrote: >>> >Ferenc Kovacs wrote: >>why is this an internals question? >>> >Because no one answered on general:( >>> >But since the core code base does not compile it seems internal to me >>> >anyway. >> The bundled extensions are not designed to be built standalone using >> phpize as you have discovered. The core codebase builds perfectly using >> the procedure it was designed for. And you don't have to touch your core >> install. Just add the flags or build in a separate directory if you are >> worried and type make install-modules and it will install any shared >> modules from that build without touching anything else. Or you can >> simply copy the modules/*.so files you want to your extension_dir >> manually. > > Except that mysqlnd does not build as a shared module even when doing a > full build. mysqli is fine built either way, and a standalone build of > mysqlnd creates a module without any warnings, just not one that works, > but there seems to be no way to flag from a core build that mysqlnd > should be built shared? There is no mysqlnd.so file to copy over, and > only a stand alone build seems to have the relevant flag :( mysqlnd is not a standalone extension at all. It is infrastructure code that needs to be linked into your PHP in order for extensions to use it. Once you have that you can load shared mysql, mysqli and pdo_mysql extensions against it. And no, it won't affect other extensions that mysqlnd is there. But again, this is a question for php-install, not internals. This is pretty basic stuff. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shared mysqlnd extension ...
Rasmus Lerdorf wrote: On 08/20/2012 06:51 PM, Lester Caine wrote: >Ferenc Kovacs wrote: >>why is this an internals question? >Because no one answered on general:( >But since the core code base does not compile it seems internal to me >anyway. The bundled extensions are not designed to be built standalone using phpize as you have discovered. The core codebase builds perfectly using the procedure it was designed for. And you don't have to touch your core install. Just add the flags or build in a separate directory if you are worried and type make install-modules and it will install any shared modules from that build without touching anything else. Or you can simply copy the modules/*.so files you want to your extension_dir manually. Except that mysqlnd does not build as a shared module even when doing a full build. mysqli is fine built either way, and a standalone build of mysqlnd creates a module without any warnings, just not one that works, but there seems to be no way to flag from a core build that mysqlnd should be built shared? There is no mysqlnd.so file to copy over, and only a stand alone build seems to have the relevant flag :( SO am I going to have to just create a parallel installation with mysqlnd included statically? Will the thirty odd existing extensions still work with that without having to recompile them? I ask since I understood that the php-config file needed to match the base code, and this would change when rebuilding the base code. In the past I've ended up recompiling everything just to get a working set of extensions. -- 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] re: removing an item from an array
Please let this die until someone is serious enough to come up with an rfc.
This has been nothing but counterproductive arguing. If someone feels
strongly about it, write an rfc then we can discuss?
On Aug 20, 2012 7:53 PM, "Yasuo Ohgaki" wrote:
> Hi,
>
> 2012/8/21 Herman Radtke :
> >>> May be we should have something like
> >>
> >> >>
> >> >> array_delete_if($array, function($v, $k=null) { if ($v == 300) return
> >> >> true; })
> >> >
> >> > So array_filter?
> >>
> >> I'll use it or like for deleting, but the point of this thread is
> >> "intuitive function for deleting element(s)"
> >>
> >> array_delete($array, $value|callable)
> >>
> >> would be nicer for users, perhaps.
> >
> >
> > You are basically asking to alias array_filter with "array_delete". That
> is
> > a very slippery slope. I think array_filter is very a very obvious
> choice to
> > remove something from an array. The "filter" function/method is common in
> > functional languages (and functional frameworks like Underscore).
> >
> > These are things developers just need to learn as part of development.
> > Really, this is entire thread should be on stack overflow, not internals.
>
> I guess you haven't read later post.
>
> You've also made a novice mistake.
> array_filter() DO NOT delete elements, but creates new array.
> array_delete() is another form of array_walk(), not array_filter().
> See my posts.
>
> Having a API for dedicated task is good thing.
> Who would argue array_pop()/array_push() isn't needed?
>
> 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] re: removing an item from an array
Hi,
2012/8/21 Herman Radtke :
>>> May be we should have something like
>>
>> >>
>> >> array_delete_if($array, function($v, $k=null) { if ($v == 300) return
>> >> true; })
>> >
>> > So array_filter?
>>
>> I'll use it or like for deleting, but the point of this thread is
>> "intuitive function for deleting element(s)"
>>
>> array_delete($array, $value|callable)
>>
>> would be nicer for users, perhaps.
>
>
> You are basically asking to alias array_filter with "array_delete". That is
> a very slippery slope. I think array_filter is very a very obvious choice to
> remove something from an array. The "filter" function/method is common in
> functional languages (and functional frameworks like Underscore).
>
> These are things developers just need to learn as part of development.
> Really, this is entire thread should be on stack overflow, not internals.
I guess you haven't read later post.
You've also made a novice mistake.
array_filter() DO NOT delete elements, but creates new array.
array_delete() is another form of array_walk(), not array_filter().
See my posts.
Having a API for dedicated task is good thing.
Who would argue array_pop()/array_push() isn't needed?
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] shared mysqlnd extension ...
On 08/20/2012 06:51 PM, Lester Caine wrote: > Ferenc Kovacs wrote: >> why is this an internals question? > Because no one answered on general :( > But since the core code base does not compile it seems internal to me > anyway. The bundled extensions are not designed to be built standalone using phpize as you have discovered. The core codebase builds perfectly using the procedure it was designed for. And you don't have to touch your core install. Just add the flags or build in a separate directory if you are worried and type make install-modules and it will install any shared modules from that build without touching anything else. Or you can simply copy the modules/*.so files you want to your extension_dir manually. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shared mysqlnd extension ...
Ferenc Kovacs wrote: Having now got mysql running on the PHP5.4.3 machine, I'm trying to compile mysqlnd and mysqli as extensions to load and unload as required. php_mysqlnd_config.h no longer exists, but why is the config file named config9.m4 rather than config.m4? What do I need to get these two extensions to build on Linux? My cuurent attempts based on google results only results in "Warning: PHP Startup: Invalid library (maybe not a PHP library) 'mysqlnd.so' in Unknown on line 0" after 'make' I would try --with-mysql=shared,mysqlnd --with-mysqli=shared,mysqlnd --enable-pdo=shared --with-pdo-mysql=shared,mysqlnd how are you doing currently? phpize in mysqlnd folder which is why config9.m4 does not work and has to be renamed, but it's calling php_mysqlnd_config.h which also does not exist. I do not want to touch the existing core install as that is what runs all my sites, so I only need mysqlnd and mysqli as extra shared modules so I can switch them off without affecting the current working system. why is this an internals question? Because no one answered on general :( But since the core code base does not compile it seems internal to me anyway. -- 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] shared mysqlnd extension ...
Andrey Hristov wrote: On 08/20/2012 11:52 PM, Lester Caine wrote: Having now got mysql running on the PHP5.4.3 machine, I'm trying to compile mysqlnd and mysqli as extensions to load and unload as required. php_mysqlnd_config.h no longer exists, but why is the config file named config9.m4 rather than config.m4? What do I need to get these two extensions to build on Linux? My cuurent attempts based on google results only results in "Warning: PHP Startup: Invalid library (maybe not a PHP library) 'mysqlnd.so' in Unknown on line 0" after 'make' File is called config9.m4, because this guarantees an order of run, if it was config.m4 no order is guaranteed during configure. It was Jani's idea. So what happens when trying to just build mysqlnd as I do any other extra module? Is simply renaming it the correct action? -- 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] shared mysqlnd extension ...
On 08/20/2012 11:52 PM, Lester Caine wrote: Having now got mysql running on the PHP5.4.3 machine, I'm trying to compile mysqlnd and mysqli as extensions to load and unload as required. php_mysqlnd_config.h no longer exists, but why is the config file named config9.m4 rather than config.m4? What do I need to get these two extensions to build on Linux? My cuurent attempts based on google results only results in "Warning: PHP Startup: Invalid library (maybe not a PHP library) 'mysqlnd.so' in Unknown on line 0" after 'make' File is called config9.m4, because this guarantees an order of run, if it was config.m4 no order is guaranteed during configure. It was Jani's idea. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shared mysqlnd extension ...
On Mon, Aug 20, 2012 at 11:52 PM, Lester Caine wrote: > Having now got mysql running on the PHP5.4.3 machine, I'm trying to > compile mysqlnd and mysqli as extensions to load and unload as required. > > php_mysqlnd_config.h no longer exists, but why is the config file named > config9.m4 rather than config.m4? What do I need to get these two > extensions to build on Linux? My cuurent attempts based on google results > only results in "Warning: PHP Startup: Invalid library (maybe not a PHP > library) 'mysqlnd.so' in Unknown on line 0" after 'make' > > hi I would try --with-mysql=shared,mysqlnd --with-mysqli=shared,mysqlnd --enable-pdo=shared --with-pdo-mysql=shared,mysqlnd how are you doing currently? why is this an internals question? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Merging fix for quoted_printable_encode()
Hi everybody, patch + test merged to master and 5.4. I would really like to merge it to 5.3 as well but if others disagree I could live without it. With regards, Lars Am 20.08.2012 um 22:03 schrieb Lars Strojny : > Hi Stas, > > I would prefer it int 5.3 as well as it might break mailing systems using > quoted_printable_encode(). I’ll add the test from the comments as well. > > Am 20.08.2012 um 20:30 schrieb Stas Malyshev : > >> Yes. For 5.3, it does not look like a critical bug, so it shouldn't be >> there. Also, the tests are still not there - so they should be added >> before the merge can happen. > > > -- > 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] Generators
On Mon, Aug 20, 2012 at 10:07 PM, Ángel González wrote: > On 20/08/12 15:12, Nikita Popov wrote: >>> You could not decorate it and rely instead on the presence of the yield >>> keyword, but parsers will thank knowing about it from the start rather >>> than realising at mid-parsing that the function is a completely >>> different beast. >> No, parsers don't care about this. It's trivial to detect in both cases. >> >> Nikita > Yes, it's trivial to detect, but how much work is for it to do so? > Suppose the parser reads php code and outputs machine instructions. When > it encouters a function(), it adds the function prologue, goes reserving > stack > space for the variables it encounters, and so on. Then you find a yield > keyword. > Options: > - Discard the generated code and go back to the function begin, using > this time > an storage into an object instead of the stack. > - Copy all the state to an object and return it. > - Add an initial pass checking which functions are generators. > > PHP being a dynamic language, it may be able to move the function variables > to a class. But it's not trivial for any parser. Sorry, I don't understand what we are arguing about here. I implemented this. I did the parser changes for this feature. And I told you that they were simple either way (both with keyword, as in the initial implementation, and without keyword, as in the current implementation). For 3rd parties (like IDEs) it is even simpler because their parsers are AST-based (unlike PHP's own parser), so they shouldn't care at all. Honestly, I stopped understanding what this whole discussion is about around ~100 mails ago. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] shared mysqlnd extension ...
Having now got mysql running on the PHP5.4.3 machine, I'm trying to compile mysqlnd and mysqli as extensions to load and unload as required. php_mysqlnd_config.h no longer exists, but why is the config file named config9.m4 rather than config.m4? What do I need to get these two extensions to build on Linux? My cuurent attempts based on google results only results in "Warning: PHP Startup: Invalid library (maybe not a PHP library) 'mysqlnd.so' in Unknown on line 0" after 'make' -- 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] Official Userland Library (was: removing an item from an array)
Lars Schultz wrote: Am 20.08.2012 19:43, schrieb Sebastian Krebs: What I don't understand is, why should every function goes directly into the core, if you can achieve exactly the same without core changes? This comment from Sebastian got me thinking. It's true. Every-someone has his own views on what is absolutely necessary and should be available to every-one. Depending on ones coding style, it probably is absolutely necessary. Whenever a userland implementation is viable, it becomes a strong argument against embedding it within the core. But those suggestions keep coming up and some create more than a little controversy among the contributors to the list and even among the core-developers. That said: Why dont we embed a library of userland code right there in the documentation, next to the core code, where a php-user would expect or look for the functionality. They'd have to be properly highlighted as userland implementations of course but would still be there to be found in the documentation. This would at least solve the problem of: - "horrible" implementations, replaced by neatly formed official userland solutions. - performance (because they would be as efficient as possible) - correctness (because discussed on the internals (or docs) list, almost as if it'd go into the core) - skill (because everyone can provide a solution, even if he's not able to write c-code) - availability (because with a simple copy/paste-action I can use the provided (currently) official solution immediately. It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a source for a userland implementation of, say, array_remove or print_r_html. Also its alot more accessible and available than PECL, because it is after all just PHP code. I am not sure wether this is a good idea, but it struck me as a better solution than just saying: it's so simple, do it yourself. Boilerplates on how to do more complex operations sounds a very good idea to me. It's exactly the sort of thing I've been asking for ... especially now that the vast majority of third party tutorials are no longer suitable? Rasmus has pointed out the same problem only in the last hour, and while trying to sort my own mysqlnd compile problem, the number of totally out of data results from google just re-enforce that situation. Even PEAR is little use as a good example of coding style since it needs to be updated to be strict compliant in a tidy way - rather than just fire fighting error messages. Using them as a replacement for tidying up core functions may be a little controversial, but it does seem the ideal idea for archiving the excellent examples that have been presented on the various lists? If they then form the base for an update to a core function, then the boilerplates just get updated to be current. -- 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] Official Userland Library (was: removing an item from an array)
On 20/08/12 21:43, Lars Schultz wrote: Am 20.08.2012 19:43, schrieb Sebastian Krebs: What I don't understand is, why should every function goes directly into the core, if you can achieve exactly the same without core changes? This comment from Sebastian got me thinking. It's true. Every-someone has his own views on what is absolutely necessary and should be available to every-one. Depending on ones coding style, it probably is absolutely necessary. Whenever a userland implementation is viable, it becomes a strong argument against embedding it within the core. It's a ridiculous argument, IMO. Nothing you could add to core couldn't be implemented in userland code somehow. (yes, that's hyperbole, but there is very often a userland solution. Most functions are for convenience) Adding functions is important for convenience as well as functionality. Sure, it would be nice to have a small set of functions, but those lead to overly verbose code and waste the time of developers. Yes, many of them can be easily implemented in userland, but consider this: what if half (say) of the array or string functions didn't exist and you had to manually implement each? A little code can quickly become a lot to do a lot of simple things. That said, not every possible function has a compelling case for addition, simply because it does something too obscure or is impractical. But those suggestions keep coming up and some create more than a little controversy among the contributors to the list and even among the core-developers. That said: Why dont we embed a library of userland code right there in the documentation, next to the core code, where a php-user would expect or look for the functionality. They'd have to be properly highlighted as userland implementations of course but would still be there to be found in the documentation. This would at least solve the problem of: - "horrible" implementations, replaced by neatly formed official userland solutions. - performance (because they would be as efficient as possible) - correctness (because discussed on the internals (or docs) list, almost as if it'd go into the core) - skill (because everyone can provide a solution, even if he's not able to write c-code) - availability (because with a simple copy/paste-action I can use the provided (currently) official solution immediately. It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a source for a userland implementation of, say, array_remove or print_r_html. Also its alot more accessible and available than PECL, because it is after all just PHP code. I am not sure wether this is a good idea, but it struck me as a better solution than just saying: it's so simple, do it yourself. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
I think this doesn't bring anything further to talk about how to
implement this in the parser.
After reading the thread again, I would like to say that
- either this should be implemented as currently defined
- or it is implemented with the generator-keyword. But then it isn't a
function anymore, because that's is ridiculous.
In that case it should look like this:
generator g() {
yield;
return;
}
2012/8/20 Ángel González :
> On 20/08/12 15:12, Nikita Popov wrote:
>>> You could not decorate it and rely instead on the presence of the yield
>>> keyword, but parsers will thank knowing about it from the start rather
>>> than realising at mid-parsing that the function is a completely
>>> different beast.
>> No, parsers don't care about this. It's trivial to detect in both cases.
>>
>> Nikita
> Yes, it's trivial to detect, but how much work is for it to do so?
> Suppose the parser reads php code and outputs machine instructions. When
> it encouters a function(), it adds the function prologue, goes reserving
> stack
> space for the variables it encounters, and so on. Then you find a yield
> keyword.
> Options:
> - Discard the generated code and go back to the function begin, using
> this time
> an storage into an object instead of the stack.
> - Copy all the state to an object and return it.
> - Add an initial pass checking which functions are generators.
>
> PHP being a dynamic language, it may be able to move the function variables
> to a class. But it's not trivial for any parser.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Freundliche Grüße
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Official Userland Library (was: removing an item from an array)
Am 20.08.2012 19:43, schrieb Sebastian Krebs: What I don't understand is, why should every function goes directly into the core, if you can achieve exactly the same without core changes? This comment from Sebastian got me thinking. It's true. Every-someone has his own views on what is absolutely necessary and should be available to every-one. Depending on ones coding style, it probably is absolutely necessary. Whenever a userland implementation is viable, it becomes a strong argument against embedding it within the core. But those suggestions keep coming up and some create more than a little controversy among the contributors to the list and even among the core-developers. That said: Why dont we embed a library of userland code right there in the documentation, next to the core code, where a php-user would expect or look for the functionality. They'd have to be properly highlighted as userland implementations of course but would still be there to be found in the documentation. This would at least solve the problem of: - "horrible" implementations, replaced by neatly formed official userland solutions. - performance (because they would be as efficient as possible) - correctness (because discussed on the internals (or docs) list, almost as if it'd go into the core) - skill (because everyone can provide a solution, even if he's not able to write c-code) - availability (because with a simple copy/paste-action I can use the provided (currently) official solution immediately. It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a source for a userland implementation of, say, array_remove or print_r_html. Also its alot more accessible and available than PECL, because it is after all just PHP code. I am not sure wether this is a good idea, but it struck me as a better solution than just saying: it's so simple, do it yourself. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
On 18/08/12 13:21, Derick Rethans wrote:
On Sat, 11 Aug 2012, Nikita Popov wrote:
Hi internals!
I think there already was a lot of discussion on the generators, so
it's time to move to the next step. I'd like to vote on the feature in
two weeks, so this the "announce[ment] on internals@, by the author,
with the intention of voting on it".
https://wiki.php.net/rfc/generators
If you have any further feedback, now would be a good time to raise
it. If there is something you previously posted, but which I didn't
yet address, please let me know. There were around 150 mails and I
sure missed some of them.
I've some comments how that I've read the RFC:
Recognition of generator functions
1. Any function which contains a yield statement is automatically a
generator function.
2. The initial implementation required that generator functions are
marked with an asterix modifier (function*). This method has the
advantage that generators are more explicit and also allows for
yield-less coroutines.
The automatic detection was chosen over the asterix modifier for the
following reasons:
I am against this. This is even more magic in PHP. Is it really that
difficult to have to mark the function with a different keyword, such as
"generator":
You know, this conversation feels like it's going in circles. I thought
we already agreed there wouldn't be one.
generator function getLinesFromFile($fileName) {
if (!$fileHandle = fopen($fileName, 'r')) {
return;
}
There is an existing generator implementation in HipHop PHP, which
uses automatic-detection. Using the asterix modifier would break
compatibility.
This should not be a concern, sure, it's annoying for the hiphop
developers but they chose to copy and then *chance* the PHP language for
their own effect.
yield: Yields the value null with an auto-incrementing integer key.
What is the usecase for this?
cheers,
Derick
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
On 20/08/12 15:12, Nikita Popov wrote: >> You could not decorate it and rely instead on the presence of the yield >> keyword, but parsers will thank knowing about it from the start rather >> than realising at mid-parsing that the function is a completely >> different beast. > No, parsers don't care about this. It's trivial to detect in both cases. > > Nikita Yes, it's trivial to detect, but how much work is for it to do so? Suppose the parser reads php code and outputs machine instructions. When it encouters a function(), it adds the function prologue, goes reserving stack space for the variables it encounters, and so on. Then you find a yield keyword. Options: - Discard the generated code and go back to the function begin, using this time an storage into an object instead of the stack. - Copy all the state to an object and return it. - Add an initial pass checking which functions are generators. PHP being a dynamic language, it may be able to move the function variables to a class. But it's not trivial for any parser. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merging fix for quoted_printable_encode()
Hi Stas, I would prefer it int 5.3 as well as it might break mailing systems using quoted_printable_encode(). I’ll add the test from the comments as well. Am 20.08.2012 um 20:30 schrieb Stas Malyshev : > Yes. For 5.3, it does not look like a critical bug, so it shouldn't be > there. Also, the tests are still not there - so they should be added > before the merge can happen. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] compile php as fpm
On 08/20/2012 03:47 PM, Adi Mutu wrote: > Hello, > > I'm trying to compile php 5.3 as php-fpm using the following configure command > > > ./configure --enable-debug --enable-maintainer-zts --enable-fpm > --enable-fastcgi > > and i get this > > " > Thank you for using PHP. > > Notice: Following unknown configure options were used: > > --enable-fastcgi > " > > The command is from a tutorial on web. This is not the mailing list for questions like this. Obviously your tutorial was not written for 5.3. The 5.3 UPGRADING document states: - FastCGI is now always enabled and can not be disabled. See sapi/cgi/CHANGES for more details. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] compile php as fpm
Hello, I'm trying to compile php 5.3 as php-fpm using the following configure command ./configure --enable-debug --enable-maintainer-zts --enable-fpm --enable-fastcgi and i get this " Thank you for using PHP. Notice: Following unknown configure options were used: --enable-fastcgi " The command is from a tutorial on web. Thanks.
Re: [PHP-DEV] [RFC] Generators
On 20/08/12 19:46, Stas Malyshev wrote:
Hi!
What would *actually* make sense here are return value typehints. E.g.
one could have something like `public Iterator getIterator() { ... }`.
And again we're back to inventing syntax to do what documentation should
be doing.
For the large part, but consider type hints mean that if you return a
completely wrong type, you can warn the programmer.
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Hi!
> What would *actually* make sense here are return value typehints. E.g.
> one could have something like `public Iterator getIterator() { ... }`.
And again we're back to inventing syntax to do what documentation should
be doing.
--
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] [RFC] Generators
Hi!
> generator function f() {
> echo "Hello World";
> }
even more interesting,
$a = generator function() {
echo "Hello World";
}
or even:
function foo() {
return generator function() {
echo "Hello World";
}
}
$a = foo();
--
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] Merging fix for quoted_printable_encode()
Hi! > Hi everybody, > > I would like to merge https://github.com/php/php-src/pull/120 in HEAD, 5_4 > and 5_3 to fix splitting of soft line breaks. Any concerns? Yes. For 5.3, it does not look like a critical bug, so it shouldn't be there. Also, the tests are still not there - so they should be added before the merge can happen. -- 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] re: removing an item from an array
Also, `array_splice` will remove the index while modifying the array in-place. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 20/08/12 19:05, Levi Morrison wrote: Some major points to consider for `array_delete`'s behavior: 1. Should items be compared with `==`, `===`, or custom comparison? If we use `==` or `===` we'd probably add `array_udelete` to allow a custom comparator. array_delete($array, $value, $all=false, $strict=false) 2. Should it stop when it encounters the first value that matches? If it does, should we add a function that searches in the reverse direction? ^ 3. Should it modify the array in-place? If so, should we have another function that returns a copy of the array that does not include the removed value(s) instead? Modify in-place. No need for another, that's filter's job imo. If someone wants to go through and define all of these cases and propose a patch, more power to them. Might do so. - Here are some reasons that aren't related to the above as to why I'm against adding `array_delete`: 1. PHP arrays are not sets. PHP arrays are meant to be a list and an associative array. As such, a PHP array can act as any* data structure that can be built from a list or associative array. A data structure that removes something by value is typically associated with a set and therefore does not belong in an array. 2. Using other array functions cover this use case AND do a better job. Want to remove the first instance of the value? Use `array_search` to find the index and unset it. If you want to reorder the array you can use `array_search` to find the index and use `array_slice`. Want to remove all instances of the value in the array? Use `array_filter`. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
Some major points to consider for `array_delete`'s behavior: 1. Should items be compared with `==`, `===`, or custom comparison? If we use `==` or `===` we'd probably add `array_udelete` to allow a custom comparator. 2. Should it stop when it encounters the first value that matches? If it does, should we add a function that searches in the reverse direction? 3. Should it modify the array in-place? If so, should we have another function that returns a copy of the array that does not include the removed value(s) instead? If someone wants to go through and define all of these cases and propose a patch, more power to them. - Here are some reasons that aren't related to the above as to why I'm against adding `array_delete`: 1. PHP arrays are not sets. PHP arrays are meant to be a list and an associative array. As such, a PHP array can act as any* data structure that can be built from a list or associative array. A data structure that removes something by value is typically associated with a set and therefore does not belong in an array. 2. Using other array functions cover this use case AND do a better job. Want to remove the first instance of the value? Use `array_search` to find the index and unset it. If you want to reorder the array you can use `array_search` to find the index and use `array_slice`. Want to remove all instances of the value in the array? Use `array_filter`. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 20/08/12 18:43, Sebastian Krebs wrote:
Am 20.08.2012 19:00, schrieb Andrew Faulds:
On 20/08/12 17:47, Herman Radtke wrote:
May be we should have something like
array_delete_if($array, function($v, $k=null) { if ($v == 300)
return
true; })
So array_filter?
I'll use it or like for deleting, but the point of this thread is
"intuitive function for deleting element(s)"
array_delete($array, $value|callable)
would be nicer for users, perhaps.
You are basically asking to alias array_filter with "array_delete".
That is
a very slippery slope. I think array_filter is very a very obvious
choice
to remove something from an array. The "filter" function/method is
common
in functional languages (and functional frameworks like Underscore).
These are things developers just need to learn as part of development.
Really, this is entire thread should be on stack overflow, not
internals.
You seem a little arrogant. Arguably, a lot of array functions are
unnecessary. But PHP is not supposed to be an extremely minimal
language. Convenience functions are a good thing.
We have array_pad for instance: completely unnecessary, you can do it
manually with other array functions. Array_fill_keys and array_fill,
too. array_flip is also unnecessary. Heck, who needs sorting, you can do
that manually too.
array_delete would be a more convenient, and more readable way to remove
a value from an array. Yes, you can already remove array items, that's
not the point. The point is this way is simpler and more convenient.
So you just want a convenient and readable way and you realise
yourself, that it is really simple to implement. So: Why don't you
just implement it yourself?
function array_delete($array, $value) {
// Your code here
}
What I don't understand is, why should every function goes directly
into the core, if you can achieve exactly the same without core changes?
I'd rather not argue any further about this (let's make an RFC and
vote). I've already addressed this point.
Regards,
Sebastian
Also, as someone else mentioned, PHP's universal collection datatype is
a great thing. It is an associative array, it is a list, it is a tuple,
it is a set, it can be used in many ways, it's incredibly versatile.
Adding array_delete would allow you to use it like a set more easily.
Just my 2½¢ :)
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
Am 20.08.2012 19:00, schrieb Andrew Faulds:
On 20/08/12 17:47, Herman Radtke wrote:
May be we should have something like
array_delete_if($array, function($v, $k=null) { if ($v == 300) return
true; })
So array_filter?
I'll use it or like for deleting, but the point of this thread is
"intuitive function for deleting element(s)"
array_delete($array, $value|callable)
would be nicer for users, perhaps.
You are basically asking to alias array_filter with "array_delete".
That is
a very slippery slope. I think array_filter is very a very obvious choice
to remove something from an array. The "filter" function/method is common
in functional languages (and functional frameworks like Underscore).
These are things developers just need to learn as part of development.
Really, this is entire thread should be on stack overflow, not internals.
You seem a little arrogant. Arguably, a lot of array functions are
unnecessary. But PHP is not supposed to be an extremely minimal
language. Convenience functions are a good thing.
We have array_pad for instance: completely unnecessary, you can do it
manually with other array functions. Array_fill_keys and array_fill,
too. array_flip is also unnecessary. Heck, who needs sorting, you can do
that manually too.
array_delete would be a more convenient, and more readable way to remove
a value from an array. Yes, you can already remove array items, that's
not the point. The point is this way is simpler and more convenient.
So you just want a convenient and readable way and you realise yourself,
that it is really simple to implement. So: Why don't you just implement
it yourself?
function array_delete($array, $value) {
// Your code here
}
What I don't understand is, why should every function goes directly into
the core, if you can achieve exactly the same without core changes?
Regards,
Sebastian
Also, as someone else mentioned, PHP's universal collection datatype is
a great thing. It is an associative array, it is a list, it is a tuple,
it is a set, it can be used in many ways, it's incredibly versatile.
Adding array_delete would allow you to use it like a set more easily.
Just my 2½¢ :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 20/08/12 18:27, Levi Morrison wrote: You are basically asking to alias array_filter with "array_delete". That is a very slippery slope. I think array_filter is a very obvious choice to remove something from an array. The "filter" function/method is common in functional languages (and functional frameworks like Underscore). This about sums up my opinion on deleting things by value on a PHP array. ** Me and Levi had a private email back-and-forth about this. Like many things here, this discussion has become a pseudo-argument, and it's unclear whether people actually think it's a good idea or not. So let's make an RFC (I think array_delete($array, $value, $all=false), mirrors Python's replace-one-only by default), vote on it, and that can decide things. So we can avoid argument. Don't like the syntax? Vote against it, but I don't see how it could be much better. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
> You are basically asking to alias array_filter with "array_delete". That is > a very slippery slope. I think array_filter is a very obvious choice > to remove something from an array. The "filter" function/method is common > in functional languages (and functional frameworks like Underscore). This about sums up my opinion on deleting things by value on a PHP array. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 20/08/12 18:11, Levi Morrison wrote: Adding array_delete would allow you to use it like a set more It's not a set and wasn't meant to be. If you want really bad set behavior, feel free to use an array as one. Arrays also aren't lists or associative arrays, strictly speaking. And there is another use case: removing of list items by value, instead of key. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
> Adding array_delete would allow you to use it like a set more It's not a set and wasn't meant to be. If you want really bad set behavior, feel free to use an array as one. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 20/08/12 17:47, Herman Radtke wrote:
May be we should have something like
array_delete_if($array, function($v, $k=null) { if ($v == 300) return
true; })
So array_filter?
I'll use it or like for deleting, but the point of this thread is
"intuitive function for deleting element(s)"
array_delete($array, $value|callable)
would be nicer for users, perhaps.
You are basically asking to alias array_filter with "array_delete". That is
a very slippery slope. I think array_filter is very a very obvious choice
to remove something from an array. The "filter" function/method is common
in functional languages (and functional frameworks like Underscore).
These are things developers just need to learn as part of development.
Really, this is entire thread should be on stack overflow, not internals.
You seem a little arrogant. Arguably, a lot of array functions are
unnecessary. But PHP is not supposed to be an extremely minimal
language. Convenience functions are a good thing.
We have array_pad for instance: completely unnecessary, you can do it
manually with other array functions. Array_fill_keys and array_fill,
too. array_flip is also unnecessary. Heck, who needs sorting, you can do
that manually too.
array_delete would be a more convenient, and more readable way to remove
a value from an array. Yes, you can already remove array items, that's
not the point. The point is this way is simpler and more convenient.
Also, as someone else mentioned, PHP's universal collection datatype is
a great thing. It is an associative array, it is a list, it is a tuple,
it is a set, it can be used in many ways, it's incredibly versatile.
Adding array_delete would allow you to use it like a set more easily.
Just my 2½¢ :)
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
>> May be we should have something like
> >>
> >> array_delete_if($array, function($v, $k=null) { if ($v == 300) return
> true; })
> >
> > So array_filter?
>
> I'll use it or like for deleting, but the point of this thread is
> "intuitive function for deleting element(s)"
>
> array_delete($array, $value|callable)
>
> would be nicer for users, perhaps.
You are basically asking to alias array_filter with "array_delete". That is
a very slippery slope. I think array_filter is very a very obvious choice
to remove something from an array. The "filter" function/method is common
in functional languages (and functional frameworks like Underscore).
These are things developers just need to learn as part of development.
Really, this is entire thread should be on stack overflow, not internals.
--
Herman Radtke
hermanrad...@gmail.com | http://hermanradtke.com
Re: [PHP-DEV] re: removing an item from an array
Absolutely, you're right. I have a tendency to get dragged into those. I apologize. On Fri, Aug 17, 2012 at 5:50 PM, Nikita Popov wrote: > > Could we please stop these pseudo-arguments?
Re: [PHP-DEV] removing an item from an array
I think adding more collection-types is the intuitive reaction to this issue, but there's something to be said for the idea of having only a single collection-type - I think that's one PHP feature we should not give up. Not having to pick and choose (and compromise) to select the "right" collection-type, and not having to refactor when you realize you needed another collection-type - as well as easy comprehension for developers... these are valuable aspects of having only a single collection-type. Some newer languages like Opa embrace that idea with great elegance. Giving up on that idea should be the last option, in my opinion. There are plenty of cases for collections of objects that do not have a scalar key, where the key is indeterminate, or where the key can change - and thus cannot have known indexes. As an aside note, I recently benchmarked array_search() for a project that needs to store many different types of objects in a list - and searching a list with 1000 objects for one specific object is extremely fast: a couple of micro-seconds more (per search) when compared against a hash-based lookup with a known key, so (in my case) nothing to worry about at all in terms of performance. Arrays are a powerful and pure feature in PHP - I would vote against introducing more collection-types, and instead leverage the already powerful and well-understood existing singular collection-type. On Sat, Aug 18, 2012 at 2:42 AM, Alexey Zakhlestin wrote: > > On 16.08.2012, at 0:18, Rasmus Schultz wrote: > > > How come there is no straight-foward obvious way to simply remove a given > > value from an array? > > Well, this sounds like a reason for creating SplSet class > >
[PHP-DEV] Merging fix for quoted_printable_encode()
Hi everybody, I would like to merge https://github.com/php/php-src/pull/120 in HEAD, 5_4 and 5_3 to fix splitting of soft line breaks. Any concerns? With regards, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Generators
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: 20 August 2012 14:12
> To: Ángel González
> Cc: Rasmus Lerdorf; Stas Malyshev; Derick Rethans; PHP internals
> Subject: Re: [PHP-DEV] [RFC] Generators
>
> On Mon, Aug 20, 2012 at 1:56 PM, Ángel González
> wrote:
> > On 20/08/12 02:01, Rasmus Lerdorf wrote:
> >> I would still like to understand what this generator keyword
would
> >> actually do. I don't see how it would work. Would a
> function marked
> >> generator somehow not be allowed to return normally or to
> finish and
> >> not return anything? How could this be enforced? I am completely
> >> against any keyword that is essentially documentation-only.
> >>
> >> -Rasmus
> > Given that such function could "return several times", seems a
> > different enough function type to have its keyword.
> The method signature defines the API, so the caller knows what to
use.
> Can we agree on that? In this case it makes absolutely no
> difference to the caller whether the function is implemented
> using a generator, or whether it returns a custom Iterator
> object. The "generator"
> keyword wouldn't document the API, it would document an
> implementation-detail.
>
> What would *actually* make sense here are return value typehints.
E.g.
> one could have something like `public Iterator getIterator() { ...
}`.
> This would provide the caller with information on what the
> function returns, but would leave out the implementation
> detail that the Iterator was implemented using a generator.
> Or, if the generator implementation is actually important
> (because it is used as a
> coroutine) one could also explicitly typehint against it:
> `public Generator getCoroutine() { ... }`.
>
Yes. Quick example...
interface A
{
function gen();
}
class AImplementation implements A
{
function gen()
{
for($i = 0; $i < 10; ++$i)
yield $i;
}
}
class ADecorator implements A
{
private $a;
function __construct(A $a)
{
$this->a = $a;
}
function gen()
{
return $this->a->gen();
}
}
$a = new ADecorator(new AImplementation());
foreach($a->gen() as $v)
echo $v, "\n";
Obviously, AImplementation::gen() is a generator, but
ADecorator::gen() isn't, but would want both to adhere to the same
interface.
So only return type hinting makes sense.
> But return-value type hints are not directly related to generators.
> They are a more general concept. If that's what all of you
> want, then I'd recommend opening up a new thread for it.
>
> > You could not decorate it and rely instead on the presence of the
> > yield keyword, but parsers will thank knowing about it from
> the start
> > rather than realising at mid-parsing that the function is a
> completely
> > different beast.
> No, parsers don't care about this. It's trivial to detect in
> both cases.
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List To
> unsubscribe, visit: http://www.php.net/unsub.php
>
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Rasmus Lerdorf:
> So how about something like this:
>
> generator function f() {
> echo "Hello World";
> }
>
> generator function f() {
> return 1;
> }
>
> generator function f($arg) {
> if(f!$arg) yield 1;
> else if($arg<0) return 1;
> else return;
> }
>
> What does the generator keyword mean in each of these cases? Anything?
> Nothing? Would I see a difference either at compile-time or at execute
> time if I left it out?
An excellent argument to use "yield" where it is needed, instead
of using "generator" at the top.
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
On Mon, Aug 20, 2012 at 3:48 PM, Rasmus Lerdorf wrote:
> On 08/20/2012 07:56 AM, Ángel González wrote:
> > On 20/08/12 02:01, Rasmus Lerdorf wrote:
> >> I would still like to understand what this generator keyword would
> >> actually do. I don't see how it would work. Would a function marked
> >> generator somehow not be allowed to return normally or to finish and not
> >> return anything? How could this be enforced? I am completely against any
> >> keyword that is essentially documentation-only.
> >>
> >> -Rasmus
> > Given that such function could "return several times", seems a different
> > enough function type to have its keyword.
> > You could not decorate it and rely instead on the presence of the yield
> > keyword, but parsers will thank knowing about it from the start rather
> > than realising at mid-parsing that the function is a completely
> > different beast.
>
> So how about something like this:
>
> generator function f() {
> echo "Hello World";
> }
>
> generator function f() {
> return 1;
> }
>
> generator function f($arg) {
> if(f!$arg) yield 1;
> else if($arg<0) return 1;
> else return;
> }
>
> What does the generator keyword mean in each of these cases? Anything?
> Nothing? Would I see a difference either at compile-time or at execute
> time if I left it out?
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I still don't think that we shall separate it into two different keywords,
and even if so - we shall still reserve the ability to use return.
Think of this case:
function keywordsInFile($file, $keyword) {
if ( ($han = fopen($file, 'r') === FALSE ) {
return; // <-- this is better than starting to wrap the
function with if-else
}
while(!feof(...)) {
foreach ($keywords as $k) {
if ( strpos($k, $line) !== FALSE ) { yield $k; }
}
}
}
Though it's not the best example and I can think about more complicated -
it can reveal my point - I wish to use the "return" keyword in order to
stop the current function run. In many complicated sites you got many
if-else cases in one function that when the statement evaluates to
true/false you shall return from the function.
Structure like
if ( ... ) {
if ( ! ... ) {
if ( ) {
if ( ... ) {
yield $v;
}
}
}
}
is ugly and make the program harder to read than
if ( ! ... ) return;
if ( ... ) return;
if (! ... ) return;
if ( ! ... ) return;
yield $k;
Re: [PHP-DEV] [RFC] Generators
On Mon, Aug 20, 2012 at 1:56 PM, Ángel González wrote:
> On 20/08/12 02:01, Rasmus Lerdorf wrote:
>> I would still like to understand what this generator keyword would
>> actually do. I don't see how it would work. Would a function marked
>> generator somehow not be allowed to return normally or to finish and not
>> return anything? How could this be enforced? I am completely against any
>> keyword that is essentially documentation-only.
>>
>> -Rasmus
> Given that such function could "return several times", seems a different
> enough function type to have its keyword.
The method signature defines the API, so the caller knows what to use.
Can we agree on that? In this case it makes absolutely no difference
to the caller whether the function is implemented using a generator,
or whether it returns a custom Iterator object. The "generator"
keyword wouldn't document the API, it would document an
implementation-detail.
What would *actually* make sense here are return value typehints. E.g.
one could have something like `public Iterator getIterator() { ... }`.
This would provide the caller with information on what the function
returns, but would leave out the implementation detail that the
Iterator was implemented using a generator. Or, if the generator
implementation is actually important (because it is used as a
coroutine) one could also explicitly typehint against it: `public
Generator getCoroutine() { ... }`.
But return-value type hints are not directly related to generators.
They are a more general concept. If that's what all of you want, then
I'd recommend opening up a new thread for it.
> You could not decorate it and rely instead on the presence of the yield
> keyword, but parsers will thank knowing about it from the start rather
> than realising at mid-parsing that the function is a completely
> different beast.
No, parsers don't care about this. It's trivial to detect in both cases.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Rasmus Lerdorf wrote:
So how about something like this:
generator function f() {
echo "Hello World";
}
generator function f() {
return 1;
}
generator function f($arg) {
if(f!$arg) yield 1;
else if($arg<0) return 1;
else return;
}
What does the generator keyword mean in each of these cases? Anything?
Nothing? Would I see a difference either at compile-time or at execute
time if I left it out?
Well the same could be said of some of the error messages generated by 'static'
if E_STRICT is enabled. However an error on the first two saying 'no yield point
found' would not be unreasonable. In reality a lot of this should simply be
handled by a good IDE leaving the runtime code as clean as possible?
For the third one ... I'm still waiting for some clarification on how yield is
SUPPOSED to work anyway? If you are using a 'generator' to return a sequence of
data elements, then just what does happen between each call to the generator ...
DOES the generator get called for each value until something flags there are no
more? I still don't see the advantage of restructuring how things are called to
get around a problem which can just as easily be solved by proper design in the
first place.
--
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] Generators
On 08/20/2012 07:56 AM, Ángel González wrote:
> On 20/08/12 02:01, Rasmus Lerdorf wrote:
>> I would still like to understand what this generator keyword would
>> actually do. I don't see how it would work. Would a function marked
>> generator somehow not be allowed to return normally or to finish and not
>> return anything? How could this be enforced? I am completely against any
>> keyword that is essentially documentation-only.
>>
>> -Rasmus
> Given that such function could "return several times", seems a different
> enough function type to have its keyword.
> You could not decorate it and rely instead on the presence of the yield
> keyword, but parsers will thank knowing about it from the start rather
> than realising at mid-parsing that the function is a completely
> different beast.
So how about something like this:
generator function f() {
echo "Hello World";
}
generator function f() {
return 1;
}
generator function f($arg) {
if(f!$arg) yield 1;
else if($arg<0) return 1;
else return;
}
What does the generator keyword mean in each of these cases? Anything?
Nothing? Would I see a difference either at compile-time or at execute
time if I left it out?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
On 20/08/12 02:01, Rasmus Lerdorf wrote: > I would still like to understand what this generator keyword would > actually do. I don't see how it would work. Would a function marked > generator somehow not be allowed to return normally or to finish and not > return anything? How could this be enforced? I am completely against any > keyword that is essentially documentation-only. > > -Rasmus Given that such function could "return several times", seems a different enough function type to have its keyword. You could not decorate it and rely instead on the presence of the yield keyword, but parsers will thank knowing about it from the start rather than realising at mid-parsing that the function is a completely different beast. Regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
hi Rasmus! On Mon, Aug 20, 2012 at 2:01 AM, Rasmus Lerdorf wrote: > I would still like to understand what this generator keyword would > actually do. I don't see how it would work. Would a function marked > generator somehow not be allowed to return normally or to finish and not > return anything? How could this be enforced? I am completely against any > keyword that is essentially documentation-only. It is not documentation only (or should not but I have to check the implementation). It allows the use of the generators features inside this function. Just like what we have for static methods and this (somehow). Also I would really not begin to totally rethink the way generators work or are defined. There are clean and known ways in other languages, the closer we get from them the easier it will be to learn how to use them in PHP. 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
[PHP-DEV] Re: Need Help in Yaf spreading
CC to php-general. thanks On Mon, Aug 20, 2012 at 4:06 PM, Laruence wrote: > Hi: > Yaf (http://pecl.php.net/yaf) is a PHP MVC framework, which is > build as a PHP extension. > > It could be considered as the fastest PHP framework for > now(http://www.laruence.com/2011/12/02/2333.html), > > and it has already been used in a lots of productions in baidu, > sina. like weibo.com. > > we gain 76% performance boost while refactor weibo.com based on > yaf ( of course and some other improvements) > > so, I can say that Yaf is very popular in chinese world. but it > was a little hysteretic in english world. > > I asked for some help in sepreading Yaf in english world. any > recommends of Yaf (post, twitter, etc) will be appreciated. > > thanks > > -- > Laruence Xinchen Hui > http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Need Help in Yaf spreading
Hi: Yaf (http://pecl.php.net/yaf) is a PHP MVC framework, which is build as a PHP extension. It could be considered as the fastest PHP framework for now(http://www.laruence.com/2011/12/02/2333.html), and it has already been used in a lots of productions in baidu, sina. like weibo.com. we gain 76% performance boost while refactor weibo.com based on yaf ( of course and some other improvements) so, I can say that Yaf is very popular in chinese world. but it was a little hysteretic in english world. I asked for some help in sepreading Yaf in english world. any recommends of Yaf (post, twitter, etc) will be appreciated. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
