3 ms·

The hostname of our servers is indeed hardcoded in the framework. So, yes, that's a 'singleton' in the same way that configuring your database hostname in Rails

The hostname of our servers is indeed hardcoded in the framework. So, yes, that's a 'singleton' in the same way that configuring your database hostname in Rails is a singleton. So far our developers have had a lot of success building upon Parse. There are certainly some missing pieces (like the one pointed out in another comment on this post) but none of them have related to our overall architecture. I invite you to let us know what it should look like ideally at founders@parse.com or even stop by our office. We love to talk with developers.

nupark2 15y ago
The hostname of our servers is indeed hardcoded in the framework. So, yes, that's a 'singleton' in the same way that configuring your database hostname in Rails is a singleton. I get the impression that arguing this further is a dead end. I'd suggest looking at NSManagedObjectContext for a basic approach that doesn't rely on global state / global variables, and while imperfect in many ways, is at least familiar to existing ObjC developers. Lastly, I'd look into the research into the effects of global variables on program interdependence, as well as the numerous discussions on the negative impact on maintainability, composability. Regardless of the above, it sounds like Parse will likely not be a good fit for our (large, complex, and top-chart) applications. If we're not the target audience, then no problem.
- lacker 15y ago
  We did look at NSManagedObjectContext... but NSManagedObjectContext doesn't support polymorphism. http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObjectContext_Class/NSManagedObjectContext.html http://developer.apple.com/library/mac/#documentation/Cocoa/... You are strongly discouraged from subclassing NSManagedObjectContext. The change tracking and undo management mechanisms are highly optimized and hence intricate and delicate. Interposing your own additional logic that might impact processPendingChanges can have unforeseen consequences.
  - nupark2 15y ago
    We did look at NSManagedObjectContext... but NSManagedObjectContext doesn't support polymorphism. Yes, it does. For a few reasons: 1) It is passed around as an instance, not a global variable, and as such, each instance can be individually configured to behave differently (such as with a different persistence implementation), while still responding to defined API. 2) NSManagedObjectContext can be subclassed. 3) Apple can improve the implementation (and recommend subclassing in the future) without breaking or modifying any existing client code. You're confusing 'polymorphism' with subclassing. Related, but not the same. --- Now, I did say that NSManagedObjectContext has many flaws -- and it does, but they're largely unrelated to the use of global variables that we're addressing here. And, since I'm being downvoted for technical discussion (presumably by you guys or your friends, because I've never seen anything like this to comments like mine on hacker news), I'm going to respond personally: Your need to find (and listen to) an advisor who has a significant stake in the ObjC space and more experience with API design than you have. You appear to be approaching your API from a Rails-centric perspective, not one rooted in Objective-C application development experience, and certainly not one rooted in the experience of architecting large shipping desktop/mobile applications. Then again, maybe your target audience are just small throw-away apps, in which case your API is probably fine -- just about any API would be.

nupark2 15y ago

The hostname of our servers is indeed hardcoded in the framework. So, yes, that's a 'singleton' in the same way that configuring your database hostname in Rails is a singleton. I get the impression that arguing this further is a dead end. I'd suggest looking at NSManagedObjectContext for a basic approach that doesn't rely on global state / global variables, and while imperfect in many ways, is at least familiar to existing ObjC developers. Lastly, I'd look into the research into the effects of global variables on program interdependence, as well as the numerous discussions on the negative impact on maintainability, composability. Regardless of the above, it sounds like Parse will likely not be a good fit for our (large, complex, and top-chart) applications. If we're not the target audience, then no problem.

lacker 15y ago
We did look at NSManagedObjectContext... but NSManagedObjectContext doesn't support polymorphism. http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObjectContext_Class/NSManagedObjectContext.html http://developer.apple.com/library/mac/#documentation/Cocoa/... You are strongly discouraged from subclassing NSManagedObjectContext. The change tracking and undo management mechanisms are highly optimized and hence intricate and delicate. Interposing your own additional logic that might impact processPendingChanges can have unforeseen consequences.
- nupark2 15y ago
  We did look at NSManagedObjectContext... but NSManagedObjectContext doesn't support polymorphism. Yes, it does. For a few reasons: 1) It is passed around as an instance, not a global variable, and as such, each instance can be individually configured to behave differently (such as with a different persistence implementation), while still responding to defined API. 2) NSManagedObjectContext can be subclassed. 3) Apple can improve the implementation (and recommend subclassing in the future) without breaking or modifying any existing client code. You're confusing 'polymorphism' with subclassing. Related, but not the same. --- Now, I did say that NSManagedObjectContext has many flaws -- and it does, but they're largely unrelated to the use of global variables that we're addressing here. And, since I'm being downvoted for technical discussion (presumably by you guys or your friends, because I've never seen anything like this to comments like mine on hacker news), I'm going to respond personally: Your need to find (and listen to) an advisor who has a significant stake in the ObjC space and more experience with API design than you have. You appear to be approaching your API from a Rails-centric perspective, not one rooted in Objective-C application development experience, and certainly not one rooted in the experience of architecting large shipping desktop/mobile applications. Then again, maybe your target audience are just small throw-away apps, in which case your API is probably fine -- just about any API would be.