Simplifications, optimizations and new fetures for Observable.js

Feature Suggestions
1

Hi develepors!

I little rewrote Observable.js to get more simple access to enumerables + performance some improvements

Motivation:

instead

var ob = Observable('a', 'b', 'c');
var valueA = ob.getAt(0);
var valueB = ob.getAt(1);
ob.replaceAt(2, 'd');

just write

var valueA = ob[0];
var valueB = ob[1];
ob[2] = 'd';

And it’s done!

You can compare old/new vertsion on GitHub: link

What are you thinking about?

Warning! Need additional code for add/remove/insert methods, so its on WIP status

PS

You can test it on repl: https://repl.it/Cmy7/0

2

Hi,

Thanks for the suggestion!

This is a nifty feature, but the cost of defining all those properties on each observable is very high, and not worth it just to get a slightly nicer syntax. It would actually represent a major performance cost.

Also, next time you want to submit a diff, leave line breaks and whitespaces intact. We will never accept a diff with this much code churn. If we were to accept this diff, we would have to read through hundreds of changes just to make sure we didn’t miss something.

3

Hi, Andrers

Thanks for feedback. I tested on desktop and indexed version faster on all desktop’s browsers. On my iphone 5s in Safari I got this results:

 get by prop index (new way) x 76,726 ops/sec ±6.36% (47 runs sampled)
 get by func call (old way) x 395,733 ops/sec ±18.68% (46 runs sampled)
 set by prop index (new way) x 256,594 ops/sec ±1.56% (58 runs sampled)
 set by func call (old way) x 9,053 ops/sec ±2.02% (54 runs sampled)

so GET indexer accessesor slowdown by x5, but SET accessesor huge faster over x28 times! I don’t why, It’s very strange…

But anyway this way of accessing to array elements just alternative, you can still use standart getAt/replaceAt, without any compatibility conflicts

Online test by performance.js: https://dl.dropboxusercontent.com/u/33221668/Observable/perfTests.html

and code: https://github.com/MaxGraey/fuse-observable/blob/master/perfTests.html

4

I am sure the lookups are fast, but I’m talking about the overhead of defining the properties for every observable (creation time).

5

It’s true, in this case we have large creation’s overhead