Re: [PHP-DEV] shared mysqlnd extension ...
Rasmus Lerdorf wrote: 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. OK that is the key piece of information I was missing. I though we had got over the 'needs to be built in' and had made it optional! I asked originally on php-general and was pointed to Fixed bug http://bugs.php.net/55609 (mysqlnd cannot be built shared). (Johannes) This specifically say ... "It's also possible to use --enable-mysqlnd=shared" SO I simply assumed that was the case, it does not give an error message like other miss configurations do ... AH - JUST use --enable-mysqlnd=shared and don't add the mysqli shared module at the same time and the core build happily creates a shared module! But ... "Unable to load dynamic library '/opt/php5/ext/mysqlnd.so' - /opt/php5/ext/mysqlnd.so: undefined symbol: executor_globals in Unknown on line 0" THIS the same problem I get if I don't recompile the extensions after changing the core build and the feedback was that this is because of using incompatible php-config files! So should I be updating that bug to the current state of play? That this is actually by design? Or create a new bug that states that '--enable-mysqlnd=shared' should not be allowed? Or is there some third position in this jigsaw? Anyway I now have parallel apache modules one with and one without mysqlnd ... after screwing up the entire machine because I forgot that php overwrites the modules in apache even with apache running :( Now to move all the mysql data over ... -- 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
Hi
2012/8/21 Tjerk Anne Meesters :
> 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.
Int would be better and callable should be accepted like array_walk().
It's better to have array_delete_recursive(), too.
I updated the page.
array_add() needs more discussion.
What we should do with array value, accept callable or not, etc.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
>
>
>>
>>
>>
>> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shared mysqlnd extension ...
Em 2012-08-21 10:41, Lester Caine escreveu: SO I simply assumed that was the case, it does not give an error message like other miss configurations do ... AH - JUST use --enable-mysqlnd=shared and don't add the mysqli shared module at the same time and the core build happily creates a shared module! But ... "Unable to load dynamic library '/opt/php5/ext/mysqlnd.so' - /opt/php5/ext/mysqlnd.so: undefined symbol: executor_globals in Unknown on line 0" THIS the same problem I get if I don't recompile the extensions after changing the core build and the feedback was that this is because of using incompatible php-config files! So should I be updating that bug to the current state of play? That this is actually by design? Or create a new bug that states that '--enable-mysqlnd=shared' should not be allowed? Or is there some third position in this jigsaw? It usually helps that the extension you compile is binary compatible with the PHP build you're loading it in. In your case, I'd guess you compiled PHP with ZTS support but mysqlnd without. As to whether '--enable-mysqlnd=shared' actually works or not I can't be sure as I haven't tested it. But there's nothing in the problem you're having that points to it not working when built properly. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] On the general standard of discussion...
Hello there, Recently we have seen many extremely long discussion threads here on internals. While discussion is good, much of these threads are filled with noise, pointless arguing that has little merit. NikiC calls them pseudo-arguments, I call it a pantomime: Someone will raise a point, someone will disagree, someone will agree with the first person, someone else will disagree, and so on. A point gets raised, a counter-point is made, and this is seemingly repeated ad nauseum. I am guilty of participating in this, that is true, but I'm stopping now and I hope you will too. If there's a point that needs raising, raise it. If you have a counter-point, make it. But please, let's avoid a "Oh yes it is!" "Oh no it isn't!" pantomime here, and bring up issues once, not 20 times. Further more, if all the points have been established, it might be worth just making an RFC and voting on it. Because no sane person could keep track of the Generators thread just now with its ridiculous length. Thank you. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shared mysqlnd extension ...
Gustavo Lopes wrote: So should I be updating that bug to the current state of play? That this is actually by design? Or create a new bug that states that '--enable-mysqlnd=shared' should not be allowed? Or is there some third position in this jigsaw? It usually helps that the extension you compile is binary compatible with the PHP build you're loading it in. In your case, I'd guess you compiled PHP with ZTS support but mysqlnd without. As to whether '--enable-mysqlnd=shared' actually works or not I can't be sure as I haven't tested it. But there's nothing in the problem you're having that points to it not working when built properly. Current situation is that I've run a clean build of the Apache module with mysqlnd included statically, and the mysqli extension is compiled as shared. If I add the '--enable-mysqlnd=shared' then it does build a shared mysqlnd module, but the module is unusable due to the 'executor_globals' error, so either there should be no option TO build shared? Or the problem in the shared module needs fixing? What was causing me more confusion ( for the last two hours ) was that I could not get the remote machine to connect to the database, so I was not sure if the mysqli module was working at all. I've had to 'create' an extra set of users on the PHP5.4 machine as 'localhost' will not work as a connection. I've found some references to needing to use the ip address, and with some juggling I now have a working connection on that machine via the domain name ... finally. -- 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 ...
Em 2012-08-21 14:10, Lester Caine escreveu: Gustavo Lopes wrote: So should I be updating that bug to the current state of play? That this is actually by design? Or create a new bug that states that '--enable-mysqlnd=shared' should not be allowed? Or is there some third position in this jigsaw? It usually helps that the extension you compile is binary compatible with the PHP build you're loading it in. In your case, I'd guess you compiled PHP with ZTS support but mysqlnd without. As to whether '--enable-mysqlnd=shared' actually works or not I can't be sure as I haven't tested it. But there's nothing in the problem you're having that points to it not working when built properly. Current situation is that I've run a clean build of the Apache module with mysqlnd included statically, and the mysqli extension is compiled as shared. If I add the '--enable-mysqlnd=shared' then it does build a shared mysqlnd module, but the module is unusable due to the 'executor_globals' error, so either there should be no option TO build shared? Or the problem in the shared module needs fixing? I've just tried to compile mysqlnd and mysqli shared and it worked (at least sapi/cli/php -n -d extension_dir=modules -d extension=mysqlnd.so -d extension=mysqli.so -i showed no problems). It is at least conceivable that there's some bug I'm not hitting. In any case, this is a development mailing list. So you can either try to figure out the problem yourself using this mailing list asking for pointers if necessary -- that means actually checking the source code, inspecting symbols in the binaries, preprocessor defines after configure etc. -- or you can file a bug report with clear, complete steps for reproducing the problem. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] UTF-8 files and include
Hello, Some of my users & contributors have met an issue with files containing UTF-8 on certain Windows configurations (but they actually did not found the difference). Any idea why? The issue does not appear on Linux, BSD or Mac OS system, only for certain Windows. What do we need to check? --enable-zend-multibyte, some php.ini magic parameters, some ENV variables? Best regards. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UTF-8 files and include
On 08/21/2012 09:10 AM, Ivan Enderlin @ Hoa wrote: > Hello, > > Some of my users & contributors have met an issue with files containing > UTF-8 on certain Windows configurations (but they actually did not found > the difference). Any idea why? > The issue does not appear on Linux, BSD or Mac OS system, only for > certain Windows. > > What do we need to check? --enable-zend-multibyte, some php.ini magic > parameters, some ENV variables? What kind of issue? Perhaps they are leaving in the BOM? Tell them to configure their editors to not add a BOM. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
On Tue, Aug 21, 2012 at 12:31 AM, Lester Caine wrote:
> 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?
>
> No one is frowning on this way of doing things. It's perfectly fine for
the circumstances. Imagine however, that you have a new client, who
provides a different format in their clientdatabase.csv. There are
definitely ways you can handle this in your current code. But with
generators you might be able to do:
function origFormat()
{
$handle = fopen("../data/clientdatabase.csv", "r");
if ( $handle == FALSE) {
return false;
} else {
$row = fgetcsv($handle, 800, ",");
if($row !== false)
yield fgetcsv($handle, 800, ",");
}
}
function strangeFormat()
{
$data = origFormat();
foreach($data as $row)
{
//move some fields around to match the original format
yield $row;
}
}
if($client == 'strange')
$data = strangeFormat();
else
$data = origFormat();
foreach($data as $row)
{
$contact->ContactRecordLoad($data);
}
Another possibility is that you are importing records from another
database, and now you can create a third generator that pulls from the db.
The point is that your data source(the producer) is abstracted from the
consumer, so the consumer doesn't need to have the logic to handle the
different cases inside its (possibly complicated) foreach() loop. And the
producer can be a simple function, rather than an object that implements
the Iterator interface.
Again, the case you've cited is probably not a case where generators give
much advantage. But anytime the logic to produce some data becomes more
complicated (Imagine that you needed to skip some of the lines in the .csv
file based on some kind of filter), then being able to extricate the
producer logic from the consumer logic is helpful.
Thanks,
John
Re: [PHP-DEV] re: removing an item from an array
On Tue, Aug 21, 2012 at 3:36 AM, Yasuo Ohgaki wrote: > Hi > > 2012/8/21 Tjerk Anne Meesters : >> 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. > > Int would be better and callable should be accepted like array_walk(). > It's better to have array_delete_recursive(), too. > I updated the page. > > array_add() needs more discussion. > What we should do with array value, accept callable or not, etc. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > I'm against this RFC, but if you are going to even try to add something, please keep it consistent! Don't modify `array_delete` to take a callable, instead make a different function `array_udelete` or something. And keep default $strict values consistent with existing functions that have that parameter. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
John LeSueur wrote: Again, the case you've cited is probably not a case where generators give much advantage. But anytime the logic to produce some data becomes more complicated (Imagine that you needed to skip some of the lines in the .csv file based on some kind of filter), then being able to extricate the producer logic from the consumer logic is helpful. But in my 'method of working' one simply changes the '$contact->' object and loads the one that matches the data you are handling. Sage, paypal, moneybox, nlpg and so on. I've a dozen or so data models currently. "skip some of the lines" simply equates to saving or not some of the detail lines such as shopping basket details on paypal or property details in nlpg. The base RecordLoad takes care of that but in reality one always saves all of the data, and later access to the database provides any filtering required when processing results for the screen. I suppose that the 'producer logic' is populating the database, while the 'consumer logic' is later reading that data back - filtered as required. If I was keeping everything in memory things would probably be different ... but I still can't see why the work flow has to be reorganised rather than simply following the natural flow that the job requires. Adding 'yield' how ever it's added loads additional development work on all of the ancillary tools many of which still haven't caught up with the 5.3 extras let alone 5.4, and doesn't seem to provide any outstanding advantages? -- 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 ...
Gustavo Lopes wrote: I've just tried to compile mysqlnd and mysqli shared and it worked (at least sapi/cli/php -n -d extension_dir=modules -d extension=mysqlnd.so -d extension=mysqli.so -i showed no problems). Correct, it compiles fine, but what setup are you running your mysqlnd.so on? This may simply be a problem with the Apache module build, but trying to include mysqlnd.so gives an error and Apache It is at least conceivable that there's some bug I'm not hitting. In any case, this is a development mailing list. So you can either try to figure out the problem yourself using this mailing list asking for pointers if necessary -- that means actually checking the source code, inspecting symbols in the binaries, preprocessor defines after configure etc. -- or you can file a bug report with clear, complete steps for reproducing the problem. https://bugs.php.net/bug.php?id=62880 -- 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
Dearest Lester, I know you don't understand generators. You've posted multiple times about it. And you know what? It's okay; you don't have to understand them. I do understand generators and would LOVE to have them available for some of the things I do in my line of work; that's perfectly fine too. Your Friend, Levi Morrison -- 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 Levi Morrison : > On Tue, Aug 21, 2012 at 3:36 AM, Yasuo Ohgaki wrote: >> Hi >> >> 2012/8/21 Tjerk Anne Meesters : >>> 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. >> >> Int would be better and callable should be accepted like array_walk(). >> It's better to have array_delete_recursive(), too. >> I updated the page. >> >> array_add() needs more discussion. >> What we should do with array value, accept callable or not, etc. >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net >> > > I'm against this RFC, but if you are going to even try to add > something, please keep it consistent! Don't modify `array_delete` to > take a callable, instead make a different function `array_udelete` or > something. > Original proposal is adding array_delete() and this is under discussion. We don't have to add array_add() > And keep default $strict values consistent with existing functions > that have that parameter. Users should use array_walk() when they would like to delete element(s). To be consistent, it should be callable. 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
On Tue, Aug 21, 2012 at 12:53 PM, Yasuo Ohgaki wrote: > 2012/8/21 Levi Morrison : >> >> I'm against this RFC, but if you are going to even try to add >> something, please keep it consistent! Don't modify `array_delete` to >> take a callable, instead make a different function `array_udelete` or >> something. >> > > Original proposal is adding array_delete() and this is under discussion. > We don't have to add array_add() > >> And keep default $strict values consistent with existing functions >> that have that parameter. > > Users should use array_walk() when they would like to delete element(s). > To be consistent, it should be callable. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net I didn't say anything about `array_add`. I meant to say if you are going to try to add something to the core that you need to be consistent with the other array functions. Why use `array_walk` to delete elements? Isn't the whole point of `array_delete` to make that process easier? I think you missed the whole point of my last message: keep the functions you propose similar to ones that already exist. -- 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/22 Levi Morrison : > On Tue, Aug 21, 2012 at 12:53 PM, Yasuo Ohgaki wrote: >> 2012/8/21 Levi Morrison : >>> >>> I'm against this RFC, but if you are going to even try to add >>> something, please keep it consistent! Don't modify `array_delete` to >>> take a callable, instead make a different function `array_udelete` or >>> something. >>> >> >> Original proposal is adding array_delete() and this is under discussion. >> We don't have to add array_add() >> >>> And keep default $strict values consistent with existing functions >>> that have that parameter. >> >> Users should use array_walk() when they would like to delete element(s). >> To be consistent, it should be callable. >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net > > I didn't say anything about `array_add`. I meant to say if you are > going to try to add something to the core that you need to be > consistent with the other array functions. > > Why use `array_walk` to delete elements? Isn't the whole point of > `array_delete` to make that process easier? > The reason why use array_walk is this is the best way to delete elements with PHP. >From the Stack Overflow's page (and this thread), we can tell the problem is lack of intuitive API for array element deletion. > I think you missed the whole point of my last message: keep the > functions you propose similar to ones that already exist. That's my point, too. array_walk() is there from PHP3 at least, IIRC. array_delete() is easier to use, too. i.e. No "use (&$array)" for closure and counter variable when user would like to know how many elements were deleted. 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
On 21/08/12 10:36, Yasuo Ohgaki wrote:
Hi
2012/8/21 Tjerk Anne Meesters :
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.
Int would be better and callable should be accepted like array_walk().
It's better to have array_delete_recursive(), too.
I updated the page.
Callable? What? This is to remove a single value, like a set. If you
want to remove based on a function, array_walk() is always available.
And allowing a callable would prevent you from removing closures or
strings! D:
array_add() needs more discussion.
What we should do with array value, accept callable or not, etc.
Why accept a callable?
I don't think it needs more discussion, I can't see how it could be made
any better than it currently is.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
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
--
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
Hi
2012/8/22 Andrew Faulds :
> On 21/08/12 10:36, Yasuo Ohgaki wrote:
>>
>> Int would be better and callable should be accepted like array_walk().
>> It's better to have array_delete_recursive(), too.
>> I updated the page.
>
> Callable? What? This is to remove a single value, like a set. If you want to
> remove based on a function, array_walk() is always available. And allowing a
> callable would prevent you from removing closures or strings! D:
Original proposal was to delete all value that matches.
It's not delete a single value.
We could choose to remove only 1st element, but is it useful?
People may do
while (array_delete($array, "do not needed"));
This is stupid O(n^2) code.
>
>>
>> array_add() needs more discussion.
>> What we should do with array value, accept callable or not, etc.
>
> Why accept a callable?
> I don't think it needs more discussion, I can't see how it could be made any
> better than it currently is.
What's the point of adding NEW feature with less extensible against competitor?
Take a look at Ruby's delete_if()
With callable, one could do
$array = [1,2,3,4,5,6,7,8];
$cnt = array_delete($array, function($v) { if ($v <== 4) return true; });
var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
With array_walk()
$array = [1,2,3,4,5,6,7,8];
$cnt = 0;
array_walk($array, function($v) use (&$array, &$cnt) { if ($v <== 4)
{$cnt++; return true;) });
var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
As I mentioned earlier, array_walk() is the best way to delete elements with PHP
more than a decade. It should be mentioned the Stack Overflow page,
but it's not.
It's just like adding
array_pop()/array_push()/array_shift()/array_unshift() while
we have array_slice()/array_splice().
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
On 21/08/12 21:00, Yasuo Ohgaki wrote:
Hi
2012/8/22 Andrew Faulds :
On 21/08/12 10:36, Yasuo Ohgaki wrote:
Int would be better and callable should be accepted like array_walk().
It's better to have array_delete_recursive(), too.
I updated the page.
Callable? What? This is to remove a single value, like a set. If you want to
remove based on a function, array_walk() is always available. And allowing a
callable would prevent you from removing closures or strings! D:
Original proposal was to delete all value that matches.
It's not delete a single value.
Treats it like a set, removes all but in practice only one will go if
properly formed set.
We could choose to remove only 1st element, but is it useful?
People may do
while (array_delete($array, "do not needed"));
This is stupid O(n^2) code.
OK.
array_add() needs more discussion.
What we should do with array value, accept callable or not, etc.
Why accept a callable?
I don't think it needs more discussion, I can't see how it could be made any
better than it currently is.
What's the point of adding NEW feature with less extensible against competitor?
Take a look at Ruby's delete_if()
With callable, one could do
$array = [1,2,3,4,5,6,7,8];
$cnt = array_delete($array, function($v) { if ($v <== 4) return true; });
var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
Yes, but you seem to be ignoring me. I don't want that, because then I
can't remove items a set containing strings or other callables, using
this function.
We already have array_walk() and array_filter().
With array_walk()
$array = [1,2,3,4,5,6,7,8];
$cnt = 0;
array_walk($array, function($v) use (&$array, &$cnt) { if ($v <== 4)
{$cnt++; return true;) });
var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
As I mentioned earlier, array_walk() is the best way to delete elements with PHP
more than a decade. It should be mentioned the Stack Overflow page,
but it's not.
It's just like adding
array_pop()/array_push()/array_shift()/array_unshift() while
we have array_slice()/array_splice().
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Andrew Faulds
http://ajf.me/
--
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)
Am 20.08.2012 23:13, schrieb Lester Caine: 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 ... I am glad you like the idea!;) although "boilerplate" does seem to leave a metallic aftertaste in my mouth. especially now that the vast majority of third party tutorials are no longer suitable? Rasmus has pointed out the same problem only in the Are you referring to "Rasmus Schultz" from the "removing an item from an array" thread? As far as I understood, Rasmus is arguing in favor of having more functionality built into core, while I am arguing, that a lot of functionality should go into the documentation first, as a userland implementation. I am not sure I understand what you're getting at. 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. You mean that when you're googling you get bad results, because of the whitespread use of php? I know what you mean. If good and proven examples of common problems would be within the official documentation, no googling would be necessary. 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. Personally I have never used PEAR, so I can't say anything about the situation there, but I can imagine that maintaining such a large codebase has it's disadvantages. This could probably happen to my idea as well...causing lots of necessary maintenance-work, I mean. But since its userland code, lots of people can work on the problem. Also the kind of code I'd like to see there is very concise and bare-bones, so it probably won't need much adjustment to new php-versions. 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. That's something I thought of too. If some functionality becomes very popular (difficult to measure, I guess) it could go into core, AFTER it's proven its worth in real-world applications. -- 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
2012/8/22 Andrew Faulds :
> On 21/08/12 21:00, Yasuo Ohgaki wrote:
>>
>> Hi
>>
>> 2012/8/22 Andrew Faulds :
>>>
>>> On 21/08/12 10:36, Yasuo Ohgaki wrote:
Int would be better and callable should be accepted like array_walk().
It's better to have array_delete_recursive(), too.
I updated the page.
>>>
>>> Callable? What? This is to remove a single value, like a set. If you want
>>> to
>>> remove based on a function, array_walk() is always available. And
>>> allowing a
>>> callable would prevent you from removing closures or strings! D:
>>
>> Original proposal was to delete all value that matches.
>> It's not delete a single value.
>
> Treats it like a set, removes all but in practice only one will go if
> properly formed set.
>
>> We could choose to remove only 1st element, but is it useful?
>> People may do
>>
>> while (array_delete($array, "do not needed"));
>>
>> This is stupid O(n^2) code.
>
> OK.
>
>>
array_add() needs more discussion.
What we should do with array value, accept callable or not, etc.
>>>
>>> Why accept a callable?
>>> I don't think it needs more discussion, I can't see how it could be made
>>> any
>>> better than it currently is.
>>
>> What's the point of adding NEW feature with less extensible against
>> competitor?
>> Take a look at Ruby's delete_if()
>>
>> With callable, one could do
>>
>> $array = [1,2,3,4,5,6,7,8];
>> $cnt = array_delete($array, function($v) { if ($v <== 4) return true; });
>> var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
>
> Yes, but you seem to be ignoring me. I don't want that, because then I can't
> remove items a set containing strings or other callables, using this
> function.
All element value and key are passed to function, you may remove any
type of data if array_delete() accepts only callable. That's the reason
why I suggest to accept callable only.
Users should get used to closure/functional programming anyway.
>
> We already have array_walk() and array_filter().
>
>> With array_walk()
>>
>> $array = [1,2,3,4,5,6,7,8];
>> $cnt = 0;
>> array_walk($array, function($v) use (&$array, &$cnt) { if ($v <== 4)
>> {$cnt++; return true;) });
>> var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
Oops, it should unset().
$array = [1,2,3,4,5,6,7,8];
$cnt = 0;
array_walk($array, function($v, $k) use (&$array, &$cnt) { if ($v <==
4) {$cnt++; unset($array[$k];} });
var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
The problem is "Many PHP users do not know the best way to delete elements,
while there is array_walk() for a long long time.", isn't it?
Providing an intuitive
and easier API for basic operation should be the solution, not providing
simple method.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
>>
>> As I mentioned earlier, array_walk() is the best way to delete elements
>> with PHP
>> more than a decade. It should be mentioned the Stack Overflow page,
>> but it's not.
>>
>> It's just like adding
>> array_pop()/array_push()/array_shift()/array_unshift() while
>> we have array_slice()/array_splice().
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>
>
>
> --
> 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
On 21/08/12 21:32, Yasuo Ohgaki wrote:
2012/8/22 Andrew Faulds :
On 21/08/12 21:00, Yasuo Ohgaki wrote:
Hi
2012/8/22 Andrew Faulds :
On 21/08/12 10:36, Yasuo Ohgaki wrote:
Int would be better and callable should be accepted like array_walk().
It's better to have array_delete_recursive(), too.
I updated the page.
Callable? What? This is to remove a single value, like a set. If you want
to
remove based on a function, array_walk() is always available. And
allowing a
callable would prevent you from removing closures or strings! D:
Original proposal was to delete all value that matches.
It's not delete a single value.
Treats it like a set, removes all but in practice only one will go if
properly formed set.
We could choose to remove only 1st element, but is it useful?
People may do
while (array_delete($array, "do not needed"));
This is stupid O(n^2) code.
OK.
array_add() needs more discussion.
What we should do with array value, accept callable or not, etc.
Why accept a callable?
I don't think it needs more discussion, I can't see how it could be made
any
better than it currently is.
What's the point of adding NEW feature with less extensible against
competitor?
Take a look at Ruby's delete_if()
With callable, one could do
$array = [1,2,3,4,5,6,7,8];
$cnt = array_delete($array, function($v) { if ($v <== 4) return true; });
var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
Yes, but you seem to be ignoring me. I don't want that, because then I can't
remove items a set containing strings or other callables, using this
function.
All element value and key are passed to function, you may remove any
type of data if array_delete() accepts only callable. That's the reason
why I suggest to accept callable only.
Users should get used to closure/functional programming anyway.
Yes, but I think this completely destroys the convenience of it. You
might as well just use array_walk if it only supports callable. And
array_walk is fine. array_delete should remove a value, not values
according to a condition.
We already have array_walk() and array_filter().
With array_walk()
$array = [1,2,3,4,5,6,7,8];
$cnt = 0;
array_walk($array, function($v) use (&$array, &$cnt) { if ($v <== 4)
{$cnt++; return true;) });
var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
Oops, it should unset().
$array = [1,2,3,4,5,6,7,8];
$cnt = 0;
array_walk($array, function($v, $k) use (&$array, &$cnt) { if ($v <==
4) {$cnt++; unset($array[$k];} });
var_dump($cnt, $array); // $cnt = 4, $array = [5,6,7,8]
The problem is "Many PHP users do not know the best way to delete elements,
while there is array_walk() for a long long time.", isn't it?
Providing an intuitive
and easier API for basic operation should be the solution, not providing
simple method.
Er, so you're advocating adding another method to do the same thing? Why?
The whole point of this was to allow people to use arrays like sets, or
easily remove list items. Not encourage people to use functional
programming.
Sure, people should use array_walk, but you've got to be kidding me if I
you think I would honestly accept using this to remove array items by value:
array_delete($array, function ($value) { return ($value == "that
value"); });
I might as well use array_walk if we're going down this route. You seem
to want to subvert the usefulness of this function and just provide an
array_walk shorthand with less functionality.
What I want is this:
array_delete($array, "that value");
Much more readable, does what you expect, and provides a significant,
noticeable value over array_walk here.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
As I mentioned earlier, array_walk() is the best way to delete elements
with PHP
more than a decade. It should be mentioned the Stack Overflow page,
but it's not.
It's just like adding
array_pop()/array_push()/array_shift()/array_unshift() while
we have array_slice()/array_splice().
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Andrew Faulds
http://ajf.me/
--
Andrew Faulds
http://ajf.me/
--
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)
Hi, Nice to see my name not only in my signature ;) I've not much to say right now, but what you wrote was slightly in my mind, when I wrote the other mail. I'll keep an eye on it (at least ;)). Regards, Sebastian 2012/8/20 Lars Schultz > 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] Official Userland Library (was: removing an item from an array)
Am 20.08.2012 22:51, schrieb Andrew Faulds: On 20/08/12 21:43, Lars Schultz wrote: 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) I don't think it's ridiculous because every core functionality to be implemented and maintained causes some php-dev to invest time on something, which is not absolutely necessary because it could be done, with some additional work, in userland. There is a lot of functionality, that can not be reasonably well implemented in userland, and php-dev time should be used on such cases, no? With my suggestion, any php-user could suggest a functionality he feels is missing to go not into core but into the documentation, with a suggestion of how to solve the problem. Therefore the bar, which decides wether something is worthy of going into core could stay as high as it is, but it could be lower for something that goes into the documentation as an example. 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. Therein lies the crux of it all...how much is too much or too little. Who's to say? It's a matter of personal preference, I believe. That's why such features will always trigger those discussions. Because it depends on one's programming style...of which there are various, various good ones, even if not always compatible. That said, not every possible function has a compelling case for addition, simply because it does something too obscure or is impractical. Sometimes that is obvious and then the discussion will be short or not even starts. But mostly it's not. -- 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 21/08/12 21:44, Lars Schultz wrote:
Am 20.08.2012 22:51, schrieb Andrew Faulds:
On 20/08/12 21:43, Lars Schultz wrote:
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)
I don't think it's ridiculous because every core functionality to be
implemented and maintained causes some php-dev to invest time on
something, which is not absolutely necessary because it could be done,
with some additional work, in userland. There is a lot of
functionality, that can not be reasonably well implemented in
userland, and php-dev time should be used on such cases, no?
With my suggestion, any php-user could suggest a functionality he
feels is missing to go not into core but into the documentation, with
a suggestion of how to solve the problem. Therefore the bar, which
decides wether something is worthy of going into core could stay as
high as it is, but it could be lower for something that goes into the
documentation as an example.
The problem is that these functions often improve the readability and
concise expressive power of PHP. Yes, you can import large libraries of
functions, but it is much more programmer-friendly not to.
Also, functions can often improve the *maintainability* of code, as
well. For instance, compare:
if (startswith($line, "") && endswith($line, "") {
with:
if (susbstr($line, 0, 7) === "" && substr($line, -8) ===
"") {
The first is more readable, and more maintainable, since you're not
dealing with manually specified string lengths, which can easily be wrong.
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.
Therein lies the crux of it all...how much is too much or too little.
Who's to say? It's a matter of personal preference, I believe. That's
why such features will always trigger those discussions. Because it
depends on one's programming style...of which there are various,
various good ones, even if not always compatible.
There seems to be a problem in here of "if I don't need it, nobody else
does". Of course the reverse "if I need it, everyone else should have it
in core" is also true, but I think the first point is a problem.
That said, not every possible function has a compelling case for
addition, simply because it does something too obscure or is
impractical.
Sometimes that is obvious and then the discussion will be short or not
even starts. But mostly it's not.
It quite often is obvious, I fear: the most vocal may often be the minority.
--
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
2012/8/22 Andrew Faulds :
> Er, so you're advocating adding another method to do the same thing? Why?
Because novices don't know about array_walk().
I think I've written this over and over in this thread.
> The whole point of this was to allow people to use arrays like sets, or
> easily remove list items. Not encourage people to use functional
> programming.
>
> Sure, people should use array_walk, but you've got to be kidding me if I you
> think I would honestly accept using this to remove array items by value:
>
> array_delete($array, function ($value) { return ($value == "that value");
> });
>
> I might as well use array_walk if we're going down this route. You seem to
> want to subvert the usefulness of this function and just provide an
> array_walk shorthand with less functionality.
>
> What I want is this:
>
> array_delete($array, "that value");
I do not want this ;)
What's wrong with extensible way? It's for PHP 5.5, not PHP 4.
array_delete($array, function ($v) { return ($v == "that value"); });
We can use ==, ===, <, >, <=, =>, <==, ==>, !=, !==, and so on.
We may pass them as parameter,
array_delete($array, "that value", "!==");
but it does not look a modern way to do and it is not extensible
like with callable.
Besides, how often we would like to delete elements based on
element's value? I guess it's not so often for most people.
> Much more readable, does what you expect, and provides a significant,
> noticeable value over array_walk here.
array_walk() is easy to use, IMHO.
People just don't know array_walk() can be used to delete
elements because of it's name.
As I wrote in sample code, new array_delete is an intuitive
name and convenient than array_walk. They are like
array_pop/array_push and array_slice/array_splice to me.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
>
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>>
As I mentioned earlier, array_walk() is the best way to delete elements
with PHP
more than a decade. It should be mentioned the Stack Overflow page,
but it's not.
It's just like adding
array_pop()/array_push()/array_shift()/array_unshift() while
we have array_slice()/array_splice().
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
>>>
>>>
>>>
>>> --
>>> Andrew Faulds
>>> http://ajf.me/
>>>
>
>
> --
> Andrew Faulds
> http://ajf.me/
>
--
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 23:13, schrieb Lester Caine: 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 ... I am glad you like the idea!;) although "boilerplate" does seem to leave a metallic aftertaste in my mouth. I run some model engineering sites ;) especially now that the vast majority of third party tutorials are no longer suitable? Rasmus has pointed out the same problem only in the Are you referring to "Rasmus Schultz" from the "removing an item from an array" thread? As far as I understood, Rasmus is arguing in favor of having more functionality built into core, while I am arguing, that a lot of functionality should go into the documentation first, as a userland implementation. I am not sure I understand what you're getting at. No Rasmus Lerdorf was sorting out a problem for someone who was 'following a tutorial' which was no longer correct. 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. You mean that when you're googling you get bad results, because of the whitespread use of php? I know what you mean. If good and proven examples of common problems would be within the official documentation, no googling would be necessary. Exactly ... 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. Personally I have never used PEAR, so I can't say anything about the situation there, but I can imagine that maintaining such a large codebase has it's disadvantages. This could probably happen to my idea as well...causing lots of necessary maintenance-work, I mean. But since its userland code, lots of people can work on the problem. Also the kind of code I'd like to see there is very concise and bare-bones, so it probably won't need much adjustment to new php-versions. Just spent the last two days getting a customers joomla sites working again ... first problem ... add error_reporting( E_ALL & ~E_STRICT & ~E_WARNING ); to the config file to hide all the errors and warnings. 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. That's something I thought of too. If some functionality becomes very popular (difficult to measure, I guess) it could go into core, AFTER it's proven its worth in real-world applications. I'm still having trouble finding out the preferred way to use some of the basics - stuff I've used for years but now throws warnings :( And a clean boilerplate design without some of the esoteric bells and whistles would be nice. -- 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)
2012/8/21 Andrew Faulds
> On 21/08/12 21:44, Lars Schultz wrote:
>
>> Am 20.08.2012 22:51, schrieb Andrew Faulds:
>>
>>> On 20/08/12 21:43, Lars Schultz wrote:
>>> 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)
>>>
>>
>> I don't think it's ridiculous because every core functionality to be
>> implemented and maintained causes some php-dev to invest time on something,
>> which is not absolutely necessary because it could be done, with some
>> additional work, in userland. There is a lot of functionality, that can not
>> be reasonably well implemented in userland, and php-dev time should be used
>> on such cases, no?
>>
>> With my suggestion, any php-user could suggest a functionality he feels
>> is missing to go not into core but into the documentation, with a
>> suggestion of how to solve the problem. Therefore the bar, which decides
>> wether something is worthy of going into core could stay as high as it is,
>> but it could be lower for something that goes into the documentation as an
>> example.
>>
>> The problem is that these functions often improve the readability and
> concise expressive power of PHP. Yes, you can import large libraries of
> functions, but it is much more programmer-friendly not to.
>
Really? Use composer and you'll not feel any difference. Don't use composer
and it will require a single 'include' from you. That is "much more
user-unfriendly"? At the end in both cases you will not feel any
difference. So where is this "readability and concise expressive power",
that is no possible with already existing userland tools?
>
> Also, functions can often improve the *maintainability* of code, as well.
> For instance, compare:
>
> if (startswith($line, "") && endswith($line, "") {
>
> with:
>
> if (susbstr($line, 0, 7) === "" && substr($line, -8) ===
> "") {
>
> The first is more readable, and more maintainable, since you're not
> dealing with manually specified string lengths, which can easily be wrong.
Yes, that are functions I can imagine can go into a php-based standard
library. They can even be more efficient than the self-made solution
(strncmp() is faster than substr() ;)) and the user of startsWith() and
endsWith() doesn't even need to take care.
>
> 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.
>>>
>>
>> Therein lies the crux of it all...how much is too much or too little.
>> Who's to say? It's a matter of personal preference, I believe. That's why
>> such features will always trigger those discussions. Because it depends on
>> one's programming style...of which there are various, various good ones,
>> even if not always compatible.
>>
> There seems to be a problem in here of "if I don't need it, nobody else
> does". Of course the reverse "if I need it, everyone else should have it in
> core" is also true, but I think the first point is a problem.
>
>
>> That said, not every possible function has a compelling case for
>>> addition, simply because it does something too obscure or is impractical.
>>>
>>
>> Sometimes that is obvious and then the discussion will be short or not
>> even starts. But mostly it's not.
>>
>> It quite often is obvious, I fear: the most vocal may often be the
> minority.
>
>
> --
> Andrew Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
github.com/KingCrunch
Re: [PHP-DEV] re: removing an item from an array
On 21/08/12 22:18, Yasuo Ohgaki wrote:
2012/8/22 Andrew Faulds :
Er, so you're advocating adding another method to do the same thing? Why?
Because novices don't know about array_walk().
I think I've written this over and over in this thread.
So publicise array_walk() then. Don't add a new function.
The whole point of this was to allow people to use arrays like sets, or
easily remove list items. Not encourage people to use functional
programming.
Sure, people should use array_walk, but you've got to be kidding me if I you
think I would honestly accept using this to remove array items by value:
array_delete($array, function ($value) { return ($value == "that value");
});
I might as well use array_walk if we're going down this route. You seem to
want to subvert the usefulness of this function and just provide an
array_walk shorthand with less functionality.
What I want is this:
array_delete($array, "that value");
I do not want this ;)
What's wrong with extensible way? It's for PHP 5.5, not PHP 4.
But we have array_walk().
array_delete($array, function ($v) { return ($v == "that value"); });
We can use ==, ===, <, >, <=, =>, <==, ==>, !=, !==, and so on.
We may pass them as parameter,
array_delete($array, "that value", "!==");
but it does not look a modern way to do and it is not extensible
like with callable.
No, it is a modern way. Modern and functional are not one and the same.
Besides, how often we would like to delete elements based on
element's value? I guess it's not so often for most people.
Uh, I thought that was the whole point of this suggestion. You seem to
want to subvert the original intentions (making it easier to remove list
items and treat arrays as sets), to providing a new functional mechanism
for removing lots of array items satisfying a criteria.
Much more readable, does what you expect, and provides a significant,
noticeable value over array_walk here.
array_walk() is easy to use, IMHO.
People just don't know array_walk() can be used to delete
elements because of it's name.
But adding a new function is NOT the solution. That is the job of
documentation. That's like saying "people have no idea what strstr is,
so let's make a new function with less functionality called
string_position!".
As I wrote in sample code, new array_delete is an intuitive
name and convenient than array_walk. They are like
array_pop/array_push and array_slice/array_splice to me.
It's nothing like those. array_pop() and array_push() are simple, they
take an array and an item to add. What's so terrible and evil and
complex about making array_delete() remove an item? Why does it have to
be functional and overcomplicated to do something we can already do,
instead of providing a simple and convenient mechanism to remove an item
by value?
I do not understand this. Especially since, by your method, you should
also provide a key since it provides no method to check item's key.
Sorry, I just do not understand how your suggestion is useful.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
As I mentioned earlier, array_walk() is the best way to delete elements
with PHP
more than a decade. It should be mentioned the Stack Overflow page,
but it's not.
It's just like adding
array_pop()/array_push()/array_shift()/array_unshift() while
we have array_slice()/array_splice().
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Andrew Faulds
http://ajf.me/
--
Andrew Faulds
http://ajf.me/
--
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
2012/8/22 Andrew Faulds :
> On 21/08/12 22:18, Yasuo Ohgaki wrote:
>>
>> 2012/8/22 Andrew Faulds :
>>>
>>> Er, so you're advocating adding another method to do the same thing? Why?
>>
>> Because novices don't know about array_walk().
>> I think I've written this over and over in this thread.
>
> So publicise array_walk() then. Don't add a new function.
Already publicized more than a decade.
IIRC, similar discussion was done years ago at least.
I suppose it's time to add element deletion function
based on values.
If you don't understand how it could be useful, take
a look at use cases of Ruby's delete_if.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
>
>>> The whole point of this was to allow people to use arrays like sets, or
>>> easily remove list items. Not encourage people to use functional
>>> programming.
>>>
>>> Sure, people should use array_walk, but you've got to be kidding me if I
>>> you
>>> think I would honestly accept using this to remove array items by value:
>>>
>>> array_delete($array, function ($value) { return ($value == "that value");
>>> });
>>>
>>> I might as well use array_walk if we're going down this route. You seem
>>> to
>>> want to subvert the usefulness of this function and just provide an
>>> array_walk shorthand with less functionality.
>>>
>>> What I want is this:
>>>
>>> array_delete($array, "that value");
>>
>> I do not want this ;)
>> What's wrong with extensible way? It's for PHP 5.5, not PHP 4.
>
>
> But we have array_walk().
>
>> array_delete($array, function ($v) { return ($v == "that value"); });
>>
>> We can use ==, ===, <, >, <=, =>, <==, ==>, !=, !==, and so on.
>> We may pass them as parameter,
>>
>> array_delete($array, "that value", "!==");
>>
>> but it does not look a modern way to do and it is not extensible
>> like with callable.
>
> No, it is a modern way. Modern and functional are not one and the same.
>
>>
>> Besides, how often we would like to delete elements based on
>> element's value? I guess it's not so often for most people.
>
> Uh, I thought that was the whole point of this suggestion. You seem to want
> to subvert the original intentions (making it easier to remove list items
> and treat arrays as sets), to providing a new functional mechanism for
> removing lots of array items satisfying a criteria.
>
>>> Much more readable, does what you expect, and provides a significant,
>>> noticeable value over array_walk here.
>>
>> array_walk() is easy to use, IMHO.
>> People just don't know array_walk() can be used to delete
>> elements because of it's name.
>
> But adding a new function is NOT the solution. That is the job of
> documentation. That's like saying "people have no idea what strstr is, so
> let's make a new function with less functionality called string_position!".
>
>>
>> As I wrote in sample code, new array_delete is an intuitive
>> name and convenient than array_walk. They are like
>> array_pop/array_push and array_slice/array_splice to me.
>
> It's nothing like those. array_pop() and array_push() are simple, they take
> an array and an item to add. What's so terrible and evil and complex about
> making array_delete() remove an item? Why does it have to be functional and
> overcomplicated to do something we can already do, instead of providing a
> simple and convenient mechanism to remove an item by value?
>
> I do not understand this. Especially since, by your method, you should also
> provide a key since it provides no method to check item's key.
>
> Sorry, I just do not understand how your suggestion is useful.
>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
>> As I mentioned earlier, array_walk() is the best way to delete
>> elements
>> with PHP
>> more than a decade. It should be mentioned the Stack Overflow page,
>> but it's not.
>>
>> It's just like adding
>> array_pop()/array_push()/array_shift()/array_unshift() while
>> we have array_slice()/array_splice().
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>
>
>
> --
> Andrew Faulds
> http://ajf.me/
>
>>>
>>> --
>>> Andrew Faulds
>>> http://ajf.me/
>>>
>
>
> --
> 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
On 21/08/12 22:35, Yasuo Ohgaki wrote:
2012/8/22 Andrew Faulds :
On 21/08/12 22:18, Yasuo Ohgaki wrote:
2012/8/22 Andrew Faulds :
Er, so you're advocating adding another method to do the same thing? Why?
Because novices don't know about array_walk().
I think I've written this over and over in this thread.
So publicise array_walk() then. Don't add a new function.
Already publicized more than a decade.
IIRC, similar discussion was done years ago at least.
I suppose it's time to add element deletion function
based on values.
If you don't understand how it could be useful, take
a look at use cases of Ruby's delete_if.
OK, but please don't subvert this. You want array_delete_if, I want
array_delete. You want a functional method for deleting things. I want
an atomic operation.
Are we clear?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
The whole point of this was to allow people to use arrays like sets, or
easily remove list items. Not encourage people to use functional
programming.
Sure, people should use array_walk, but you've got to be kidding me if I
you
think I would honestly accept using this to remove array items by value:
array_delete($array, function ($value) { return ($value == "that value");
});
I might as well use array_walk if we're going down this route. You seem
to
want to subvert the usefulness of this function and just provide an
array_walk shorthand with less functionality.
What I want is this:
array_delete($array, "that value");
I do not want this ;)
What's wrong with extensible way? It's for PHP 5.5, not PHP 4.
But we have array_walk().
array_delete($array, function ($v) { return ($v == "that value"); });
We can use ==, ===, <, >, <=, =>, <==, ==>, !=, !==, and so on.
We may pass them as parameter,
array_delete($array, "that value", "!==");
but it does not look a modern way to do and it is not extensible
like with callable.
No, it is a modern way. Modern and functional are not one and the same.
Besides, how often we would like to delete elements based on
element's value? I guess it's not so often for most people.
Uh, I thought that was the whole point of this suggestion. You seem to want
to subvert the original intentions (making it easier to remove list items
and treat arrays as sets), to providing a new functional mechanism for
removing lots of array items satisfying a criteria.
Much more readable, does what you expect, and provides a significant,
noticeable value over array_walk here.
array_walk() is easy to use, IMHO.
People just don't know array_walk() can be used to delete
elements because of it's name.
But adding a new function is NOT the solution. That is the job of
documentation. That's like saying "people have no idea what strstr is, so
let's make a new function with less functionality called string_position!".
As I wrote in sample code, new array_delete is an intuitive
name and convenient than array_walk. They are like
array_pop/array_push and array_slice/array_splice to me.
It's nothing like those. array_pop() and array_push() are simple, they take
an array and an item to add. What's so terrible and evil and complex about
making array_delete() remove an item? Why does it have to be functional and
overcomplicated to do something we can already do, instead of providing a
simple and convenient mechanism to remove an item by value?
I do not understand this. Especially since, by your method, you should also
provide a key since it provides no method to check item's key.
Sorry, I just do not understand how your suggestion is useful.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
As I mentioned earlier, array_walk() is the best way to delete
elements
with PHP
more than a decade. It should be mentioned the Stack Overflow page,
but it's not.
It's just like adding
array_pop()/array_push()/array_shift()/array_unshift() while
we have array_slice()/array_splice().
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Andrew Faulds
http://ajf.me/
--
Andrew Faulds
http://ajf.me/
--
Andrew Faulds
http://ajf.me/
--
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
There is a reason to have a callable provided: custom comparison. Other array functions solve this by providing a `u` alternative: `int array_udelete(&$array, $value, bool function($value, $key))` Let's not deviate from established array naming conventions. (Yasuo, I'm looking at you) Cheers, Levi Morrison -- 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 21/08/12 22:43, Levi Morrison wrote: There is a reason to have a callable provided: custom comparison. Other array functions solve this by providing a `u` alternative: `int array_udelete(&$array, $value, bool function($value, $key))` Let's not deviate from established array naming conventions. (Yasuo, I'm looking at you) Cheers, Levi Morrison Yeah, this looks like a good solution and we have the best of both worlds. We get int array_delete(&$array, $value, $strict=TRUE); and int array_udelete(&$array, $value, $callback=bool function ($value $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
Hi, 2012/8/22 Levi Morrison : > There is a reason to have a callable provided: custom comparison. > Other array functions solve this by providing a `u` alternative: > > `int array_udelete(&$array, $value, bool function($value, $key))` > > Let's not deviate from established array naming conventions. (Yasuo, > I'm looking at you) Good suggestion. Written to the wiki page. 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
On Tue, Aug 21, 2012 at 3:45 PM, Andrew Faulds wrote: > On 21/08/12 22:43, Levi Morrison wrote: >> >> There is a reason to have a callable provided: custom comparison. >> Other array functions solve this by providing a `u` alternative: >> >> `int array_udelete(&$array, $value, bool function($value, $key))` >> >> Let's not deviate from established array naming conventions. (Yasuo, >> I'm looking at you) >> >> Cheers, >> >> Levi Morrison > > Yeah, this looks like a good solution and we have the best of both worlds. > > We get int array_delete(&$array, $value, $strict=TRUE); and int > array_udelete(&$array, $value, $callback=bool function ($value $key)); > > :) > > I'll still vote no on the RFC if it ever comes to it :) I'm only contributing here because I don't want pure madness to ever come to a vote when I'm absent and get voted in . . . -- 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
2012/8/22 Levi Morrison : > On Tue, Aug 21, 2012 at 3:45 PM, Andrew Faulds wrote: >> On 21/08/12 22:43, Levi Morrison wrote: >>> >>> There is a reason to have a callable provided: custom comparison. >>> Other array functions solve this by providing a `u` alternative: >>> >>> `int array_udelete(&$array, $value, bool function($value, $key))` >>> >>> Let's not deviate from established array naming conventions. (Yasuo, >>> I'm looking at you) >>> >>> Cheers, >>> >>> Levi Morrison >> >> Yeah, this looks like a good solution and we have the best of both worlds. >> >> We get int array_delete(&$array, $value, $strict=TRUE); and int >> array_udelete(&$array, $value, $callback=bool function ($value $key)); >> >> :) >> >> > > I'll still vote no on the RFC if it ever comes to it :) > > I'm only contributing here because I don't want pure madness to ever > come to a vote when I'm absent and get voted in . . . Just curious why? 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, I see why with new Criticism section in the wiki page. You've also misunderstood that array_udelete() is array_walk() variant, not array_filter(). This may be the good reason why we should have array_udelete :) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/8/22 Yasuo Ohgaki : > 2012/8/22 Levi Morrison : >> On Tue, Aug 21, 2012 at 3:45 PM, Andrew Faulds wrote: >>> On 21/08/12 22:43, Levi Morrison wrote: There is a reason to have a callable provided: custom comparison. Other array functions solve this by providing a `u` alternative: `int array_udelete(&$array, $value, bool function($value, $key))` Let's not deviate from established array naming conventions. (Yasuo, I'm looking at you) Cheers, Levi Morrison >>> >>> Yeah, this looks like a good solution and we have the best of both worlds. >>> >>> We get int array_delete(&$array, $value, $strict=TRUE); and int >>> array_udelete(&$array, $value, $callback=bool function ($value $key)); >>> >>> :) >>> >>> >> >> I'll still vote no on the RFC if it ever comes to it :) >> >> I'm only contributing here because I don't want pure madness to ever >> come to a vote when I'm absent and get voted in . . . > > Just curious why? > > 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
On Tue, Aug 21, 2012 at 4:13 PM, Yasuo Ohgaki wrote: > Hi, > > I see why with new Criticism section in the wiki page. > You've also misunderstood that array_udelete() is > array_walk() variant, not array_filter(). > Actually, array_udelete is far more similar to array_filter than it is array_walk. . . -- 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/22 Levi Morrison : > On Tue, Aug 21, 2012 at 4:13 PM, Yasuo Ohgaki wrote: >> Hi, >> >> I see why with new Criticism section in the wiki page. >> You've also misunderstood that array_udelete() is >> array_walk() variant, not array_filter(). >> > > Actually, array_udelete is far more similar to array_filter than it is > array_walk. . . Have you read my posts in this thread? Array filter CREATES new array instead of deleting elements. If one would like to DELETE element(s) by element value, array_walk is the way to go. I suppose I don't have to explain memory and execution efficiency here. Many people misunderstand the best practice. This is the reason why I think there should be array_udelete. 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/22 Levi Morrison : > On Tue, Aug 21, 2012 at 4:13 PM, Yasuo Ohgaki wrote: >> Hi, >> >> I see why with new Criticism section in the wiki page. >> You've also misunderstood that array_udelete() is >> array_walk() variant, not array_filter(). >> > > Actually, array_udelete is far more similar to array_filter than it is > array_walk. . . Why did you change the equivalent code? array_walk is the best(fast and memory efficient) way to delete elements. This code may be refereed from old PHP users, therefore we should write better code. If you don' t have good reason to do so, please revert the change. 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
> Why did you change the equivalent code? > array_walk is the best(fast and memory efficient) way > to delete elements. > > This code may be refereed from old PHP users, therefore > we should write better code. > > If you don' t have good reason to do so, please revert > the change. The implementation you had may be faster, but that is certainly NOT what matters as long as both are correct. What matters in the RFC is clarity. You have already said that too many people don't know about array_walk, so why would they understand array_delete in terms of array_walk? Please do not revert the change as what I have written is more clear. The reason speed doesn't matter in behavior example is that once it is implemented in C it will be just as fast as array_walk, perhaps it will even be faster. -- 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 21 August 2012 23:26, Yasuo Ohgaki wrote: > array_walk is the best(fast and memory efficient) way > to delete elements. If array_walk() is the best (fast and memory efficient) way to delete elements, why have we had the following line in the manual, for the array_walk() callback, for over a decade [1]? (The exact phrasing has changed slightly one time, but the message has remained the same) "Only the values of the array may potentially be changed; its structure cannot be altered, i.e., the programmer cannot add, unset or reorder elements." [1] http://svn.php.net/viewvc/?view=revision&revision=75124 -- 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/22 Peter Cowburn : > On 21 August 2012 23:26, Yasuo Ohgaki wrote: >> array_walk is the best(fast and memory efficient) way >> to delete elements. > > If array_walk() is the best (fast and memory efficient) way to delete > elements, why have we had the following line in the manual, for the > array_walk() callback, for over a decade [1]? (The exact phrasing has > changed slightly one time, but the message has remained the same) > "Only the values of the array may potentially be changed; its > structure cannot be altered, i.e., the programmer cannot add, unset or > reorder elements." > > [1] http://svn.php.net/viewvc/?view=revision&revision=75124 10 years ago log :) I'm not sure, but it had some problems with reference back then. There were many array functions that behaved wrong with reference used to be. I was annoyed by that, probably. That's why I wrote it, I suppose. Good catch. It should be removed now. 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
2012/8/22 Levi Morrison : >> Why did you change the equivalent code? >> array_walk is the best(fast and memory efficient) way >> to delete elements. >> >> This code may be refereed from old PHP users, therefore >> we should write better code. >> >> If you don' t have good reason to do so, please revert >> the change. > > The implementation you had may be faster, but that is certainly NOT > what matters as long as both are correct. What matters in the RFC is > clarity. You have already said that too many people don't know about > array_walk, so why would they understand array_delete in terms of > array_walk? Please do not revert the change as what I have written is > more clear. I don't say array_walk() is difficult, but people out there just don't know it. Why we should use inefficient example for internals? Besides, if array_walk() is used, people who would like to write patch for it will knew that most of code can be borrowed from array_walk(). Thus, it may prevent reinventing wheel. > The reason speed doesn't matter in behavior example is that once it is > implemented in C it will be just as fast as array_walk, perhaps it > will even be faster. I cannot agree to this opinion. I still think the example should be reverted. 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
2012/8/22 Yasuo Ohgaki : > Hi, > > 2012/8/22 Peter Cowburn : >> On 21 August 2012 23:26, Yasuo Ohgaki wrote: >>> array_walk is the best(fast and memory efficient) way >>> to delete elements. >> >> If array_walk() is the best (fast and memory efficient) way to delete >> elements, why have we had the following line in the manual, for the >> array_walk() callback, for over a decade [1]? (The exact phrasing has >> changed slightly one time, but the message has remained the same) >> "Only the values of the array may potentially be changed; its >> structure cannot be altered, i.e., the programmer cannot add, unset or >> reorder elements." >> >> [1] http://svn.php.net/viewvc/?view=revision&revision=75124 > > 10 years ago log :) > I'm not sure, but it had some problems with reference back then. > There were many array functions that behaved wrong with reference > used to be. > > I was annoyed by that, probably. That's why I wrote it, I suppose. > > Good catch. > It should be removed now. I thought it's in there now, but it's not. What's the point of bring up old bug documentation now? I really don't see. Regards, -- Yasuo Ohgaki -- 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-22 04:35, Lester Caine wrote:
John LeSueur wrote:
Again, the case you've cited is probably not a case where generators
give much
advantage. But anytime the logic to produce some data becomes more
complicated
(Imagine that you needed to skip some of the lines in the .csv file
based on
some kind of filter), then being able to extricate the producer logic
from the
consumer logic is helpful.
But in my 'method of working' one simply changes the '$contact->' object
and loads the one that matches the data you are handling. Sage, paypal,
moneybox, nlpg and so on. I've a dozen or so data models currently.
>
That is one of the differences. With the Iterator pattern that is being
automated here, all the boilerplate of maintaining state between
iteration steps is contained within the iterator object, and is the same
for all uses of that object, so only needs to be written once (and, with
this extension, that writing is automated). Using the Observer pattern
like you do requires boilerplate to be written afresh for every distinct
_use_ of the iterator. That boilerplate isn't directly related to the
consumer's actual job but to the iteration process (limiting the range
of producers that consumer can be fed from).
but I still can't see why the work flow has to be
reorganised rather than simply following the natural flow that the job
requires.
The adjective "natural" would only apply if you always see iteration as
the producer pushing its productions out to the consumer ("here - go
work on this"), and never picture the situation as the consumer pulling
them from the producer ("give me something to work on"). Otherwise it's
just a different perspective.
The Observer pattern certainly does have its uses (otherwise it wouldn't
be a pattern): if the "things being produced" are interpreted as "events
being handled" ("hey, a new line of CSV has just come in!"), there may
be multiple consumers interested in being notified when those events occur.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] [RFC] Generators
Oh, yes...
On 2012-08-22 04:35, Lester Caine wrote:
and doesn't seem to
provide any outstanding advantages?
As I wrote in an earlier post:
On 2012-08-09 15:30, Morgan L. Owens wrote:
> I for one am lazy, and would much prefer writing:
> function append_iterator($first, $second)
> {
>foreach($first as $i)
>{
>yield $i;
>}
>foreach($second as $i)
>{
>yield $i;
>}
> }
> ?>
>
> to
>
> 87 lines elided
> ?>
I'm not making any assumption about where the generator returned by
append_iterator() is going to be used. In particular, it might not be in
a public object method or other callable. But its use would probably
look something like:
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
Hi, 2012/8/16 Rasmus Schultz : > How come there is no straight-foward obvious way to simply remove a given > value from an array? > > Just look at the number of horrible ways people solve this obvious problem: > > http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key > > Shouldn't we have something simple, like: > > array_remove($array, $value) : array (returns a new array) > > and/or > > array_delete(&$array, $value) : bool (modifies array directly) > > ? It was amazing that this thread has close to 90 mails. I've added some use cases of array_udelete() to wiki, since some people fails to see how it could be useful. I also bring back to array_walk() version of equivalent example. I just don't see any reason why we should replace it with slower foreach() version. I think the RFC page is almost complete. https://wiki.php.net/rfc/array_delete Any more comments? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
On Tue, Aug 21, 2012 at 7:45 PM, Yasuo Ohgaki wrote: > > Hi, > > 2012/8/16 Rasmus Schultz : > > How come there is no straight-foward obvious way to simply remove a given > > value from an array? > > > > Just look at the number of horrible ways people solve this obvious problem: > > > > http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key > > > > Shouldn't we have something simple, like: > > > > array_remove($array, $value) : array (returns a new array) > > > > and/or > > > > array_delete(&$array, $value) : bool (modifies array directly) > > > > ? > > It was amazing that this thread has close to 90 mails. > > I've added some use cases of array_udelete() to wiki, since > some people fails to see how it could be useful. I also bring > back to array_walk() version of equivalent example. I just > don't see any reason why we should replace it with slower > foreach() version. > > I think the RFC page is almost complete. > > https://wiki.php.net/rfc/array_delete > > Any more comments? > > -- > Yasuo Ohgaki > yohg...@ohgaki.net Take a look at: http://php.net/manual/en/function.array-walk.php#refsect1-function.array-walk-parameters Look at funcname parameter. Notice: > Only the values of the array may potentially be changed; its structure cannot > be altered, i.e., the programmer cannot add, unset or reorder elements. If > the callback does not respect this requirement, the behavior of this function > is undefined, and unpredictable. I'm just going to change the behavior back when you switch it to array_walk. It's less clear and technically undefined. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
Hi, 2012/8/22 Levi Morrison : > On Tue, Aug 21, 2012 at 7:45 PM, Yasuo Ohgaki wrote: >> >> Hi, >> >> 2012/8/16 Rasmus Schultz : >> > How come there is no straight-foward obvious way to simply remove a given >> > value from an array? >> > >> > Just look at the number of horrible ways people solve this obvious problem: >> > >> > http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key >> > >> > Shouldn't we have something simple, like: >> > >> > array_remove($array, $value) : array (returns a new array) >> > >> > and/or >> > >> > array_delete(&$array, $value) : bool (modifies array directly) >> > >> > ? >> >> It was amazing that this thread has close to 90 mails. >> >> I've added some use cases of array_udelete() to wiki, since >> some people fails to see how it could be useful. I also bring >> back to array_walk() version of equivalent example. I just >> don't see any reason why we should replace it with slower >> foreach() version. >> >> I think the RFC page is almost complete. >> >> https://wiki.php.net/rfc/array_delete >> >> Any more comments? >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net > > Take a look at: > http://php.net/manual/en/function.array-walk.php#refsect1-function.array-walk-parameters > > Look at funcname parameter. Notice: >> Only the values of the array may potentially be changed; its structure >> cannot be altered, i.e., the programmer cannot add, unset or reorder >> elements. If the callback does not respect this requirement, the behavior of >> this function is undefined, and unpredictable. > > I'm just going to change the behavior back when you switch it to > array_walk. It's less clear and technically undefined. Ok, then my commit to the doc was outstanding still. Old PHP was behaved badly with reference variables. I'll remove obsolete statement. I'll fix it later. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UTF-8 files and include
On 21/08/12 15:13, Rasmus Lerdorf wrote: On 08/21/2012 09:10 AM, Ivan Enderlin @ Hoa wrote: Hello, Some of my users & contributors have met an issue with files containing UTF-8 on certain Windows configurations (but they actually did not found the difference). Any idea why? The issue does not appear on Linux, BSD or Mac OS system, only for certain Windows. What do we need to check? --enable-zend-multibyte, some php.ini magic parameters, some ENV variables? What kind of issue? Perhaps they are leaving in the BOM? Tell them to configure their editors to not add a BOM. It's not from the editor. The filename contains UTF-8 character and the include/require fails. Best regards. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
Um, Yasuo, have you looked at array_walk implementation and ascertained it is safe to change array structure while using it? Because I'm worried you're changing docs without doing so. -- Sent from Samsung Mobile Andrew Faulds http://ajf.me/ Yasuo Ohgaki wrote: Hi, 2012/8/22 Levi Morrison : > On Tue, Aug 21, 2012 at 7:45 PM, Yasuo Ohgaki wrote: >> >> Hi, >> >> 2012/8/16 Rasmus Schultz : >> > How come there is no straight-foward obvious way to simply remove a given >> > value from an array? >> > >> > Just look at the number of horrible ways people solve this obvious problem: >> > >> > http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key >> > >> > Shouldn't we have something simple, like: >> > >> > array_remove($array, $value) : array (returns a new array) >> > >> > and/or >> > >> > array_delete(&$array, $value) : bool (modifies array directly) >> > >> > ? >> >> It was amazing that this thread has close to 90 mails. >> >> I've added some use cases of array_udelete() to wiki, since >> some people fails to see how it could be useful. I also bring >> back to array_walk() version of equivalent example. I just >> don't see any reason why we should replace it with slower >> foreach() version. >> >> I think the RFC page is almost complete. >> >> https://wiki.php.net/rfc/array_delete >> >> Any more comments? >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net > > Take a look at: > http://php.net/manual/en/function.array-walk.php#refsect1-function.array-walk-parameters > > Look at funcname parameter. Notice: >> Only the values of the array may potentially be changed; its structure >> cannot be altered, i.e., the programmer cannot add, unset or reorder >> elements. If the callback does not respect this requirement, the behavior of >> this function is undefined, and unpredictable. > > I'm just going to change the behavior back when you switch it to > array_walk. It's less clear and technically undefined. Ok, then my commit to the doc was outstanding still. Old PHP was behaved badly with reference variables. I'll remove obsolete statement. I'll fix it later. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UTF-8 files and include
hi! On Tue, Aug 21, 2012 at 3:10 PM, Ivan Enderlin @ Hoa wrote: > Hello, > > Some of my users & contributors have met an issue with files containing > UTF-8 on certain Windows configurations (but they actually did not found the > difference). Any idea why? > The issue does not appear on Linux, BSD or Mac OS system, only for certain > Windows. > > What do we need to check? --enable-zend-multibyte, some php.ini magic > parameters, some ENV variables? It can't be fixed easily. Basically avoid by any price to use Unicode names for the filenames of your projects. As it may (very often) works smoothly on most unices, it won't work ever using current releases or master on Windows. One has to set the correct codepage and do the conversion from/to UTF-8. 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
