This comment was originally written by ross.dart...@gmail.com

I wish you could edit these posts!

'remote process' was bad choice of terms; I meant 'some service in my isolate that the ui does not talk with but which also has access to my bound data'. Perhaps that service is talking to a remote process, or just doing its own thing.

Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Library-Mirrors, Triaged labels.

Observability and data binding are very useful base level functionality. They do not belong in the mirror library. There is a lot of work on that elsewhere in Dart.

Added NotPlanned label.

This comment was originally written by dev...@futureperfect.info

#­3 I agree that object observability is a very useful base level functionality. Would there be any worth to opening a new feature request in the vein of TC39's Object.observe? Or would it be futile?

They have got this right, and it is a very compelling reason to choose Javascript over Dart. Of course there are other reasons to choose Dart, but I believe Dart needs an Object.observe if it wants to compete long-term on the client side. This was also a pain point in C# (and Java) where observability is delegated to special "observable" objects.

All objects need to be (optionally) observable, which is the fundamental flaw that Object.observe has so wisely solved for the Javascript community. I am not interested in any package or framework solution because they cannot by definition solve this correctly.

JavaScript's Object.observe is a very low-level feature which does not take abstraction into consideration.
It observes physical changes, not logical changes. It's like looking at syntax without considering semantics.

Object.observe only looks at object properties - it can't detect that a getter would now return a different value. It may detect multiple changes that is really only a single logical change, or it might miss a change that happens on an embedded object which isn't observed.
For example, if I make a multi-object data structure, like a linked list, then observing the root object doesn't tell you anything about the elements of the list.

It does work if you restrict your data model to be simple JSON-like objects with no behavior and no abstraction - no private fields, no computed getters, no compound structures.
Only the most primitive Dart objects are so simple.
It "works" in JavaScript because many data-models are actually this simple and nobody uses or expects encapsulation.

In short, I think observing object property changes without understanding the object's meaning is not something that scales to languages with proper abstraction.
There's probably a good reason that languages like Java and C# doesn't have observability without the object's cooperation. You need the object to cooperate with you in telling which changes are actually meaningful, or even which changes happened at all - in the private internal model that you can't, and shouldn't, see from the outside.

This comment was originally written by dev...@futureperfect.info

JavaScript's Object.observe is a very low-level feature which does not take abstraction into consideration.

A low-level feature is precisely what I (and others) desire. I don't want someone else's abstraction.

Object.observe only looks at object properties - it can't detect that a getter would now return a different value.

Again, this is what I want and expect.

For example, if I make a multi-object data structure, like a linked list, then observing the root object doesn't tell you anything about the elements of the list.

Again, that is what I would expect it to do (provide change notifications for the root object).

In short, I think observing object property changes without understanding the object's meaning is not something that scales to languages with proper abstraction.

Who said that I don't understand the meaning of the objects in my system? I certainly do. And I'd also like to observe them. All objects can be decomposed into the simple types.

I'm getting the feeling that a new feature request would be futile, so I will let this go back to rest.

This comment was originally written by greg.low...@gmail.com

It's already pretty easy to do this in dart using the observe package.

http://www.dartdocs.org/documentation/observe/0.12.1+1/index.html#observe/observe

import 'package:observe/observe.dart';
import 'package:observe/mirrors_used.dart';

class Monster extends GameObject with Observable {
  @­observable int health = 100;
}

main() {
  var obj = new Monster();
  obj.changes.listen((records) {
    print('Changes to $obj were: $records');
  });
}

This comment was originally written by dev...@futureperfect.info

#­7 This issue is / was about object observe as a language and / or core feature. There is a fundamental difference between that and a package solution (e.g. the observe package). With a package solution you can only observe objects that are defined according to the rules of that package. As soon as your code wants to observe an object that is created with some other package, or with no observable package at all, you will be stuck. This is the fundamental difference. If you have not run into this in building large-scale GUI applications then I admit it may be hard to appreciate the difference. I suggest to read this article if you want a primer to appreciate the difference:

http://www.html5rocks.com/en/tutorials/es7/observe/

I've read the Object.observe tutorial and other descriptions.

The JavaScript Object.observe functionality works in JavaScript because it works for JavaScript objects and arrays - and that's all there is. In Dart, it would be the equivalent of an observe that only works on LinkedHashMap<String,...> and growable List. That's definitely doable, but not really something you can use in practice.

I'm not opposed to having some language supported way to easily make objects observable, but I still think that it needs cooperation from the object.

A Dart object can change its implementation between a field and a getter between versions without breaking anything. If it breaks observing it (because there is no way to know when the getter changes its value), then that kind of observing is incompatible with the Dart programming model.