On Mon, Jul 27, 2015 at 2:37 PM, Kevin Grandon <[email protected]> wrote: >> You can't trade one use case with another. > > I was referring to startup races and initialization, not callbacks. Promises > can easily guard this, and we do so all over gaia in other classes. >
We have already in agreement on how Promise can be used to prevent start-up races. The part we disagree is whether or not installing an Promise interface onto SettingsListener.observe() helps people more on introducing/fixing start-up races, or simply getting rid of the opportunity to allow people to install an multi-purpose callback. >> Share libraries can serve us right in a few things but wrapping >> mozSettings API shouldn't be one of it. > > I think one of the nice things of having a helper is the ability to have a > nice method (like SettingsObserver.observe), which listens to changes as > well as calls the callback with the current setting. I'm in favor of doing a > lightweight API wrappers where it makes our code a lot less verbose. One > option here is to add this to the platform, but we've often gotten pushback > in the past when adding things like this to the platform, and thus, a > library is born. I don't think that this is necessarily bad, and it follows > the extensible web manifesto, https://extensiblewebmanifesto.org/ I wholeheartedly agree libraries can be experimental playgrounds for API evolution, but specifically for this instance, SettingsObserver.observe() is not a nice method as it's simply an invitation to start-up races, and other stuff. I simply don't believe reviewers will be able to caught those errors in every patch in every app in the future. === The alternative would be keeping the method but try to deprecate the default argument and the callback. I have a simple proposal partial interface SettingsObserver { Promise<SettingsValueHolder> observe(string key, any defaultValue, function callback) } interface SettingsValueHolder { void addObserver(function callback) void removeObserver(function callback) attribute string key attribute any value } observe() would console.warn() when there is a defaultValue or callback passed into it. On the warning we ask developers to migrate to handling the Promise interface and interact with SettingsValueHolder instead. The defaultValue will not be filled into SettingsValueHolder#value. Would that be the "evolution" you are looking for? Not sure the complexity will cause more push back than simply deprecate the method. _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
