Mods: please consider replacing the story link with this one, this is the link I expected. The current one goes to some kind of "highlighting" site which presents a very short version of the text, which never kind of answers the question ("what happened"). Very annoying in my opinion.
Well that's because this is checking if a value may be a valid number.
It's not safely converting the value to a number.
That's done after a parseFloat()
And this is the reason why Google is that worried about 'european privacy'.
Being less reliant on american companies is not that bad for the rest of the world.
Problem is quite a few european countries right now don't trust american companies anymore so they are working on their own mail service, cloud, network and hardware components, ... (you know if american companies agreed with american government to spy on us they kinda deserve a nice fk off).
So who is damaged by this european behaviour? American companies.
And now Google is suddenly concerned about our privacy.
"if american companies agreed with american government"
Just as a reminder, The government threatened to fine Yahoo $250,000 a day if it did not immediately cave in and comply with the secret court order.
http://www.wired.com/2014/09/feds-yahoo-fine-prism/
This blog post could actually be Google's way of silently signaling us that the US gov't is still strong arming american companies, and it needs the help of public pressure in order to keep our information safe and secure.
> could actually be Google's way of silently signaling us that the US gov't is still strong arming american companies
Or it could be Googles way of looking like a good guy without actually doing anything. How you look at it depends on how much you want to trust them, or any other company that does something similar.
Personally I will never ascribe good intentions to any amoral entity. Google is going to do like every other business will do, what ever it takes to increase the bottom line.
>> "The government threatened to fine Yahoo $250,000 a day if it did not immediately cave in and comply with the secret court order."
Do you think that really would have happened if the CEO or a high ranking employee came out publicly and explained what was happening? There is no way the fines would have happened or anyone would have been prosecuted. Sure the USG could have done it but they would have been insane to.
Be very careful thinking that they would not have attempted to prosecute them and/or punish the company for doing so. The wonderful fun of these secret courts, that we are stuck with for the moment, is that everything the do is stuck under gag order. You have to deal with the prospect of an angry judge or prosecutor at that point, and don't discount the likelihood of them being vindictive.
There's the EU-funded FI-WARE cloud platform. Completely free to use for European start-ups and comes with 80 million euros in EU grants for start-ups using it. http://www.fi-ware.org/
Let's say you have a regular JS array. There is a reference to it in memory and it has a certain value. Now you change an element in that array. You've just mutated it. In JS, the reference in memory doesn't change, but now the value of what it's pointing to has. So in order to know if the value has changed, you need to do a comparison on every element on that array, which is expensive.
Now let's say you have a immutable array (such as from the Immutable FB library or Mori). If you change an element in that array, you get a new array and a new array reference in memory. In other words, if you check that the reference in memory is the same, you are guaranteed that the value is the same (in this case, the array). So checking for equality is fast and cheap because you are only checking the reference, not each value in the array.
One way this is important in React is that now if your component state (or entire app state) is represented by an immutable data structure, you can just check for reference equality in the shouldComponentUpdate() method when deciding to re-render that component. If the reference is equal, you are guaranteed that the data backing that component hasn't changed and you can return false, telling React not to re-render.
What's surprising is that people have made these data structures also very memory efficient. You can see David Nolan talking about how they work and memory comparisons here: https://www.youtube.com/watch?v=mS264h8KGwk
Note that you can have cheap equality detection by using e.g. flags or revision counters and so on (but there are limits due to JavaScript's nature..). The problem is that JavaScript currently doesn't support this properly out of the box, but Object.observe is coming in the next standard.
I personally like the safety benefits of immutability. You can give objects to functions and not worry about the functions changing the object. The only way to guarantee that otherwise is to clone the object, but that takes quite a bit of performance.
The difference is that if you use Object.observe to track changes, then you don't have the ability to hold onto the previous version of an object and know what the old value was.
This is important for animations where you want to animate from the object's old value to the new value.
Good to know. I never got into immutable collections because I presumed they would result in things being allocated all the time (and that that would be expensive).
Persistent data structures allow for the appearance of cloning (you have a new thing) but are much more efficient behind the scenes (you don't actually copy everything). So if you find yourself doing a lot of defensive cloning, then Mori or this library would probably be a lot faster for you.
It is a guarantee to you that the data structure has not been tampered with by the time it reaches you.
// pseudo code
var fruitBasket = new FruitBasket('banana, 'apple)
muckWithFruits(fruitBasket)
suspiciousLogger(fruitBasket)
weirdCallback(fruitBasket)
// here
assert(fruitBasket.length == 2)
By the time we reach "here", we know that none of the functions since the inception of fruit basket have tampered with it.
This may not be a big deal if you are disciplined about never modifying your source data, but this moves the guarantee from a soft one to a mechanical one.
And then there's all this typical stuff about functional programming blah blah... But that's the most practical example I can think of.
In multi-threaded environments, immutable objects are thread-safe.
When multiple threads are sharing data, you would normally have to worry about synchronization. However, immutable data structures guarantee that the shared data will not change, so synchronization issues simply go away.
That said, I'm not sure how this applies to JS, which is single-threaded.
