[PHP-DEV] Proposal: array_flatten function
Hey everybody, I'm new both to the list and to hacking the internals, so I'll try to keep it short and humble. I've written an array_flatten function which just takes all elements from a nested array and pushes them into a single indexed array. Couple of questions: 1. Most importantly, is this patch-worthy to everybody? I was a bit surprised that it didn't already exist (it wasn't difficult to write, even for me :) ), and a search turns up quite a few posts both on the PHP doc comments and elsewhere detailing how to do the same in usersland PHP. There are some pretty clear usecases for this, such as doing statistics on a grouped dataset, as well as grabbing all values from a single-column SQL query. It's a very simple, unobtrusive patch. 2. One of the PHP implementations "preserved keys." This seems counterintuitive to me, as there's a high probability of overwriting, and I can't think of a usecase where one would want to flatten out an array, but keep the keys. Nonetheless, it was implemented by one of the snippets I saw. Should the function offer this option with a $preserveKeys = false optional param? If so, how should I handle duplicate keys? Failure? Warning? IMO, it's not worthwhile, but I wanted to get opinions. 3. (this is where the noob comes in) What is the protocol on creating patches? Should I just run the CVS patch command against a major revision? I haven't used that before, but it seems straight forward enough. If someone can point me to a writeup of the exact "correct" way to generate a patch, I'd appreciate it. Ooops, not that short I guess... Cheers. Mike.
Re: [PHP-DEV] Proposal: array_flatten function
Well, I've made a patch against 5.3 for now, let me know if there are issues with it (I'm sure there are) and if you want the HEAD patch. Cheers. Mike. On Fri, Dec 26, 2008 at 2:55 AM, Alexey Zakhlestin wrote: > On Fri, Dec 26, 2008 at 1:43 PM, David Coallier wrote: > >> > >> "cvs diff -u" against 5.3 branch shoould be ok for the start. > >> after positive review, "cvs diff -u" against HEAD would be needed to > >> > > > > I really have to say it, you should make your changes to HEAD > > __first__ then to 5.3. Not the other way around :) > > David, it's not about changes. It's about review. > Raw fact is, that reviewing on 5.3 is much easier than on HEAD for many > people. > > At the moment of commit both patches are needed, for sure :) > > -- > Alexey Zakhlestin > http://www.milkfarmsoft.com/ > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: array_flatten function
Why not just link straight to the tutorial on your site? ;) Not sure what
your point is, other than "there's a way to do this in userland," which I
cover in my email. Maybe some sentences to accompany it would make it easier
to understand.
Thanks for reading. Cheers.
Mike.
On Fri, Dec 26, 2008 at 5:55 AM, Kevin Waterson wrote:
> This one time, at band camp, "Mike Panchenko" wrote:
>
> > Hey everybody, I'm new both to the list and to hacking the internals, so
> > I'll try to keep it short and humble.
> >
> > I've written an array_flatten function which just takes all elements from
> a
> > nested array and pushes them into a single indexed array.
>
> function flattenArray(array $array){
> $ret_array = array();
> foreach(new RecursiveIteratorIterator(new RecursiveArrayIterator($array))
> as $value)
> {
> $ret_array[] = $value;
> }
> return $ret_array;
> }
>
> Kevin
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Proposal: array_flatten function
Lukas,
Hmmm I'm just trying to solve the basic problem (hence my skepticism towards
preserving keys - it seems an edge case). I think once you get to more
specific requirements, iterators are probably the way to go, since all the
standard functions you could use to shorten this would re-iterate over the
array internally anyway.
Cheers.
Mike.
On Fri, Dec 26, 2008 at 7:56 AM, Lukas Kahwe Smith wrote:
> In one of my recent projects I had the need for something like this. I
> essentially had a recursive data structure of organizations and frequently I
> had to get a list of all organization ID's that were above or underneath a
> given organization. So I had to write a deeply self join which would produce
> lets say around 3-4 columns that either contained an ID or were NULL.
>
> I ended up with an implementation like the following. Actually looking at
> it now it seems way too complex but it works, so it goes:
>function flattenArray($array) {
>if (empty($array)) {
>return array();
>}
>$first = reset($array);
>if (empty($first)) {
>return array();
>}
>$keys = array_keys($first);
>$result = array();
>foreach ($array as $row) {
>foreach ($keys as $key) {
>if (!empty($row[$key])) {
>$result[] = $row[$key];
>}
>}
>}
>$result = array_unique($result);
>return $result;
>}
>
> So I guess what I am asking for is a flag to ignore NULL's. Kind of reminds
> me of that patch Igor proposed the other day. Then again, we have so
> many array functions its not even funny. So maybe we really should look more
> towards Iterators to help us consolidate things. Not sure.
>
> regards,
> Lukas
>
Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
On Mon, Apr 13, 2009 at 1:06 PM, Stanislav Malyshev wrote: > It's a pretty small use case (that's a problem only if you have xml > documents which has to have php code which has to be inlined) and as you > see, can be easily handled. I think that should not make whole very useful > syntax deprecated. > +1 One of the reason's for PHP's success IMO is the ease of creating templates with it. Forcing everyone to write every time just just so that you don't have to write
Re: [PHP-DEV] Why is ereg being deprecated?
Mark,
You contradict yourself. You say that putting a warning in 5.3 isn't soon
enough, since most people are a few versions behind. Yet you think it is an
absolute outrage that something is being dropped in 6, which is a couple of
years away anyway. The people that won't be on 5.3 in time to be notified of
the change won't be upgrading to 6 for a year or two after the release
anyway. If people are upgrading as new versions are marked stable, they've
already seen the warnings. If they aren't, then there will be a ton of time
for them to port their code to use PCRE before they get anywhere near
installing 6. Besides, any time you upgrade to a major revision, you should
basically expect your code to break. Since it's been pointed out that ereg
will be moved to a PECL extension, hosting providers who have users that
depend on ereg will be able to just install the extension. CRISIS AVERTED!
And in the meantime, you've insulted the core PHP developers and have made a
big stink, when really, they're just trying to make the best decision for
moving the language along. Good going.
Unicode support is far more important than posix regex support. If you feel
so strongly about keeping ereg, you should do the work required to keep it
instead of pissing and moaning at others for not doing it, while making
accusatory statements at people who donate their time to work on an open
source project.
Cheers,
Mike.
On Mon, Oct 12, 2009 at 2:57 PM, Ferenc Kovacs wrote:
> On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs wrote:
> > On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz wrote:
> >> On Mon, Oct 12, 2009 at 07:22:10PM GMT, Robert Cummings [
> rob...@interjinn.com] said the following:
> >>>
> >>> You are obviously right of course... the PHP world is NOT ready for the
> >>> POSIX regex library to be dropped. That's why it's "deprecated" in PHP
> >>> 5.3 and not removed. In a year or 3, when PHP 6 is released, one would
> >>> hope that by then the PHP world WILL be ready.
> >>>
> >>
> >> One would hope, but I've seen otherwise over the past 10 or 11 years
> >> of administrating PHP.
> >>
> > You are just the one in seven billion.
> >> Often times the latest supported versions of operating systems do not
> >> contain a version of PHP that is recent or supported even. And
> >> typically people will run a server for around 3-5 years so they end up
> >> having a version of PHP that is way behind. PHP Developers may wonder
> >> about this but it is completely acceptable and expected from a sysadmin
> >> point of view. I know that I never feel like I'm on a supported
> >> version of PHP, even though I'll use a recent OS version.
> > Major versions can and will break backward compatibility.
> > If your code does not ready for php6, then you have 3-10 years to port
> > it to the php6.
> > If you dont want to, then its fine, you dont have to.
> >>
> >> So what happens is if its timed right, many people will never be
> >> running PHP 5.3 and will end up straight on PHP 6.
> >>
> > Why would somebody skip php 5.3 when porting the applications from 5.2
> > is easy, then switch to php6 to its release day?
> >> I used the term overnight before and I think that confused people.
> >> What I mean is overnight in terms of version numbers. For instance,
> >> overnight would be like one patch level or even minor version to the
> >> next.
> >>
> >> When a function is deprecated, I expect to see the warning for quite a
> >> while before its actually removed. So if it just happens "overnight"
> >> thats not acceptable, no matter how much time has passed. Its more
> >> about version numbers than time.
> >>
> > If -at least- 3 years of warning is overnight for you, than I think
> > I'm lucky to catch you awake.
> >>
> >> --
> >> Mark S. Krenz
> >> IT Director
> >> Suso Technology Services, Inc.
> >> http://suso.org/
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
> > I don't like the way that you say you are representing "the whole
> > internet", it would be better if we can go for the one person one vote
> > rule.
> >
> > Sorry for my english, I'm not a native speaker, and it's getting late.
> >
> > Tyrael
> >
>
> btw. I hate php 5.3 for the following change:
> # The use of {} to access string offsets is deprecated. Use [] instead.
> I always used the {} because the [] was deprecated for a long time,
> and I corrected everybody, to use the {}, and in one release, the []
> gets undeprecated, and the {} to deprecated.
> Shame on you people, but I think I have to live with it. :)
>
> Tyrael
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
