Object equals self or empty object - javascript

I've got a JavaScript that uses this notation to make sure an object is initialized:
MyObject = MyObject || {};
I understand what it does, namely checking wether MyObject is anything, if not assigning an empty object to MyObject. I don't really know all the internals of JS that well, so I don't see how a logic comparison could be used in an assignment.
How does it work? Is there any other languages that allows this?

Depends on the language.
For example, in Ruby, you could use this style.
But in PHP, you could not use this style, because in PHP, the Logical Operators always returns a boolean value (true/false).
Conclusion:
If the Logical Operators always return a boolean value, then you could not use this style.
If the Logical Operators returns the first value when first value evaluates true otherwise return the second value, then you could use this style.

This syntax means "assign MyObject to itself, if it's defined. Otherwise, give it the empty object."
It works because Javascript treats undefined values as false, and defined ones as true. Combine that with lazy evaluation of logical expressions, and you get the behavior described above.

The logical-'or' operator has short-circuit semantics, which means that the right-hand operand is only evaluated if the left-hand one evaluates as false. Thus if MyObject is initialized, the statement reads MyObject = MyObject; (which does nothing), and otherwise it is MyObject = {};.

Related

If all JavaScript types are objects, then why are numbers be passed by value?

In articles about closures, you will often see closures being created inside of loops using self-invoking functions to pass the iterator variable to a returned function expression in order to create a closure around the value of the iterator variable at the time the self-invoking function was invoked, rather than its value after the loop finishes. Here is an example:
var func = [];
for (var i = 0; i < 3; i++)
{
func.push((function(j){ return function(){ console.log(j); }; })(i));
}
// Logs
// 0
// 1
// 2
// to the console
for (var i = 0; i < func.length; i++)
{
func[i]();
}
This technique works with both numbers and strings, based on my simple experiments. However, the same technique does not work with plain JavaScript objects. If an object is passed to a self-invoking function and referenced in a function expression, changes to the enclosed object are visible in the function expression because the value passed to the self-invoking function was a reference to an object and not a copy of the object, as is the case with numbers and strings.
I can understand why this technique would not work with a variable that stores an object, but I don't understand why this technique should work with numbers and strings, whose prototype chains terminate with Object.
Does this mean that strings and numbers are just special cases of objects that are handled differently by the interpreter, or am I suffering from a fundamental misconception?
First, it is not true that "all JavaScript types are objects". Primitive strings, numbers, and boolean values are not objects.
Second, everything in JavaScript is pass-by-value. It's important to understand what "pass-by-value" means. It means that when a function is called, like this:
var someVariable = something;
someFunction(someVariable); // <--- this is the function call
then what the language does is copy the value of someVariable and pass that copy to the function. What a "pass-by-reference" language would do is pass a reference to that variable to the function. Because a copy of the value of the variable is passed to the function in a pass-by-value world, the function has absolutely no way to modify the value of someVariable. In a "pass-by-reference" language, it does.
To some extent, C++ lets you employ either parameter passing scheme. JavaScript does not.
The fact that in JavaScript variables have object references as values sometimes does not mean the language is pass-by-reference. I know that that seems like a silly pedantic distinction, but it's important to understand that "pass-by-value" and "pass-by-reference" are precise terms used to describe language semantics. If they don't have precise meanings, they're useless for that purpose.
One more thing: JavaScript implicitly wraps string, number, and boolean primitive values in wrappers of the corresponding String, Number, and Boolean types when the primitive values are used as if they're objects. That's what happens when you do something as common as:
var five = "hello".length
The left-side operand of the . operator has to be an object, so there's no special-case here: there's an implicit promotion of the primitive string value to a String instance. (What the runtime really does under the covers, well, we can't tell and we shouldn't care. Conceptually, a temporary wrapper object is created, used, and thrown away.)
In javascript there are 6 primitive types: string,number,boolean,null,undefined,symbol - new in ECMAScript 2015. However there are Object wrapper classes for these primitives. All 6 except null and undefined have wrapper classes. Reference These primitive types are passed by value not by reference per the javascript design.

Why is 0[0] syntactically valid?

Why is this line valid in javascript ?
var a = 0[0];
After that, a is undefined.
When you do 0[0], the JS interpreter will turn the first 0 into a Number object and then try to access the [0] property of that object which is undefined.
There is no syntax error because the property access syntax 0[0] is allowed by the language grammar in this context. This structure (using terms in the Javascript grammar) is NumericLiteral[NumericLiteral].
The relevant part of the language grammar from section A.3 of the ES5 ECMAScript spec is this:
Literal ::
NullLiteral
BooleanLiteral
NumericLiteral
StringLiteral
RegularExpressionLiteral
PrimaryExpression :
this
Identifier
Literal
ArrayLiteral
ObjectLiteral
( Expression )
MemberExpression :
PrimaryExpression
FunctionExpression
MemberExpression [ Expression ]
MemberExpression . IdentifierName
new MemberExpression Arguments
So, one can follow the grammer through this progression:
MemberExpression [ Expression ]
PrimaryExpression [ Expression ]
Literal [ Expression ]
NumericLiteral [ Expression ]
And, similarly Expression can also eventually be NumericLiteral so after following the grammar, we see that this is allowed:
NumericLiteral [ NumericLiteral ]
Which means that 0[0] is an allowed part of the grammar and thus no SyntaxError.
Then, at run-time you are allowed to read a property that does not exist (it will just be read as undefined) as long as the source you are reading from either is an object or has an implicit conversion to an object. And, a numeric literal does indeed have an implicit conversion to an object (a Number object).
This is one of those often unknown features of Javascript. The types Number, Boolean and String in Javascript are usually stored internally as primitives (not full-blown objects). These are a compact, immutable storage representation (probably done this way for implementation efficiency). But, Javascript wants you to be able to treat these primitives like objects with properties and methods. So, if you try to access a property or method that is not directly supported on the primitive, then Javascript will temporarily coerce the primitive into an appropriate type of object with the value set to the value of the primitive.
When you use an object-like syntax on a primitive such as 0[0], the interpreter recognizes this as a property access on a primitive. Its response to this is to take the first 0 numeric primitive and coerce it into a full-blown Number object which it can then access the [0] property on. In this specific case, the [0] property on a Number object is undefined which is why that's the value you get from 0[0].
Here is an article on the auto-conversion of a primitive to an object for purposes of dealing with properties:
The Secret Life of Javascript Primitives
Here are the relevant portions of the ECMAScript 5.1 specification:
9.10 CheckObjectCoercible
Throws TypeError if value is undefined or null, otherwise returns true.
11.2.1 Property Accessors
Let baseReference be the result of evaluating MemberExpression.
Let baseValue be GetValue(baseReference).
Let propertyNameReference be the result of evaluating Expression.
Let propertyNameValue be GetValue(propertyNameReference).
Call CheckObjectCoercible(baseValue).
Let propertyNameString be ToString(propertyNameValue).
If the syntactic production that is being evaluated is contained in strict
mode code, let strict be true, else let strict be false.
Return a value of type Reference whose base value is baseValue and whose
referenced name is propertyNameString, and whose strict mode flag is
strict.
An operative part for this question is step #5 above.
8.7.1 GetValue (V)
This describes how when the value being accessed is a property reference, it calls ToObject(base) to get the object version of any primitive.
9.9 ToObject
This describes how Boolean, Number and String primitives are converted to an object form with the [[PrimitiveValue]] internal property set accordingly.
As an interesting test, if the code was like this:
var x = null;
var a = x[0];
It would still not throw a SyntaxError at parse time as this is technically legal syntax, but it would throw a TypeError at runtime when you run the code because when the above Property Accessors logic is applied to the value of x, it will call CheckObjectCoercible(x) or call ToObject(x) which will both throw a TypeError if x is null or undefined.
Like most programming languages, JS uses a grammar to parse your code and convert it to an executable form. If there's no rule in the grammar that can be applied to a particular chunk of code, it throws a SyntaxError. Otherwise, the code is considered valid, no matter if it makes sense or not.
The relevant parts of the JS grammar are
Literal ::
NumericLiteral
...
PrimaryExpression :
Literal
...
MemberExpression :
PrimaryExpression
MemberExpression [ Expression ]
...
Since 0[0] conforms to these rules, it's considered a valid expression. Whether it's correct (e.g. doesn't throw an error at run time) is another story, but yes it is. This is how JS evaluates expressions like someLiteral[someExpression]:
evaluate someExpression (which can be arbitrary complex)
convert the literal to a corresponding object type (numeric literals => Number, strings => String etc)
call the get property operation on result(2) with the property name result(1)
discard result(2)
So 0[0] is interpreted as
index = 0
temp = Number(0)
result = getproperty(temp, index) // it's undefined, but JS doesn't care
delete temp
return result
Here's a example of a valid, but incorrect expression:
null[0]
It's parsed fine, but at run time, the interpreter fails on step 2 (because null can't be converted to an object) and throws a run time error.
There are situations where you could validly subscript a number in Javascript:
-> 0['toString']
function toString() { [native code] }
While not immediately apparent why you would want to do this, subscripting in Javascript is equivalent to using dotted notation (albeit the dot notation limits you to using identifiers as keys).
I'd just like to note that this being valid syntax is not in any way unique to Javascript. Most languages will have a runtime error or a type error, but that's not the same thing as a syntax error. Javascript chooses to return undefined in many situations where another language might raise an exception, including when subscripting an object that does not have a property of the given name.
The syntax doesn't know the type of an expression (even a simple expression like a numeric literal), and will allow you to apply any operator to any expression. For example, attempting to subscript undefined or null causes a TypeError in Javascript. It's not a syntax error - if this is never executed (being on the wrong side of an if-statement), it won't cause any problems, whereas a syntax error is by definition always caught at compile time (eval, Function, etc, all count as compiling).
Because it is valid syntax, and even valid code to be interpreted. You can try to access any property of any object(and in this case 0 will be cast to a Number-object), and it will give you the value if it exists, otherwise undefined. Trying to access a property of undefined does not work however, so 0[0][0] would result in a runtime error. This would still be classified as valid syntax though. There's a difference of what is valid syntax and what won't cause runtime/compiletime errors.
Not only is the syntax valid the result does not have to be undefined though in most, if not all sane cases it will. JS is one of the most pure object oriented languages. Most so called OO languages are class oriented, in the sense that you can't change the form (it's tied to the class) of the object once created, only the state of the object. In JS you can change the state as well as the form of the object and this you do more often than you think. This ability makes for some rather obscure code, if you misuse it. Numerals are immutable, so you can't change the object itself, not it's state nor it's form so you could do
0[0] = 1;
which is an valid assignment expression that returns 1 but doesn't actually assign anything, The numeral 0 is immutable. Which in itself is somewhat odd. You can have a valid and correct (executable) assingment expression, that doesn't assign anything(*). However the type of the numeral is a mutable object so you can mutate the type, and the changes will cascade down the prototype chain.
Number[0] = 1;
//print 1 to the console
console.log(0[0]);
//will also print 1 to the console because all integers have the same type
console.log(1[0]);
of course it's a far cry from the sane use category but the language is specified to allow for this because in other scenarios, extending the objects capabilities actually makes a lot of sense. It's how jQuery plugins hook into the jQuery object to give an example.
(*) It does actually assign the value 1 to the property of an object, however there's no way you can reference that (transcient) object and it will thus be collected at the nexx GC pass
In JavaScript, everything is object, so when interpreter parse it, it treats 0 as a object and tries to return 0 as a property. The same thing happens when you try to access 0th element of true or ""(empty string).
Even if you set 0[0]=1, it will set the property and its value in memory, but while you access 0 it treats as a number (Don't get confuse between treating as Object and number here.)

Weird Code - Dynamic properties in primitive and reference variables in javascript (JS)

I'm working through Learning Javascript Properly and am reading Chapter 4 of Professional Javascript for Web Developers. On p. 86 they say
Primitive values can’t have properties added to them even though
attempting to do so won’t cause an error. Here’s an example:
var name = “Nicholas”;
name.age = 27;
alert(name.age); //undefined
They also say that JavaScript does not treat strings as objects, like other languages do. I wanted to see if I could get it to print out name.age.
I tried
var name = "Nicholas";
name.age = 27, alert(name.age);
And got undefined.
Trying
var name = "Nicholas";
name.age = 27 & alert(name.age);
Also gave undefined.
But,
var name = "Nicholas";
alert(name.age = 27);
gives 27!
With regards to the text's original example, the author says
"Here a property called age is defined on the string name and assigned
a value of 27. On the very next line, however, the property is gone.
Only reference values can have properties defined dynamically for
later use."
What is going on with the comma separated assignment and function call - I knew you could use commas to separate variable assignments, but you can also do function calls? What are the limits to the comma in javascript?
How does the & operator work for chaining together code snippets? What is that operator and what should it be used for?
Why did my last example work when the other ones wouldn't? Does this have to do with scope?
Edit: Thanks JLRishe and SirReal. I didn't really understand JLRishe's answer until reading SirReal's, but I recommend reading both!
Really, the answer to all three of your questions has to do with how the ,, & and = operators are defined, and has nothing to do with properties on primitive values.
What is going on with the comma separated assignment and function call
Your second example is an example of the comma operator, and this is different from the comma used in variable declarations. It evaluates each of its operands one at a time from left to right, and the ultimate value of the expression is the value of the last operand.
How does the & operator work for chaining together code snippets?
The & operator evaluates its two operands from left to right and produces the result of applying a bitwise AND to them. Your alert() is executing as a side effect of this. The expression 27 & alert(name.age) evaluates to 0, and this is what is assigned to name.age (but this doesn't really do anything). You can see similar behavior with:
name.age = 27 * alert(name.age);
or
name.age = 27 - alert(name.age);
or several other operators.
Why did my last example work when the other ones wouldn't?
What you observed in your last example is the well-defined behavior of the = operator. It performs an assignment and produces the value of the right-hand side. The assignment doesn't actually happen in this case, for the reasons you quoted, but it evaluates to the value of the right-hand nonetheless, and that is what is passed to the alert() function.
& is bitwise AND, a comparison operator. It's used to compare values at the bit level. You should probably not be using this for chaining code together.
, (comma) is the comma operator.
The comma operator evaluates each of its operands (from left to right) and returns the value of the last operand.
There don't appear to be any limits to that, but there are not a lot of good reasons to abuse this. MDN suggests that this is mostly for working with multiple values in for loops.
=, the simple assignment operator allows chaining. That means x = y = 2 is valid and will result in x == 2 and y == 2. I haven't found explicit documentation to support this, but I think it's safe to infer that the result of the assignment is returned when using =, which is the strange behavoir you're seeing. While you can't actually set a property on a string, the value you try to set is returned in case you wanted to chain it or otherwise use it.
You can't think like this in javascript. Variable assignment will work in this context if the variable can be assigned but has no bearing on the value passed to the function, that is, in this case 27, not name.age.
var name = "Nicholas";
alert(name.age = 27);
This will always alert an integer of 27. This is because you are not just assigning the name.age property a value, you are also passing the value to the alert function regardless of the property you attempted to assign the value to.
Comma operators string together operands and evaluate them in the order that you define them. As they are evaluated separately name.age has no value when it is evaluated as the second operand in your example.
The & operator is a bitwise operator that converts both sides to integers and evaluates both sides as their 32 bit binary representations. As other comments and answers have pointed out if either the left or right side is NaN it is treated as 0.
Irrelevant detail added in original answer below
&& evaluates left to right, similar to comma operators, however if the left side evaluates to false, the right side is never evaluated. This allows you to chain a check and an evaluation together without errors. This is called short circuiting.
callback instanceof Function && callback();
The above example checks if callback is a function, only if it is TRUE will the right hand side be evaluated.
The reason alert(name.age = 27) works is because of how primitive wrapper types operate. Primitive values like booleans, numbers, and strings in javascript are treated as objects in certain special cases, permitting the use of methods (like substring()).
Normally, a primitive value would not be able to call a method since it is considered a primitive, not an object (reference type). However, there are primitive wrapper types that enable this to work behind the scenes.
The three primitive wrapper types are Number, Boolean, and String and correspond to their respective primitive values. When you execute a method on a primitive value what is actually happening is the following:
The primitive value is cast as an instance of the primitive wrapper type
The method is executed on the primitive wrapper instance (an object)
The primitive wrapper instance is destroyed (your value goes back to being a regular primitive value).
The variable name in the code example is a string primitive value. When the property .age is added to it, it must first be cast as an instance of the primitive wrapper type String. However, that instance is immediately destroyed after that call executes, which is why the only call that does not return undefined is the one that alerts the property at the same time it is assigned.
The major difference between reference types and primitive wrapper types is the lifetime of the object. When you instantiate a reference
type using the new operator, it stays in memory until it goes out of
scope, whereas automatically created primitive wrapper objects exist
for only one line of code before they are destroyed. This means that
properties and methods cannot be added at runtime. Take this for
example:
var s1 = “some text”;
s1.color = “red”;
alert(s1.color);//undefined
Here, the second line attempts to add a color property to
the string s1. However, when s1 is accessed on the third line, the
color property is gone. This happens because the String object that
was created in the second line is destroyed by the time the third line
is executed. The third line creates its own String object, which
doesn’t have the color property. (Zakas, 147)
This is also why the following code would have worked:
var name = new String("Nicholas");
name.age = 27;
alert(name.age); //27
Here we have an explicit construction of an instance of the String primitive wrapper type, so it survives as an actual object.
Source: Zakas, Professional Javascript for Web Developers, p. 147 3rd ed.

Difference between Object.getPrototypeOf(x) and x.constructor.prototype?

For most values of x that I have tested, the following evaluates to true:
Object.getPrototypeOf(x) === x.constructor.prototype
...but there are a few exceptions: if x is a string, the LHS of the expression above fails with an error like
TypeError: "abc" is not an object
...although, e.g., "abc".constructor.prototype evaluates to String.prototype. One gets analogous results if x is a number or a boolean.
What's going on? Are there more exceptions to the identity shown earlier?
More to the point, the above suggests that x.constructor.prototype is more robust than Object.getPrototypeOf(x).
Is there any good reason not to use x.constructor.prototype exclusively and forget entirely about the Object.getPrototypeOf(x)?
Strings (and other primitives) can behave a little weirdly.
Basically, when you try to access a property of a primitive, it is boxed in a Just-In-Time fashion using its Object equivalent, and then the property of that object is returned.
So in this case, when you try to access "abc".constructor, what's actually happening is the same as new String("abc").constructor (which of course returns the String object).
On the other hand, Object.getPrototypeOf does no such boxing, instead returning an error if you pass it anything that isn't an object.
As you suggest, x.constructor.prototype does seem to be a more reliable method of determining the constructor of something, since it does handle this "boxing" case. That said, personally I can't think of any real situation where something like this might be needed, since... well, typically, you already know what type something is. It's the same reason I don't see any real point in using === most of the time.
Object.getPrototypeOf is not supported by older browsers where as x.constructor.prototype is more cross-browser solution.
However, if available it is more reliable to use Object.getPrototypeOf because x.constructor can be changed like so: x.constructor = 'my new value';
I suggest you to create this polyfill function:
if (!Object.getPrototypeOf) {
Object.getPrototypeOf = function(o) { return o.__proto__ || o.constructor.prototype; };
}

What is "x && foo()"?

I saw somewhere else said,
x && foo();
 is equal to
if(x){
foo();
}
I tested it and they really did the same thing.
But why? What exactly is x && foo()?
Both AND and OR operators can shortcut.
So && only tries the second expression if the first is true (truth-like, more specifically). The fact that the second operation does stuff (whatever the contents of foo() does) doesn't matter because it's not executed unless that first expression evaluates to something truthy. If it is truthy, it then will be executed in order to try the second test.
Conversely, if the first expression in an || statement is true, the second doesn't get touched. This is done because the whole statement can already be evaluated, the statement will result in true regardless of the outcome of the second expression, so it will be ignored and remain unexecuted.
The cases to watch out for when using shortcuts like this, of course, are the cases with operators where defined variables still evaluate to falsy values (e.g. 0), and truthy ones (e.g. 'zero').
This is known as short-circuit evaluation.
In this case, if x is False, then foo() doesn't need to be evaluated (the result of && will always be False); if x is True, it does need to be evaluated (even if the result is thrown away).
It's not exactly equivalent. The first one is an expression with a return value you can use; the second one is a statement.
If you are not interested in the return value (that is, the information whether both x and foo() evaluate to a truthy value), they are equivalent, but normally, you should use the boolean-logic version only if you want to use it as a boolean expression, e.g.:
if (x && foo()) {
do_stuff();
}
If you are only interested in running foo() conditionally (when x is truthy), the second form is to be preferred, since it conveys the intention more clearly.
A reason people might prefer the boolean-logic version might be that javascript is subject to an unusual restriction: source code size (more verbose source code means more bandwidth used); since the boolean-logic version uses less characters, it is more bandwidth-efficient. I'd still prefer the more verbose version most of the time, unless the script in question is used a lot - for a library like jQuery, using optimizations like this is perfectly justifyable, but in most other cases it's not.
In javascript, the && operator evaluates left to right and returns the value of the rightmost operation. If the first condition evaluates to false, it doesn't evaluate the second. So its a shorthand of saying "if something is not null or undefined, do something"
It is short circuiting.
The && operator works like this: It does the logical or of the two operands on both side. If the left hand side has a non zero value then the right hand side is evaluated to determine the truth value. If the left hand side is zero then whatever the right hand side be, the expression will evaluate to 0, therefore the right hand side is not evaluated. So in effect, if x is non-zero then only foo is called, and if x is 0 then foo is not called, and thus, it works like if - else in this case.

Categories

Resources