'any' vs 'Object'
any
is something specific to TypeScript is explained quite well by alex's answer.
Object
refers to the JavaScript object
type. Commonly used as {}
or sometimes new Object
. Most things in javascript are compatible with the object data type as they inherit from it. But any
is TypeScript specific and compatible with everything in both directions (not inheritance based). e.g. :
var foo:Object;
var bar:any;
var num:number;
foo = num; // Not an error
num = foo; // ERROR
// Any is compatible both ways
bar = num;
num = bar;
Object
is more restrictive than any
. For example:
let a: any;
let b: Object;
a.nomethod(); // Transpiles just fine
b.nomethod(); // Error: Property 'nomethod' does not exist on type 'Object'.
The Object
class does not have a nomethod()
function, therefore the transpiler will generate an error telling you exactly that. If you use any
instead you are basically telling the transpiler that anything goes, you are providing no information about what is stored in a
- it can be anything! And therefore the transpiler will allow you to do whatever you want with something defined as any
.
So in short
any
can be anything (you can call any method etc on it without compilation errors)Object
exposes the functions and properties defined in theObject
class.
Contrary to .NET where all types derive from an "object", in TypeScript, all types derive from "any". I just wanted to add this comparison as I think it will be a common one made as more .NET developers give TypeScript a try.
Bit old, but doesn't hurt to add some notes.
When you write something like this
let a: any;
let b: Object;
let c: {};
- a has no interface, it can be anything, the compiler knows nothing about its members so no type checking is performed when accessing/assigning both to it and its members. Basically, you're telling the compiler to "back off, I know what I'm doing, so just trust me";
- b has the Object interface, so ONLY the members defined in that interface are available for b. It's still JavaScript, so everything extends Object;
- c extends Object, like anything else in TypeScript, but adds no members. Since type compatibility in TypeScript is based on structural subtyping, not nominal subtyping, c ends up being the same as b because they have the same interface: the Object interface.
And that's why
a.doSomething(); // Ok: the compiler trusts you on that
b.doSomething(); // Error: Object has no doSomething member
c.doSomething(); // Error: c neither has doSomething nor inherits it from Object
and why
a.toString(); // Ok: whatever, dude, have it your way
b.toString(); // Ok: toString is defined in Object
c.toString(); // Ok: c inherits toString from Object
So Object
and {}
are equivalents in TypeScript.
If you declare functions like these
function fa(param: any): void {}
function fb(param: Object): void {}
with the intention of accepting anything for param (maybe you're going to check types at run-time to decide what to do with it), remember that
- inside fa, the compiler will let you do whatever you want with param;
- inside fb, the compiler will only let you reference Object's members.
It is worth noting, though, that if param is supposed to accept multiple known types, a better approach is to declare it using union types, as in
function fc(param: string|number): void {}
Obviously, OO inheritance rules still apply, so if you want to accept instances of derived classes and treat them based on their base type, as in
interface IPerson {
gender: string;
}
class Person implements IPerson {
gender: string;
}
class Teacher extends Person {}
function func(person: IPerson): void {
console.log(person.gender);
}
func(new Person()); // Ok
func(new Teacher()); // Ok
func({gender: 'male'}); // Ok
func({name: 'male'}); // Error: no gender..
the base type is the way to do it, not any. But that's OO, out of scope, I just wanted to clarify that any should only be used when you don't know whats coming, and for anything else you should annotate the correct type.
UPDATE:
Typescript 2.2 added an object
type, which specifies that a value is a non-primitive: (i.e. not a number
, string
, boolean
, symbol
, undefined
, or null
).
Consider functions defined as:
function b(x: Object) {}
function c(x: {}) {}
function d(x: object) {}
x
will have the same available properties within all of these functions, but it's a type error to call d
with a primitive:
b("foo"); //Okay
c("foo"); //Okay
d("foo"); //Error: "foo" is a primitive