Also, maybe this is a better pattern to encourage:

final _fieldName = new Property<T>(val);
T get fieldName => _fieldName.value;
T set fieldName(x) { _fieldName.value = x; }

... it's even worse at declaration time, but avoids the ".value" for access.

@blois @­sigmund -- thoughts here on best looking API?

cc @blois.
cc @sigmundch.

correction to above:

• T set fieldName(x) { _fieldName.value = x; }
• set fieldName(T x) { _fieldName.value = x; }

Ideas on how this would impact memory usage? In a system with an extremely rich set of bindable properties but which only a fraction of which are actually set, there's going to be quite a bit of overhead of these per-instance Property fields.

If there's a base-class for these then there could be sparse storage of non-default properties in a dictionary on the base, using something such as:
static const _fieldName = const Property<bool>(#fieldName, initialValue);
bool get fieldName => _fieldName.get(this);
void set fieldName(bool value) { _fieldName.set(this, value); }

Alternatively, may be able to do:
bool get fieldName => get(#fieldName, orElse() => defaultValue);
void set fieldName(bool value) { set(#fieldName, value); }

Removed Area-Polymer label.
Added Pkg-Polymer, Area-Pkg labels.

I'm trying to think of other alternatives, but I'm not sure I have the whole picture yet. Do we need both sync and async notifications, depending on how the property is used? Is this needed for Observable, or only for Bindable?

Some ideas I'm trying to think about is whether this could this be addressed by adding a second API that provides the other notification timing. For example, '.changesSync' in Observable, or 'openSync' in Bindable?

we need a property that redirects the getter/setter to another object, immediately. And is configured at runtime.
https://github.com/Polymer/observe-js/blob/master/src/observe.js#L1277 that one and bindToInstance right below it.

The only way I could think of to get that indirection is having an object for indirection.

We could do a transformation, but... it would have to be on in development mode too :(. I'm not really a fan of that, personally... At that point, it feels like we're inventing language syntax instead of just optimizing for deployment. But if you & Justin & Pete like the idea, go for it...

cc @justinfagnani.

Added this to the Later milestone.
Removed Priority-Unassigned label.
Added Priority-Medium label.

Issue #13567 has been merged into this issue.

Added Polymer-P-2 label.

Removed this from the Later milestone.

Removed Polymer-P-2 label.
Added Polymer-Milestone-Later label.

Removed Polymer-Milestone-Later label.
Added PolymerMilestone-Later label.

I've been looking into this while working on rolling the polymer package.

The good news - the hacky code moved out of observe-js and now lives in polymer.
The bad news - the hack of redefining the prototype is still there and is also used for computed properties.

If I understand correctly, here is my understanding of how timing is different here. The logic is differs when there is a binding on a property and when there is not, so here is are details for each case. I am using foo as an example. In JS it represents the public property, and foo_ is the private property (copied from the originally declared foo).

No bindings:
  - js read operation
      - invoke foo getter
      - returns foo_
    (all sync)

  - dart read operation
      - read foo's value
    (this is the only case where Dart and JS match in timing)

  - js write operation
      - invoke foo setter
      - set foo_
      - reflect foo_ value to attribute (if any)
    (all sync)

   - dart write operation
      - set foo
      ... (async break)
      - on change event, reflect to attribute

With a binding on the property:
   - js read operation
       - invoke foo getter
       - invoke bindable.deliver()
          - deliver may set foo_
          - if so, it reflects to attribute too
       - return latest value of foo_
     (all sync)

   - dart read operation
      - read foo's current value
        (which may not include latest changes from bindable)

   - js write operation
      - invoke foo setter
      - set value on bindable
      ... (async break)
      - when bindable delivers, set foo_
      - reflect to attribute
   
    - dart write operation
      - set foo
      ...
      - on change event, set value on bindable
      - also on change event, reflect to attribute
        (which may not be synchronously at the same time as we update bindable).

I decided to go with Pete's suggestion. Part of the reason is that notifications are delivered from the object that contains the property, not the property object itself.

The syntax looks like this:
  @­published
  int get property => readValue(#property, () => 42);
  set property(int value) => writeValue(#property, value);

The change is included in the roll of polymer to match 0.3.4 of polymer.js, which includes also computed properties. See:
  https://codereview.chromium.org/420673002/

Added Started label.

this was landed a while back

This issue has been moved to dart-archive/polymer-dart#169.