Keep the toolkit lean an mean

Jun 20, 2007 at 12:07 AM
I belive that we should keep this toolkit (.net facebook api) as close as the api defined by Facebook. I know it's easy to ask for new features ("then I don't have to implement 'em myself"), but adding them can confuse ("why is NN() in this kit, but not in the original?"). If we add new features, like GetNonAppUsers(), I belive they should be in their own namespace, e.g. Facebook.Unsupported.

Just my 2c :)
Developer
Jun 21, 2007 at 12:27 AM
Edited Jun 21, 2007 at 12:29 AM

soderlind wrote:
I belive that we should keep this toolkit (.net facebook api) as close as the api defined by Facebook. I know it's easy to ask for new features ("then I don't have to implement 'em myself"), but adding them can confuse ("why is NN() in this kit, but not in the original?"). If we add new features, like GetNonAppUsers(), I belive they should be in their own namespace, e.g. Facebook.Unsupported.

Just my 2c :)

I agree that there is a benefit to having the core implementation stand-out from the rest. However, I wouldn't go as far as to put them in their own namespace. This would remove them from the classes that they relate to and really belong in. This would just make it more difficult for users to find, and would add to the "Why the heck is Facebook.Unsupported" in this kit?"

However, it would make sense to separate these extra functions logically in the code-- perhaps in a different source file, or just a different region. For users who don't want these extra functions, we could surround them with "#ifdef FACEBOOK_EXTRAS" or a [Conditional("FACEBOOK_EXTRAS")] attribute. I think both of these options would make more sense than a separate namespace.
Jun 21, 2007 at 3:44 PM
I agree with that. You just don't want to make it too hard to access though. Something like

_fbService.GetAppUsers()

vs.

_fbService.Extras.GetNonAppUsers()

would suffice.