I am sorry if this is a duplicate, so far I couldn't find the same question.
I have an Object with various methods in my __proto__ member.
Let's call the type of this object myObjectType.
Later on I have to do a JSON.stringify(myObjectType). The problem is that then when I build my object from the previous obtained JSON string the type of my Object is plain Object, I lost all the methods I had.
Does any one see why ?
search google for javascript object serialization.
GSerializer library
There's no standardized way of incorporating functions into JSON data. You can do something yourself — that is, write your own JSON serializer that incorporates functions according to some convention — but with straight standard JSON you get numbers, strings, booleans, and null, plus of course objects with named properties and arrays. No functions, just data.
I'd highly recommend Douglas Crockford's libraries:
https://github.com/douglascrockford/JSON-js
Related
Why is it that in Javascript, methods that relate to numbers are stored in the Math object? For example, to round you would need to do Math.round(5.2)
On the other hand, for strings I can just do “hello”.toUpperCase()
Why not String.toUpperCase(“hello”)
Like why cant we do 2.5..round() like how we would do "hello".toUpperCase()
Is there a reason why things are organized this way?
We can't do something like:
2.toString();
directly, but we can:
console.log((2).toString());
This is suspicious to me... so i think javascript convert object literals in a specific generic type, something like String, and then makes the operation that is needed according the String method given.
In your example you said that Math object stores methods for making convenient number transformations, like parsing it to an int, parsing it to a float and etc.
But this is not exactly true, because we have also functions like:
window.parseInt();
window.parseFloat();
that are focused in.
And also we have the generic Number class which allows us to create a generic number as the java Integer which is different of java primitive int, so this clarify a bit what is going on here.
I think javascript have some methods for string and String and also number and Number but they are not the same, one is generic and the other is primitive, but... if this where true, the primitive objects should never have methods, so we can assume three possibilities:
For object literals methods javascript converts the primitive object (if it's a primitive object) to a generic object and uses the generic object method, or uses an static generic class method.
Primitive objects in javascript aren't primitive they are generic.
Primitive objects have been constructed with some attached methods to it.
I will not make a confirmation about what is, because i don't know really if some of these posibilities are the right, but in my opinion i think the first one is the more accurate of how javascript stores and uses object literal methods.
I’m new to data structure and I’m learning it in Javascript.
My Question is:
Why do we need hash tables when we 've objects in javascript?
Can anybody give me a situation where hash tables will be more useful than objects?
"Hashtable" is called different things in different languages. Java has Hashtable and HashMap, Ruby has Hash, Python has dict... in JavaScript, it's called Map.
Objects' keys are limited to strings; Map keys can be anything.
Objects support inheritance; a Map only contains what is specifically put into it.
Think you means Map instead of HashTable. IMHO Map may be more useful and perform better if you need one of that:
keep order of insertions of key/value pairs;
frequent additional and removal;
key which not String/Symbol.
I think you can obtain more information at MDN
The MDN docs on this are quite helpful: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#Objects_and_maps_compared
Most notably, using a map gives you the advantage of using anything as a key, maps retain order, and may perform better when constantly adding and removing values.
One thing bothered me quite a bit when learning Javascript while trying to incorporate CS concepts - what exactly is JSON? I heard of people calling it associative arrays, key value pair objects, Javascript Objects.
Correct me if I'm wrong - I know in Java Hash Maps are more or less key value pairs. Since I feel like JSON shares a lot of properties with that, can I safely call JSON objects hash maps without sounding like an idiot in interviews?
Thanks
No. You could call it a lightweight human readable structured text document. Human readable like xml, but not as verbose hence lightweight. You might compare it to other data encoding mechanisms like protocol buffers, yaml or (the previously mentioned) XML.
JSON - JavaScript Object Notation
Data objects consisting of attribute-value pairs.
Why does JSON only allow a string to be a key of a pair? Why not other types such as null, number, bool, object, array? Considering JSON is tightly related with JavaScript, could I conclude the reason from JavaScript specification (ECMA-262)? I'm totally a newbie to JavaScript, could you help me to point it out.
The JSON format is deliberately based on a subset of JavaScript object literal syntax and array literal syntax, and JavaScript objects can only have strings as keys - thus JSON keys are strings too. (OK, you can sort of use numbers as JavaScript object keys, but really they get converted to strings.)
Note that the point of JSON is that it is a string representation of data to allow easy exchange between programs written in different languages running on different machines in different environments. If you wanted to use an object as a key then that object would in turn have to be somehow represented as a string for transmission, but then the receiving language would need to be able to use objects as keys and that would mean you'd need a limited subset of JSON for those languages which would just be a mess.
"Considering JSON is a part of JavaScript"
No, it isn't. Newer browsers provide methods for creating and parsing JSON, but they're not part of the language as such except that JSON is a string format and JavaScript can do strings. JSON is always a string representation - it has to be parsed to create an object for use within JavaScript (or other languages) and once that happens JavaScript (or the other languages) treat the resulting object the same as any other object.
(Note also that a particular bit of JSON doesn't necessarily have any keys at all: it could just be an array, like '["one","two","three"]'.)
Main reason according to the discoverer of JSON representation is,
while parsing JSON data, there is a chance/possibility that, key
you are using to refer a value might be a reserved word in your
parsing language.
Refer this talk by Douglas Crockford, who is the discoverer of JSON representation.
Example :
{
id: 1234,
name: "foo",
do: "somthing"
}
Since JSON is a cross language compatibility, We can use this data set in many languages. But, the word do is a keyword in Javascript. It will end up in syntax error while parsing.
Because that is the way the specification was written.
It's very common in Javascript to come across Array-Like objects with some similarities to the build in Array type but without all of its methods or features. So much so that there are some tricks to convert Array-Like objects to "real" arrays for further manipulation.
This is even mentioned in Javascript: The Definitive Guide.
The questions is why is this pattern so common? Why not prefer the built-in Array type in all these cases?
Well, speaking about core Javascript objects, the arguments is a good example to talk about.
In this case it has been an array-like object since the beginning, appeared in the ECMAScript 1th Edition Specification already as a simple object.
Why? I think at that time there were only four built-in Array methods, and maybe the designer didn't think it worthed too much, later the change was proposed, but Microsoft (part of the TC39 committee) didn't approved the change, the fear of breaking the web has always been present.
Now going to host objects, the DOM, NodeLists come to my mind, I think they didn't wanted to use the native Array type due the dynamic behavior of these objects.
NodeLists generally are live objects, their structure is reflects any change on the underlying DOM structure...
Personally I like array-objects, because they are really lightweight, before ECMAScript 5, there were a lot of restrictions in core methods, regarding the usage of user-defined array-like objects.
For example, the apply method of function objects, in ECMAScript <= 3, allowed only either a real array or an arguments object as its second argument, now in ES5, the following is possible:
var arrayLike = {0: 'hello ', 1:'world', length:2};
(function (a,b) { alert(a+b); }).apply(null, arrayLike);
See also:
Why isn't a function's arguments object an array in Javascript?