Nick Stinemates wrote:
Nathan Rixham wrote:
Robert Cummings wrote:
On Mon, 2008-02-18 at 21:09 -0600, Larry Garfield wrote:
On Monday 18 February 2008, Nick Stinemates wrote:
I have found, however, that if I ever need to return /multiple/
values,
it's usually because of bad design and/or the lack of proper
encapsulation.
You mean you've never had a function like getCoordinates()? Or
getUsers(), or any other of a zillion perfectly valid and reasonable
functions that return multiple values as an array? Wow, how odd!
Cheers,
Rob.
getCoordinates() would return a Point object
getUsers() would return a Group object...
Not rocket science ;)
I wouldn't consider an array of user objects to be "multiple
things". I consider it a single aggregate thing, and return arrays
all the time. That's conceptually different from wanting two
separate return values from a function, which is indeed conceptually
icky.
Yes, an aggregate is comprised of multiple things usually. Hence when
decomposing the concept you are indeed returning multiple values-- both
points of view are valid. If you receive a parcel of 100 pens. I can
say, "has the parcel arrived yet" (one entity) or "have the pens arrived
yet" (multiple entities).
At any rate, the O.P. wanted to return multiple values called $x and $y.
It seems quite reasonable to assume he was returning something akin to
coordinates but didn't know how to do so by binding them in an
aggregating structure such as an array, or if you wish, an object.
Cheers,
Rob.
seriously, whats wrong with returning an array? half the standard php
functions return array's, therefore at least half of php has been
designed badly..?
ps: when working with co-ordinates / GIS data you should really be
using wkb data instead, it's much faster. [unpack]
What's wrong with it? Hmm..
Half of PHP functions DO return arrays, I'll grant you that. The reason?
It's untyped. If PHP were a typed language, and it still returned arrays
for a lot, I definitely think it would be designed poorly.
At any rate, returning an array from your Objects increases the burden
and shifts it to the client of your API. For instance, if we take an
example mentioned above *getUsers()* which returned an arbitrary number
of User objects you could potentially use it like this.
userupdater.php
<?php
$x = Users::getUsers($somefilter)
foreach ($x as $user) {
$user->update();
}
?>
Keep in mind. You'll have to rewrite that functionality in multiple
areas. As opposed to:
<?php
$x = Users::getGroup($somegroup); // returns a group of users
$x->update(); // can be reused wherever instead of having to loop
through every user on the client side.
?>
I hope you can see past my (basic) example to understand where I am
headed with this.
I would, and do, use this magic :)
Users::GetGroup($somegroup)->update();
Simple, Even less typing then yours :p
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
