Provide a helper for notifying when accessor properties have changed about observe-js

[EisenbergEffect]

Another idea would be that if Object.observe is present and the observed value is coming from an accessor, fallback to using dirty checking for just that property. Basically, take a hybrid approach. Use Object.observe for what it can handle, but use dirty checking for everything else. You'd probably want to provide a way to mark an accessor function in the case that you want to handle notifying manually.

This is probably a bigger change in the library, but it would make things work consistently and take the burden off of the developer to write custom code every time they want to use an accessor (which by the way is going to become increasingly common.) I think it's a reasonable compromise.

[sjmiles]

The thing is that there is really no reason to use accessors, so there's not a great deal of momentum behind making them work well.

Maybe if you provide a use case (or two) where you want an accessor, we can discuss it and figure out if we have more of a problem than I am suggesting.

The general notion is that instead of creating an accessor which calculates values on demand, one can have a computed property whose value is constructed when the dependent values change.

[rafaelw]

The key semantic difference with accessors as computed properties is that their dependencies can be resolved synchronously on access (a-la polymer published attributes).

I agree, it'd be nice to see use cases for exposing a more general form of this, but I can easily imagine it exists.

I suspect it'll make sense to support both patterns (computed data properties vs computed accessor properties) and there will be a familiar expressiveness vs expense tradeoff. Hopefully we can arrive at good syntax and sugaring for both patterns and good docs that correctly outline the trade-offs.

[sjmiles]

key semantic difference with accessors as computed properties is that their dependencies can be resolved synchronously on access

True, but this feature is defeated as soon as you try to use your accessor in a data-binding scenario, which is the only time there is actually a problem with accessors. Any data-binding machinery has to query the value of the accessor (and possibly repeatedly when dirty checking).

[sjmiles]

Oops, sorry, I responded to a different concept then what you actually wrote, sorry about that.

There is a concept that an accessor can defer processing until the value is queried, that's the bit that is defeated by employing the accessor in a binding context.

With respect to synchronous access, I'm not sure where that's a virtue, since the rest of our system is asynchronous.

(a-la polymer published attributes)

You refer to attribute changes being processed synchronously? This is more of a conceit to folks' expectation of the platform rather than something Polymer actually advocates.

All other data side-effects in Polymer resolve asynchronously (as you of course know =P).

[sjmiles]

Sorry again for the noise, my comments above are supposed to be about exploring this topic and not somehow suggesting you (rafaelw) don't have it right. You are the expert in data systems.