This project is read-only.

What is the reason for using internal for classes.

Feb 6, 2008 at 11:56 AM
Why is alot of the classes internal? what was the reason behind this? I am trying to use Facebook.NET but alot of the internal classes have basically made this impossible.
Feb 12, 2008 at 5:08 PM
Can you give an example of what you are trying and which internal classes you're running into?
Feb 13, 2008 at 1:19 AM
I agree that it is quite damning to have all these class constructors internal and having the classes sealed.

Just one of many examples:

removing these restrictions allows me, for example, to make a complex calls to Fql.ExecuteQuery and browse the results to call something like:
foreach (object result in (IEnumerable)results)
User user = new User((Hashtable)result);
// some code
why do that? For example, I've created my own session management through caching for FBML apps. Periodically, I check if there are users with new statuses since the last time I checked and update single user records of a cached list of users with the new records obtained.
For any object in Facebook.Net, there are many cases were I see I need to do custom queries that I cannot do with supplied services.
To save memory, I even sometimes store Json results in the cache, so removing these restrictions is then also useful to recreate an object from a Json string.
To do this, I had to to modify the source code and of course, at each release, I need to reintegrate my changes.

I would even like the classes to be inheritable (or defined as partial) so I can add my own stuff to them. Off hand, I can't think of an example, but I ran in many cases where adding a new method would have been much simpler.

I think having more flexibility in how using the classes allow for more creative coding!
Feb 14, 2008 at 6:41 AM
There are different opinions, and I am not suggesting everyone agree with the decisions, but there was some thought put into the choice. I agree that aetting strongly typed results from FQL queries is needed, and its on the mental todo list - essentially in addition to passing the query you pass in an entity type as well (this needs to be plumbed all the way to the data source control).

Making ctors public - sort of divided on this. FQL queries is really the only compelling reason because the code assumes a certain structure of the objects which only makes sense from a Facebook response. Once FQL queries are taken care of I am not so sure.

Make types unsealed - this would not really help other than in the FQL query scenario where you can specify the strongly result type (once that is done). Things like strongly typed APIs - eg. UsersService.GetUser all return User, and you won't be able to plug in your derived type. I'd recommend C# 3.0 extension methods for this scenario.

Partial types - doesn't apply - you can't create a partial class in another assembly.
Jul 16, 2008 at 3:33 AM
Edited Jul 16, 2008 at 3:34 AM
Is there a work around for this?

I want to do a simple Fql.Query to get all online friends' details and return as strong typed (User).

If i make calls to Friends.GetFriends()., Users.GetUsers, I waste bandwidth and have two make to callbacks which slows down the whole process. Plus I'm getting all friends instead of just online friends.


Jul 16, 2008 at 9:54 PM
As Nikhil mentionned, it's now probably easier to extend the core functionality of Facebook.Net with VS2008 C# extensions.

I'll have to see when developing my next Facebook application. I'll try to make my modifications to Facebook.Net easier to manage through extensions.