Re: More than one values returned?

Nick Stinemates wrote:

Jim Lucas wrote:

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

:P. I use that method, too. It really sucks for debugging though, because what if GetGroup($somegroup) returns a null or unexpected value? Yeah, it sucks. But, doesn't occur enough to be too annoying ;)

You built it, make sure it doesn't return anything other than what you want! -- Jim Lucas "Some men are born to greatness, some achieve greatness, and some have greatness thrust upon them." Twelfth Night, Act II, Scene V by William Shakespeare