Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES6 Map. WeakMap, Set, WeakSet support #1

Closed
devmondo opened this issue Aug 29, 2016 · 2 comments
Closed

ES6 Map. WeakMap, Set, WeakSet support #1

devmondo opened this issue Aug 29, 2016 · 2 comments

Comments

@devmondo
Copy link

Hi,

great library there, after making some tests, all is working great, except no support for the for mentioned new ES6 Data Types, is there a possibility to support them?

thanks in advanced.

@gullerya
Copy link
Owner

Hi,

Thanks for a feedback!

I've not planned it and actually my first intuitive answer was that those objects are not part of the functionality targeted by object-observer (OO) utility, but let me do some checks to see what's the gap.

2 questions for clarification:

  1. Can provide the simplest use-case where such on observation would be useful?
  2. All of these classes are able to receive a changes by both, their intrinsic APIs (set, add), they are also may be added new properties just as any other object in JS (var m = new Map(); m.prop = 'text'). I assume you are interested in an ability to observe the changes made by the APIs, right?

@gullerya
Copy link
Owner

Somewhat late response, yet still relevant.

First let's make an order:

  1. If the special objects in question are treated as regular objects (some properties added/read/deleted from them) - observation would work just fine; I'm aware of fact that once there was some problem on the level of native support for such a case, but AFAICS now it fixed.
  2. Beside being just a regular object, those objects are providing special means to hold the data within them via intrinsic APIs like set, get, delete etc. This is the case I'll be talking about right below:

I've reviewed a possibility to handle intrinsic APIs those objects as part of an observation, but decided that the they are not playing well with the current library design and will not be supported.

Especially this is the case for the sets, as there are actually no key there and the whole point of the observer is to provide a listener with the actual change and the path that has been changed. Of course, in case of sets there may be no path.
Maps are also problematic since their keys may effectively be anything - again there is a problem to generate path for such a cases.

And at the end, observation of anything passing through the internal APIs of Map/WeakMap/Set/WeakSet may be achieved in such an easy way (proxifying the methods themselves, we are talking about finite and quite small number of APIs) that I hardly can see justification to apply an observation pattern for such a use case.

I'm closing this issue with this conclusion right now, until some strong and well defined requirement of this will emerge again in any future with any reasonable solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants