Hi!
> The number of values in a DB result set may be unpredictable, but the
> number of _elements_ in each value shouldn't be - and the list() will be
> on those elements:
>
> foreach($resultset as list($id, $name, $address, $phone))
> {
One doesn't see this pattern too much and the reason is - what happens
if an element is added or the order changes? Is it really guaranteed the
elements are always in this order - what if the query is modified to add
some other data from other table, etc.? Thus usually people do more of
$row['id'] than list($id, ...) = $row. List() is usually too rigid for
something as fluid as DB data sets (and with noSQL DBs where there's no
fixed schema it'd be even less appropriate).
> So when I have a function that has a two- or multi-part result then -
> instead of having one part as the return value and the others by
> reference - in Python I'd return a tuple.
PHP functions can return arrays and some do - e.g. pathinfo(). But not
all of them. Maybe getting more functions return result sets instead of
modifying parameters could be one target of that API refactoring people
are talking about. However, in some case - e.g. function returning
result and maybe error code - tuple may not be that convenient, in most
cases you just want the result, and unpacking tuple (or array in PHP)
would be additional complication.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
