On 27 Nov 2013, at 10:43 pm, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
> FWIW I would say: right diagnosis, wrong solution. > > What on earth is going on with your app(s) that requires preferences to be > deleted? If, after all these years of your being a very accomplished > developer, your apps aren’t robust enough to deal with unusable or > inconsistent values in prefs — or, more to the point, put the prefs into such > a state to begin with — then I humbly suggest you treat that as a major bug, > and fix it. Absolutely correct, and we have very diligently done this whenever it has arisen. > > Is there a genuine reason why you can’t robustify your app’s dealings with > preferences, and avoid the entire problem of deleting them? The point is, if we could predict all bugs, they wouldn’t be there. We’ve had rare cases in the past where a prefs file has caused an issue. Obviously we did not anticipate it, otherwise it would have been discovered in testing and fixed before it got out into the wild, but we know that nobody’s perfect, and not every case can be tested for. Therefore we approach things with the cautious knowledge that no matter how hard we try, there will always be bugs. Since we’ve experienced bugs caused by prefs in the past, it’s not impossible that there could be other bugs triggered by bad prefs in the future. We need to have something up our sleeves if that occurs (like having a fire department). Deleting the prefs file has been an acceptable solution in the past because we know it’s super-rare that it’s needed. We always follow up where we can and find out the real cause and fix it, so these problems are virtually non-existent now, but we can’t be 100% certain. One of the things that our app allows is that the user can build vector “styles” in pretty much any way that they can imagine. It means that there are literally billions of combinations. Each tool in the app might be working with any style at any time, and as a courtesy to the user we save the tool’s style data in the prefs so they can pick up where they left off. When we’ve had a problem with prefs, it’s usually turned out to be a user-built style that contains crazy values. We’ve worked extremely hard to make sure “crazy” values are impossible, but you can only make an app foolproof, not damn fool proof, and occasionally something totally unanticipated slips through. These days such occurrences are very rare, but as I say, we can’t guarantee there is certainty, given the sheer number of combinations making it impossible to test them exhaustively. But the other reason it’s nice to have a quick way to restore the original defaults is in development and testing itself, so that a “clean install” can be tested as well as an update where an existing set of prefs needs to be considered. In this case the command line is fine, but clicking a button even better. Even developers and testers like an easy life. —Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
