Coalesce – Communication framework for distributed JavaScript
github.com
github.com
This and some other quirks together make things harder to understand. The idea seems really cool, but a clearer (even if not as fun to read) README would help. :)
If I were the maintainer, I'd reduce the amount of text (by moving extensive API docs somewhere else? cutting some of the stuff that is just-for-lulz?), and think of adding an overview—how coalesce fits among existing solutions. Yeah, dry and boring, but practical.
m && m.what? document.hello.to.value = m.what :
a.com.send({what: document.hello.to.value, where: 'magic' });
Urgh.However, bummer that despite the clear instructions, they never state what this does or why it might be helpful, for what problem.
So many developers take the attitude of "if you don't know why you need it, you shouldn't be learning about it" but I don't see why they do that. You should always assume that some outsiders will come along, and some of them will have use cases that could benefit from your solution, if only you would explain what the hell it is.
It is 17 digits long, which is 4 digits longer than the normal new Date().getTime()"
Is this serious? I can't find any assignment of "when" in the code. And why would you expect hyper precise timing from js? And if it has four more digits wouldn't it no longer be milliseconds?
https://github.com/amark/theory/blob/master/theory.js#L449
look at 'time.now()', called by when, and 'time.is()'.
time.is = (function(t){
t = ($=a.fns.$(time))||t;
return t? t instanceof Date : (+new Date().getTime());
});
time.now = (function(){
return a.num.ify((a.time.is().toString())+'.'+a.num.r(4));
});
...
num.random = num.r = (function(l){
...
how cuteThe likely reason for the extra 4 digits is to prevent collisions in timing.
The probability of messages having the same timestamp is already pretty low, this just divides that probability by ten thousand.
UUIDs are for uniqueness, but don't imply order.
Timestamps imply order, but not necessarily uniqueness.
Sometimes you want both. Some languages give you mechanisms to guarantee an increasing timestamp (Erlang's erlang:now(), for instance) for that purpose.
Now, if this is actually appending just random data, rather than an incrementing counter, you still are guaranteeing uniqueness (well, a reasonable guarantee of probably uniqueness), and have order to a specific coarseness, but beyond that all bets are off. My guess is that it's to imply an absolute ordering, but once you're sub-millisecond assume that it doesn't really matter if the order is accurate.