You could offer a more instructive function than the
rather hypothetical theCodeToRunForALetter(),
perhaps something that counts vowels.
OIC, that use case would require a more flexible predicate.
Maybe something that counts occurences of "a".
You could offer a more instructive function than the
rather hypothetical theCodeToRunForALetter(),
perhaps something that counts vowels.
OIC, that use case would require a more flexible predicate.
Maybe something that counts occurences of "a".
Potentially quadratic, depending on whether we have lots of repeated values, such as boolean values:
Potentially quadratic, depending on whether we have lots of repeated values:
Potentially quadratic, depending on whether we have lots of repeated values, such as boolean values:
be generic
var aLetter = "a";
var theCodeToRunForALetter = () => {};
The library generically implements Observer pattern over the elements of an array. Consider presenting this function in a more generic way by renaming "letter" to "element".
Alternatively, consider offering a bit of scaffolding "in between", so the example may easily consume an "element" abstraction that immediately grounds out to a character or "letter".
quadratic complexity
My reading of the
spec
is that .splice() is required to take O(n) linear time.
var index = values.indexOf(value);
...
values.splice(index, 1);
I think you're computing once one time for each element of values?
In which case we're O(n^2) quadratic in number of values.
Consider overwriting with a
tombstone
sentinel instead.
Potentially quadratic, depending on whether we have lots of repeated values:
for ( var i = 0; i < values.length; i++ ) {
...
values.splice(i, 1);
If the caller can expect O(n) linear behavior for typical inputs, spell out in the documentation what those inputs would look like.
one time
var oneTimeDiffusees = [];
Sorry, I didn't get that concept. Citing an URL would go a long way toward explaining its motivation.
There seems to be some review context missing, at least for the example call, but hey, we'll take what we can get and run with it. Certainly the crunch() example has pedagogic value that helps motivate the library -- thank you for that.
As an app developer calling into this library, I could use some more clarity on what I'm responsible for passing in and what I can expect of the library's behavior. Partly this is due to the "hello world" example needing more lines of code than I would anticipate.
, entierly: function() {
nit, typo: Please use standard spelling of entirely.
conventional terminology
The verb "diffuse" is fine, you can certainly leave it as-is.
But consider renaming to "subscribe", more in line with the literature. One encounters "subscriber" far more often than "diffusee". The similarity between "diffuser" and "diffusee" seems unhelpfully distracting.
documentation
The explanatory prose accompanying this submission is very nice. It does not appear in the source code, and it absolutely should.
Several of the interior functions need comments, including returned functions.