php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #34061 Restructure array functions for PHP6
Submitted: 2005-08-10 03:32 UTC Modified: 2010-12-03 17:37 UTC
From: garyb at fxt dot com Assigned: jani (profile)
Status: Closed Package: *General Issues
PHP Version: 5.1.0b3 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: garyb at fxt dot com
New email:
PHP Version: OS:

 

 [2005-08-10 03:32 UTC] garyb at fxt dot com
Description:
------------
The list of PHP functions that operate on arrays has grown large, but could be restructured to fit into a more coherent model.  Multidimensional array operations in any language can be confusing even in the best situations.  PHP's array functions seem to have been implemented one at a time, as someone saw a need.  Some of the functions are overly specific to a given, rare applicationm and others are not defined well particularly for multidimensional applications.  It can be difficult to figure out which function(s) to use/combine to accomplish a particular task.  Just as one example, array_slice could be more useful for multidimensional arrays if an array could be given for the offset and length  This would allow one to slice, for example, all instances of a particular field in a set of database results.

I would propose a new array function set for a later version of PHP, that works the same without regard to dimension.  In my experience, the best implementation of array functionality (disregarding the language syntax) that I have ever used is the one in APL.  Every function that works on arrays (which is most of them) does what's expected regardless of dimensionality, and in almost all cases every argument can be an array.  Like PHP, APL can view a string as a string or as an array of char.  Later versions supported structured arrays, akin to objects.  I found APL's basic functions to be easier to learn and use than any of the 'Mathematica' clones.  Of course APL just represents one potential approach.

If nobody else is already working on anything in this line, I'd be amenable to participating in such a project, perhaps first as an extension - though I can't say I'd be that much help.  It may be that the APL functions could be used as models for named functions, with similar monadic/dyadic effects; or an interface to the Octave libraries could be the best approach.

Reproduce code:
---------------
Example of APL equivalents:
APL          :== function()
    --> effect or equivalent using PHP syntax

A = iota(6)  :== iterate (6)
    --> A = range(6);

B = rho (A)  :== shape (A)
    --> B = count (A);

B = (2 3) rho (A) :== reshape A
    --> B = array ( array (0, 1, 2), array ( 3, 4, 5);
    --> or B = array (range (0,3), range(3,6));

C = (0 1 0 ) select(A) (I forget the APL name)
    --> C = array (array (1), array (4));
    --> no simple equiv in PHP


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-05 00:21 UTC] yaXay at gmx dot net
I would really like the intoduction of actual arrays, because let's face it: We're talking about lists here. Sure, lists are superior to arrays, but only regarding functionality. Most of my algorithms would work perfectly fine with zero-based arrays as one has to deal with in C/++, Java, etc. And just rarely I actually need them to be dynamic and sometimes not even semi-dynamic.
Overall I would love it if there could be two new native types in PHP: arrays (semi-dynamic) and stacks.
Why make "stack" an actual type you might ask? For performance reasons. Of course there could be a class "Stack", but having to call $stack->push($val) and $stack->pop() all the time would be slower compared to some stack operators.
The reason I'm putting performance in the center of discussion is that PHP is really slow compared to JSP. Of course that is not just because Java supports arrays, but also because with PHP you have to lex and parse the whole script on each call, but still: If I can choose between PHP and JSP I usually go with JSP, because of performance, stability and security.

Sincerely,
Benjamin Schulz
 [2010-12-03 17:37 UTC] jani@php.net
-Status: Open +Status: Closed -Package: Feature/Change Request +Package: *General Issues -Assigned To: +Assigned To: jani
 [2010-12-03 17:37 UTC] jani@php.net
There's SPL nowadays..
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 09:01:26 2024 UTC