Re: [PEPr] Comment on Web Services::Services_Facebook
| From: | Travis Swicegood | Date: | Mon, 29 Oct 2007 21:27:57 +0000 |
| Subject: | Re: [PEPr] Comment on Web Services::Services_Facebook | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-48336@lists.php.net to get a copy of this message | ||
Just getting around to responding to emails... Sorry for the delay.
I'd never implement the driver interface mainly because I doubt a person cares *how* you're connecting to Facebook. That being said, when PEAR2's HTTP_Request comes out I'll use that and add an accept method to you can make connections however you want.Yeah - the new P2 code will be nice.
When would you need to check results explicitly? That's handled in the request method anyways.I'm not sure; in this case it's more of a design choice to keep objects with a very defined purpose.
Hrm. Good idea. How about a setDefaultUserFields()? I'm fine even making it public. I now see a reason to expose it; it's just a matter of how to go about exposing it?I'm not sure either. Personally, the only reason I would use a setter is if there was some sort of validation happening. I'm more for keeping it free-form rather than saying it will accept X, Y, and Z values but not A, B, and C. For that, I'm thinking a public static for the default, then we can cast it to an array when we start working with it to make doing single fields less cumbersome.
I like this a lot. It makes sense. Would you then make Services_Facebook::factory() private? Or leave it exposed?I would make it a private. If you want to simulate factory() you would just do: $users = $facebook->users; -T