Why does accessing a property of indexOf still compile?
I made a typo in TypeScript which was picked up during code review.
I used someArray.indexOf[someObject]
instead of someArray.indexOf(someObject)
.
I would expect an error from the IDE/Compiler. Instead, no errors were raised and the result was simply undefined.
Can anyone explain this?
typescript methods properties
add a comment |
I made a typo in TypeScript which was picked up during code review.
I used someArray.indexOf[someObject]
instead of someArray.indexOf(someObject)
.
I would expect an error from the IDE/Compiler. Instead, no errors were raised and the result was simply undefined.
Can anyone explain this?
typescript methods properties
1
What did you assign the result of? Because what you wrote is valid you are taking thesomeObject
member of theindexOf
method. Well, trying to. The only error would come from TypeScript compilation and only if you try to assign the result to something that doesn't match the expected type.
– vlaz
Jan 18 at 12:54
12
Welcome to javascript, where everything is an object!
– Jean-Baptiste Yunès
Jan 18 at 12:54
7
@DeWetvanAs I am actually curious about your problem - this seems like a genuine bug/problem with TypeScript see example here. It seems that if you are trying to assign to a variable of typenumber
, the result of.indexOf[someObject]
shouldn't be considered anumber
and thus the compilation would fail. That's the whole idea of TypeScript is - to enforce the types. The answers here focus on JS but ignore this.
– vlaz
Jan 18 at 13:43
@vlaz it was in fact a complex object with multiple properties.
– De Wet van As
Jan 18 at 19:50
add a comment |
I made a typo in TypeScript which was picked up during code review.
I used someArray.indexOf[someObject]
instead of someArray.indexOf(someObject)
.
I would expect an error from the IDE/Compiler. Instead, no errors were raised and the result was simply undefined.
Can anyone explain this?
typescript methods properties
I made a typo in TypeScript which was picked up during code review.
I used someArray.indexOf[someObject]
instead of someArray.indexOf(someObject)
.
I would expect an error from the IDE/Compiler. Instead, no errors were raised and the result was simply undefined.
Can anyone explain this?
typescript methods properties
typescript methods properties
edited Jan 18 at 13:54
Bergi
367k58546873
367k58546873
asked Jan 18 at 12:51
De Wet van AsDe Wet van As
1418
1418
1
What did you assign the result of? Because what you wrote is valid you are taking thesomeObject
member of theindexOf
method. Well, trying to. The only error would come from TypeScript compilation and only if you try to assign the result to something that doesn't match the expected type.
– vlaz
Jan 18 at 12:54
12
Welcome to javascript, where everything is an object!
– Jean-Baptiste Yunès
Jan 18 at 12:54
7
@DeWetvanAs I am actually curious about your problem - this seems like a genuine bug/problem with TypeScript see example here. It seems that if you are trying to assign to a variable of typenumber
, the result of.indexOf[someObject]
shouldn't be considered anumber
and thus the compilation would fail. That's the whole idea of TypeScript is - to enforce the types. The answers here focus on JS but ignore this.
– vlaz
Jan 18 at 13:43
@vlaz it was in fact a complex object with multiple properties.
– De Wet van As
Jan 18 at 19:50
add a comment |
1
What did you assign the result of? Because what you wrote is valid you are taking thesomeObject
member of theindexOf
method. Well, trying to. The only error would come from TypeScript compilation and only if you try to assign the result to something that doesn't match the expected type.
– vlaz
Jan 18 at 12:54
12
Welcome to javascript, where everything is an object!
– Jean-Baptiste Yunès
Jan 18 at 12:54
7
@DeWetvanAs I am actually curious about your problem - this seems like a genuine bug/problem with TypeScript see example here. It seems that if you are trying to assign to a variable of typenumber
, the result of.indexOf[someObject]
shouldn't be considered anumber
and thus the compilation would fail. That's the whole idea of TypeScript is - to enforce the types. The answers here focus on JS but ignore this.
– vlaz
Jan 18 at 13:43
@vlaz it was in fact a complex object with multiple properties.
– De Wet van As
Jan 18 at 19:50
1
1
What did you assign the result of? Because what you wrote is valid you are taking the
someObject
member of the indexOf
method. Well, trying to. The only error would come from TypeScript compilation and only if you try to assign the result to something that doesn't match the expected type.– vlaz
Jan 18 at 12:54
What did you assign the result of? Because what you wrote is valid you are taking the
someObject
member of the indexOf
method. Well, trying to. The only error would come from TypeScript compilation and only if you try to assign the result to something that doesn't match the expected type.– vlaz
Jan 18 at 12:54
12
12
Welcome to javascript, where everything is an object!
– Jean-Baptiste Yunès
Jan 18 at 12:54
Welcome to javascript, where everything is an object!
– Jean-Baptiste Yunès
Jan 18 at 12:54
7
7
@DeWetvanAs I am actually curious about your problem - this seems like a genuine bug/problem with TypeScript see example here. It seems that if you are trying to assign to a variable of type
number
, the result of .indexOf[someObject]
shouldn't be considered a number
and thus the compilation would fail. That's the whole idea of TypeScript is - to enforce the types. The answers here focus on JS but ignore this.– vlaz
Jan 18 at 13:43
@DeWetvanAs I am actually curious about your problem - this seems like a genuine bug/problem with TypeScript see example here. It seems that if you are trying to assign to a variable of type
number
, the result of .indexOf[someObject]
shouldn't be considered a number
and thus the compilation would fail. That's the whole idea of TypeScript is - to enforce the types. The answers here focus on JS but ignore this.– vlaz
Jan 18 at 13:43
@vlaz it was in fact a complex object with multiple properties.
– De Wet van As
Jan 18 at 19:50
@vlaz it was in fact a complex object with multiple properties.
– De Wet van As
Jan 18 at 19:50
add a comment |
4 Answers
4
active
oldest
votes
Quite easy.
someArray.indexOf
you know that this is a function
, which is also an object and can have properties.
By doing someArray.indexOf[someObject]
, you are trying to reach the property with the key valued to the value of someObject
.
Of course, it is not defined on the indexOf
function, so it returns undefined
.
Quick example that illustrates the syntax and the fact that a function can have properties ;) :
const array = ;
array.indexOf['anyValue'] = 'test';
console.log(array.indexOf.anyValue);
EDIT
Here is an attempt of an answer for the TypeScript side of the question.
As you already know, TypeScript is designed to be compatible with JavaScript. Therefore, as in JS, you can access a property of an object by the following ways:
- 'Statically':
obj.property
- 'Dynamically':
obj['property']
By using the 'static' way to access a property, of course, TypeScript will raise an error!
But with the dynamic way of accessing the property, there is no way TypeScript compiler can determine the type of it or if it exists or not, since the value between bracket will be evaluated at runtime, after TypeScript transpiling.
That's why it will be implicitly marked as any
.
As David Sherret mentioned in his answer, you can force TypeScript to raise an error by adding the flag --noImplicitAny
, please refer to his answer for more details about this!
Hoping this helps ;)
4
I think answers here are missing theTypeScript
tag. It's entirely reasonable to expect a compilation error in TS. Then again, it depends if you haveindex: number
andindex = arr.indexOf[obj]
then that should be a compilation error. Butindex: any
wouldn't throw a compilation error.
– vlaz
Jan 18 at 12:58
@vlaz +1. sjahan gives OP a quick explanation of theundefined
result but the main question remains...
– Florian
Jan 18 at 13:14
1
"Of course, someone could say the compiler could understand" Yes, the compiler would understand. That is the entire reason for the compiler to be there and if TypeScript can't figure out that type is undetermined, then what good is TS at all? That's just a logical examination of the statement - David Sherret's answer points out that TS does indeed understand undetermined types and can raise an error for it. So your edit dispenses incorrect assumptions and information.
– vlaz
Jan 18 at 15:52
@vlaz I think I didn't express myself correctly and my point could get misinterpreted. I'm going to edit the last part, thank you.
– sjahan
Jan 18 at 15:59
add a comment |
It does not error because the --noImplicitAny
compiler option is not enabled. With that compiler option enabled you will get an error as expected:
The reason is that an element access expression returns an object typed as any
when the type has no index signature defined (this is an implicit any
).
So again, since --noImplicitAny
is not enabled, it does not error. I highly recommend turning this compiler option on.
add a comment |
array.indexOf
is a function.
Functions are objects.
You were accessing the someObject
property of the array.indexOf
function.
You would have got undefined
.
const array = [1, 2, 3]
const someObject = 'asdasd'
console.log(array.indexOf[someObject])
// undefined
1
Array.indexOf
isundefined
,Array.prototype.indexOf
, on the other hand, is a function.
– Pavlo
Jan 18 at 13:48
You’re right! I fixed the typo in my answer. Thanks
– 0xc14m1z
Jan 18 at 13:54
add a comment |
The only real issue here is that you expected Typescript to throw an error that exposed the problem in your logic. The intended logic was to use curly braces and utilise the someArray.indexOf(someObject)
function.
What happened when you used square braces, someArray.indexOf[someObject]
, was that the JS runtime first converted your object someObject
into a string by calling the function someObject.toString
, which most likely returned "[object object]"
. Then the someArray.indexOf
object was queried for the key "[object object]"
which wasn't present, returning undefined
. As far as Typescript goes, this is completely fine.
David Sherret pointed out that --noImplicitAny
would have pointed out the error, but it would only have pointed out a different error, as he explained, which would not directly have helped you to find the flaw in your logic.
"As far as Typescript goes, this is completely fine." no, it's not. The result of this expression would be undetermined, TypeScript would recognise it as much and should report an error because the return type would beany
as opposed tonumber
. Which is not fine for TypeScript - remember, it's there to ensure the type safety. Saying "Oh, it's fine that you want one thing but you are have no guarantee of getting it" - that's the opposite of the core intention of TS.
– vlaz
23 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54254396%2fwhy-does-accessing-a-property-of-indexof-still-compile%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Quite easy.
someArray.indexOf
you know that this is a function
, which is also an object and can have properties.
By doing someArray.indexOf[someObject]
, you are trying to reach the property with the key valued to the value of someObject
.
Of course, it is not defined on the indexOf
function, so it returns undefined
.
Quick example that illustrates the syntax and the fact that a function can have properties ;) :
const array = ;
array.indexOf['anyValue'] = 'test';
console.log(array.indexOf.anyValue);
EDIT
Here is an attempt of an answer for the TypeScript side of the question.
As you already know, TypeScript is designed to be compatible with JavaScript. Therefore, as in JS, you can access a property of an object by the following ways:
- 'Statically':
obj.property
- 'Dynamically':
obj['property']
By using the 'static' way to access a property, of course, TypeScript will raise an error!
But with the dynamic way of accessing the property, there is no way TypeScript compiler can determine the type of it or if it exists or not, since the value between bracket will be evaluated at runtime, after TypeScript transpiling.
That's why it will be implicitly marked as any
.
As David Sherret mentioned in his answer, you can force TypeScript to raise an error by adding the flag --noImplicitAny
, please refer to his answer for more details about this!
Hoping this helps ;)
4
I think answers here are missing theTypeScript
tag. It's entirely reasonable to expect a compilation error in TS. Then again, it depends if you haveindex: number
andindex = arr.indexOf[obj]
then that should be a compilation error. Butindex: any
wouldn't throw a compilation error.
– vlaz
Jan 18 at 12:58
@vlaz +1. sjahan gives OP a quick explanation of theundefined
result but the main question remains...
– Florian
Jan 18 at 13:14
1
"Of course, someone could say the compiler could understand" Yes, the compiler would understand. That is the entire reason for the compiler to be there and if TypeScript can't figure out that type is undetermined, then what good is TS at all? That's just a logical examination of the statement - David Sherret's answer points out that TS does indeed understand undetermined types and can raise an error for it. So your edit dispenses incorrect assumptions and information.
– vlaz
Jan 18 at 15:52
@vlaz I think I didn't express myself correctly and my point could get misinterpreted. I'm going to edit the last part, thank you.
– sjahan
Jan 18 at 15:59
add a comment |
Quite easy.
someArray.indexOf
you know that this is a function
, which is also an object and can have properties.
By doing someArray.indexOf[someObject]
, you are trying to reach the property with the key valued to the value of someObject
.
Of course, it is not defined on the indexOf
function, so it returns undefined
.
Quick example that illustrates the syntax and the fact that a function can have properties ;) :
const array = ;
array.indexOf['anyValue'] = 'test';
console.log(array.indexOf.anyValue);
EDIT
Here is an attempt of an answer for the TypeScript side of the question.
As you already know, TypeScript is designed to be compatible with JavaScript. Therefore, as in JS, you can access a property of an object by the following ways:
- 'Statically':
obj.property
- 'Dynamically':
obj['property']
By using the 'static' way to access a property, of course, TypeScript will raise an error!
But with the dynamic way of accessing the property, there is no way TypeScript compiler can determine the type of it or if it exists or not, since the value between bracket will be evaluated at runtime, after TypeScript transpiling.
That's why it will be implicitly marked as any
.
As David Sherret mentioned in his answer, you can force TypeScript to raise an error by adding the flag --noImplicitAny
, please refer to his answer for more details about this!
Hoping this helps ;)
4
I think answers here are missing theTypeScript
tag. It's entirely reasonable to expect a compilation error in TS. Then again, it depends if you haveindex: number
andindex = arr.indexOf[obj]
then that should be a compilation error. Butindex: any
wouldn't throw a compilation error.
– vlaz
Jan 18 at 12:58
@vlaz +1. sjahan gives OP a quick explanation of theundefined
result but the main question remains...
– Florian
Jan 18 at 13:14
1
"Of course, someone could say the compiler could understand" Yes, the compiler would understand. That is the entire reason for the compiler to be there and if TypeScript can't figure out that type is undetermined, then what good is TS at all? That's just a logical examination of the statement - David Sherret's answer points out that TS does indeed understand undetermined types and can raise an error for it. So your edit dispenses incorrect assumptions and information.
– vlaz
Jan 18 at 15:52
@vlaz I think I didn't express myself correctly and my point could get misinterpreted. I'm going to edit the last part, thank you.
– sjahan
Jan 18 at 15:59
add a comment |
Quite easy.
someArray.indexOf
you know that this is a function
, which is also an object and can have properties.
By doing someArray.indexOf[someObject]
, you are trying to reach the property with the key valued to the value of someObject
.
Of course, it is not defined on the indexOf
function, so it returns undefined
.
Quick example that illustrates the syntax and the fact that a function can have properties ;) :
const array = ;
array.indexOf['anyValue'] = 'test';
console.log(array.indexOf.anyValue);
EDIT
Here is an attempt of an answer for the TypeScript side of the question.
As you already know, TypeScript is designed to be compatible with JavaScript. Therefore, as in JS, you can access a property of an object by the following ways:
- 'Statically':
obj.property
- 'Dynamically':
obj['property']
By using the 'static' way to access a property, of course, TypeScript will raise an error!
But with the dynamic way of accessing the property, there is no way TypeScript compiler can determine the type of it or if it exists or not, since the value between bracket will be evaluated at runtime, after TypeScript transpiling.
That's why it will be implicitly marked as any
.
As David Sherret mentioned in his answer, you can force TypeScript to raise an error by adding the flag --noImplicitAny
, please refer to his answer for more details about this!
Hoping this helps ;)
Quite easy.
someArray.indexOf
you know that this is a function
, which is also an object and can have properties.
By doing someArray.indexOf[someObject]
, you are trying to reach the property with the key valued to the value of someObject
.
Of course, it is not defined on the indexOf
function, so it returns undefined
.
Quick example that illustrates the syntax and the fact that a function can have properties ;) :
const array = ;
array.indexOf['anyValue'] = 'test';
console.log(array.indexOf.anyValue);
EDIT
Here is an attempt of an answer for the TypeScript side of the question.
As you already know, TypeScript is designed to be compatible with JavaScript. Therefore, as in JS, you can access a property of an object by the following ways:
- 'Statically':
obj.property
- 'Dynamically':
obj['property']
By using the 'static' way to access a property, of course, TypeScript will raise an error!
But with the dynamic way of accessing the property, there is no way TypeScript compiler can determine the type of it or if it exists or not, since the value between bracket will be evaluated at runtime, after TypeScript transpiling.
That's why it will be implicitly marked as any
.
As David Sherret mentioned in his answer, you can force TypeScript to raise an error by adding the flag --noImplicitAny
, please refer to his answer for more details about this!
Hoping this helps ;)
const array = ;
array.indexOf['anyValue'] = 'test';
console.log(array.indexOf.anyValue);
const array = ;
array.indexOf['anyValue'] = 'test';
console.log(array.indexOf.anyValue);
edited Jan 18 at 16:03
answered Jan 18 at 12:54
sjahansjahan
3,2802928
3,2802928
4
I think answers here are missing theTypeScript
tag. It's entirely reasonable to expect a compilation error in TS. Then again, it depends if you haveindex: number
andindex = arr.indexOf[obj]
then that should be a compilation error. Butindex: any
wouldn't throw a compilation error.
– vlaz
Jan 18 at 12:58
@vlaz +1. sjahan gives OP a quick explanation of theundefined
result but the main question remains...
– Florian
Jan 18 at 13:14
1
"Of course, someone could say the compiler could understand" Yes, the compiler would understand. That is the entire reason for the compiler to be there and if TypeScript can't figure out that type is undetermined, then what good is TS at all? That's just a logical examination of the statement - David Sherret's answer points out that TS does indeed understand undetermined types and can raise an error for it. So your edit dispenses incorrect assumptions and information.
– vlaz
Jan 18 at 15:52
@vlaz I think I didn't express myself correctly and my point could get misinterpreted. I'm going to edit the last part, thank you.
– sjahan
Jan 18 at 15:59
add a comment |
4
I think answers here are missing theTypeScript
tag. It's entirely reasonable to expect a compilation error in TS. Then again, it depends if you haveindex: number
andindex = arr.indexOf[obj]
then that should be a compilation error. Butindex: any
wouldn't throw a compilation error.
– vlaz
Jan 18 at 12:58
@vlaz +1. sjahan gives OP a quick explanation of theundefined
result but the main question remains...
– Florian
Jan 18 at 13:14
1
"Of course, someone could say the compiler could understand" Yes, the compiler would understand. That is the entire reason for the compiler to be there and if TypeScript can't figure out that type is undetermined, then what good is TS at all? That's just a logical examination of the statement - David Sherret's answer points out that TS does indeed understand undetermined types and can raise an error for it. So your edit dispenses incorrect assumptions and information.
– vlaz
Jan 18 at 15:52
@vlaz I think I didn't express myself correctly and my point could get misinterpreted. I'm going to edit the last part, thank you.
– sjahan
Jan 18 at 15:59
4
4
I think answers here are missing the
TypeScript
tag. It's entirely reasonable to expect a compilation error in TS. Then again, it depends if you have index: number
and index = arr.indexOf[obj]
then that should be a compilation error. But index: any
wouldn't throw a compilation error.– vlaz
Jan 18 at 12:58
I think answers here are missing the
TypeScript
tag. It's entirely reasonable to expect a compilation error in TS. Then again, it depends if you have index: number
and index = arr.indexOf[obj]
then that should be a compilation error. But index: any
wouldn't throw a compilation error.– vlaz
Jan 18 at 12:58
@vlaz +1. sjahan gives OP a quick explanation of the
undefined
result but the main question remains...– Florian
Jan 18 at 13:14
@vlaz +1. sjahan gives OP a quick explanation of the
undefined
result but the main question remains...– Florian
Jan 18 at 13:14
1
1
"Of course, someone could say the compiler could understand" Yes, the compiler would understand. That is the entire reason for the compiler to be there and if TypeScript can't figure out that type is undetermined, then what good is TS at all? That's just a logical examination of the statement - David Sherret's answer points out that TS does indeed understand undetermined types and can raise an error for it. So your edit dispenses incorrect assumptions and information.
– vlaz
Jan 18 at 15:52
"Of course, someone could say the compiler could understand" Yes, the compiler would understand. That is the entire reason for the compiler to be there and if TypeScript can't figure out that type is undetermined, then what good is TS at all? That's just a logical examination of the statement - David Sherret's answer points out that TS does indeed understand undetermined types and can raise an error for it. So your edit dispenses incorrect assumptions and information.
– vlaz
Jan 18 at 15:52
@vlaz I think I didn't express myself correctly and my point could get misinterpreted. I'm going to edit the last part, thank you.
– sjahan
Jan 18 at 15:59
@vlaz I think I didn't express myself correctly and my point could get misinterpreted. I'm going to edit the last part, thank you.
– sjahan
Jan 18 at 15:59
add a comment |
It does not error because the --noImplicitAny
compiler option is not enabled. With that compiler option enabled you will get an error as expected:
The reason is that an element access expression returns an object typed as any
when the type has no index signature defined (this is an implicit any
).
So again, since --noImplicitAny
is not enabled, it does not error. I highly recommend turning this compiler option on.
add a comment |
It does not error because the --noImplicitAny
compiler option is not enabled. With that compiler option enabled you will get an error as expected:
The reason is that an element access expression returns an object typed as any
when the type has no index signature defined (this is an implicit any
).
So again, since --noImplicitAny
is not enabled, it does not error. I highly recommend turning this compiler option on.
add a comment |
It does not error because the --noImplicitAny
compiler option is not enabled. With that compiler option enabled you will get an error as expected:
The reason is that an element access expression returns an object typed as any
when the type has no index signature defined (this is an implicit any
).
So again, since --noImplicitAny
is not enabled, it does not error. I highly recommend turning this compiler option on.
It does not error because the --noImplicitAny
compiler option is not enabled. With that compiler option enabled you will get an error as expected:
The reason is that an element access expression returns an object typed as any
when the type has no index signature defined (this is an implicit any
).
So again, since --noImplicitAny
is not enabled, it does not error. I highly recommend turning this compiler option on.
edited Jan 18 at 18:51
answered Jan 18 at 14:42
David SherretDavid Sherret
51.2k16120123
51.2k16120123
add a comment |
add a comment |
array.indexOf
is a function.
Functions are objects.
You were accessing the someObject
property of the array.indexOf
function.
You would have got undefined
.
const array = [1, 2, 3]
const someObject = 'asdasd'
console.log(array.indexOf[someObject])
// undefined
1
Array.indexOf
isundefined
,Array.prototype.indexOf
, on the other hand, is a function.
– Pavlo
Jan 18 at 13:48
You’re right! I fixed the typo in my answer. Thanks
– 0xc14m1z
Jan 18 at 13:54
add a comment |
array.indexOf
is a function.
Functions are objects.
You were accessing the someObject
property of the array.indexOf
function.
You would have got undefined
.
const array = [1, 2, 3]
const someObject = 'asdasd'
console.log(array.indexOf[someObject])
// undefined
1
Array.indexOf
isundefined
,Array.prototype.indexOf
, on the other hand, is a function.
– Pavlo
Jan 18 at 13:48
You’re right! I fixed the typo in my answer. Thanks
– 0xc14m1z
Jan 18 at 13:54
add a comment |
array.indexOf
is a function.
Functions are objects.
You were accessing the someObject
property of the array.indexOf
function.
You would have got undefined
.
const array = [1, 2, 3]
const someObject = 'asdasd'
console.log(array.indexOf[someObject])
// undefined
array.indexOf
is a function.
Functions are objects.
You were accessing the someObject
property of the array.indexOf
function.
You would have got undefined
.
const array = [1, 2, 3]
const someObject = 'asdasd'
console.log(array.indexOf[someObject])
// undefined
const array = [1, 2, 3]
const someObject = 'asdasd'
console.log(array.indexOf[someObject])
// undefined
const array = [1, 2, 3]
const someObject = 'asdasd'
console.log(array.indexOf[someObject])
// undefined
edited Jan 18 at 13:54
answered Jan 18 at 12:54
0xc14m1z0xc14m1z
1,534613
1,534613
1
Array.indexOf
isundefined
,Array.prototype.indexOf
, on the other hand, is a function.
– Pavlo
Jan 18 at 13:48
You’re right! I fixed the typo in my answer. Thanks
– 0xc14m1z
Jan 18 at 13:54
add a comment |
1
Array.indexOf
isundefined
,Array.prototype.indexOf
, on the other hand, is a function.
– Pavlo
Jan 18 at 13:48
You’re right! I fixed the typo in my answer. Thanks
– 0xc14m1z
Jan 18 at 13:54
1
1
Array.indexOf
is undefined
, Array.prototype.indexOf
, on the other hand, is a function.– Pavlo
Jan 18 at 13:48
Array.indexOf
is undefined
, Array.prototype.indexOf
, on the other hand, is a function.– Pavlo
Jan 18 at 13:48
You’re right! I fixed the typo in my answer. Thanks
– 0xc14m1z
Jan 18 at 13:54
You’re right! I fixed the typo in my answer. Thanks
– 0xc14m1z
Jan 18 at 13:54
add a comment |
The only real issue here is that you expected Typescript to throw an error that exposed the problem in your logic. The intended logic was to use curly braces and utilise the someArray.indexOf(someObject)
function.
What happened when you used square braces, someArray.indexOf[someObject]
, was that the JS runtime first converted your object someObject
into a string by calling the function someObject.toString
, which most likely returned "[object object]"
. Then the someArray.indexOf
object was queried for the key "[object object]"
which wasn't present, returning undefined
. As far as Typescript goes, this is completely fine.
David Sherret pointed out that --noImplicitAny
would have pointed out the error, but it would only have pointed out a different error, as he explained, which would not directly have helped you to find the flaw in your logic.
"As far as Typescript goes, this is completely fine." no, it's not. The result of this expression would be undetermined, TypeScript would recognise it as much and should report an error because the return type would beany
as opposed tonumber
. Which is not fine for TypeScript - remember, it's there to ensure the type safety. Saying "Oh, it's fine that you want one thing but you are have no guarantee of getting it" - that's the opposite of the core intention of TS.
– vlaz
23 hours ago
add a comment |
The only real issue here is that you expected Typescript to throw an error that exposed the problem in your logic. The intended logic was to use curly braces and utilise the someArray.indexOf(someObject)
function.
What happened when you used square braces, someArray.indexOf[someObject]
, was that the JS runtime first converted your object someObject
into a string by calling the function someObject.toString
, which most likely returned "[object object]"
. Then the someArray.indexOf
object was queried for the key "[object object]"
which wasn't present, returning undefined
. As far as Typescript goes, this is completely fine.
David Sherret pointed out that --noImplicitAny
would have pointed out the error, but it would only have pointed out a different error, as he explained, which would not directly have helped you to find the flaw in your logic.
"As far as Typescript goes, this is completely fine." no, it's not. The result of this expression would be undetermined, TypeScript would recognise it as much and should report an error because the return type would beany
as opposed tonumber
. Which is not fine for TypeScript - remember, it's there to ensure the type safety. Saying "Oh, it's fine that you want one thing but you are have no guarantee of getting it" - that's the opposite of the core intention of TS.
– vlaz
23 hours ago
add a comment |
The only real issue here is that you expected Typescript to throw an error that exposed the problem in your logic. The intended logic was to use curly braces and utilise the someArray.indexOf(someObject)
function.
What happened when you used square braces, someArray.indexOf[someObject]
, was that the JS runtime first converted your object someObject
into a string by calling the function someObject.toString
, which most likely returned "[object object]"
. Then the someArray.indexOf
object was queried for the key "[object object]"
which wasn't present, returning undefined
. As far as Typescript goes, this is completely fine.
David Sherret pointed out that --noImplicitAny
would have pointed out the error, but it would only have pointed out a different error, as he explained, which would not directly have helped you to find the flaw in your logic.
The only real issue here is that you expected Typescript to throw an error that exposed the problem in your logic. The intended logic was to use curly braces and utilise the someArray.indexOf(someObject)
function.
What happened when you used square braces, someArray.indexOf[someObject]
, was that the JS runtime first converted your object someObject
into a string by calling the function someObject.toString
, which most likely returned "[object object]"
. Then the someArray.indexOf
object was queried for the key "[object object]"
which wasn't present, returning undefined
. As far as Typescript goes, this is completely fine.
David Sherret pointed out that --noImplicitAny
would have pointed out the error, but it would only have pointed out a different error, as he explained, which would not directly have helped you to find the flaw in your logic.
answered Jan 18 at 23:13
Alex SteinbergAlex Steinberg
427411
427411
"As far as Typescript goes, this is completely fine." no, it's not. The result of this expression would be undetermined, TypeScript would recognise it as much and should report an error because the return type would beany
as opposed tonumber
. Which is not fine for TypeScript - remember, it's there to ensure the type safety. Saying "Oh, it's fine that you want one thing but you are have no guarantee of getting it" - that's the opposite of the core intention of TS.
– vlaz
23 hours ago
add a comment |
"As far as Typescript goes, this is completely fine." no, it's not. The result of this expression would be undetermined, TypeScript would recognise it as much and should report an error because the return type would beany
as opposed tonumber
. Which is not fine for TypeScript - remember, it's there to ensure the type safety. Saying "Oh, it's fine that you want one thing but you are have no guarantee of getting it" - that's the opposite of the core intention of TS.
– vlaz
23 hours ago
"As far as Typescript goes, this is completely fine." no, it's not. The result of this expression would be undetermined, TypeScript would recognise it as much and should report an error because the return type would be
any
as opposed to number
. Which is not fine for TypeScript - remember, it's there to ensure the type safety. Saying "Oh, it's fine that you want one thing but you are have no guarantee of getting it" - that's the opposite of the core intention of TS.– vlaz
23 hours ago
"As far as Typescript goes, this is completely fine." no, it's not. The result of this expression would be undetermined, TypeScript would recognise it as much and should report an error because the return type would be
any
as opposed to number
. Which is not fine for TypeScript - remember, it's there to ensure the type safety. Saying "Oh, it's fine that you want one thing but you are have no guarantee of getting it" - that's the opposite of the core intention of TS.– vlaz
23 hours ago
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54254396%2fwhy-does-accessing-a-property-of-indexof-still-compile%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
What did you assign the result of? Because what you wrote is valid you are taking the
someObject
member of theindexOf
method. Well, trying to. The only error would come from TypeScript compilation and only if you try to assign the result to something that doesn't match the expected type.– vlaz
Jan 18 at 12:54
12
Welcome to javascript, where everything is an object!
– Jean-Baptiste Yunès
Jan 18 at 12:54
7
@DeWetvanAs I am actually curious about your problem - this seems like a genuine bug/problem with TypeScript see example here. It seems that if you are trying to assign to a variable of type
number
, the result of.indexOf[someObject]
shouldn't be considered anumber
and thus the compilation would fail. That's the whole idea of TypeScript is - to enforce the types. The answers here focus on JS but ignore this.– vlaz
Jan 18 at 13:43
@vlaz it was in fact a complex object with multiple properties.
– De Wet van As
Jan 18 at 19:50