Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Extending expressions" feature in TypeScript 1.6 leads to inconsistent compiler behaviour. #4975

Closed
lord-saumagen opened this issue Sep 25, 2015 · 5 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@lord-saumagen
Copy link

"Extending expressions" feature in TypeScript 1.6 leads to inconsistent compiler behaviour.

Dear ladies and gentlemen,

I have a question regarding the compiler behaviour change for the new TypeScript 1.6 feature:
"Expression extending".

[Description at: https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript]
featuredescription

Before V1.6 I wasn't able to drive from the built-in classes and got a compiler error at design time.
The compiler simply didn't let me do it.

[compile-time error]
compilererror

Now I'm able to drive from the built-in classes and I'm very happy about that. But unfortunately that also has the effect that I don't get any warning when I'm going to derive from unsupported classes.
Here is an example where I drive from the "HTMLElement" class.
The compiler let me do that, but afterwards I get a runtime error.

[runtime error]
runtimeerror

The powerful error handling system of the TypeScript compiler is one of the features I like most. Before, I was able to make any stupid mistake in JavaScript and could only hope that such errors would reveal themselves at runtime. Hopefully before my code went into production. With the 1.6 release you relaxed the error handling system of the compiler. An error which was a compile-time error before became a runtime error with this release.

My question is, did you do that by purpose or was it an unpredicted side effect?

Before you ask, I'm aware that the "HTMLElement" class is not a built-in class but a WebAPI class. But before 1.6 I didn't have to worry about that in any way. WebAPI or built-in, the classes were all handled the same way.

I would appreciate if you could clarify that for me.

Kind regards, Lord Saumagen.

@weswigham
Copy link
Member

You should be able to subclass HTMLElement, according to the information available on custom elements. If you cannot, it's potentially an issue in the browser you're targeting which you'll need to work around, such as here (which describes your issue precisely).

@mhegazy
Copy link
Contributor

mhegazy commented Sep 25, 2015

also see #1168 (comment) for related discussion.

@mhegazy mhegazy added the Question An issue which isn't directly actionable in code label Sep 25, 2015
@mhegazy mhegazy closed this as completed Sep 25, 2015
@saschanaz
Copy link
Contributor

Out of curiosity, was it working in runtime on TS 1.5?

@lord-saumagen
Copy link
Author

@saschanaz

Dear Sacha Naz,

I'm sorry, but I can't answer that question. I made a jump from TS 1.3 to TS 1.6. I never used the 1.5 compiler version.

Kind regards, Lord Saumagen

@lord-saumagen
Copy link
Author

@weswigham, @mhegazy

Dear eswigham and mhegazy

thank you both for your suggestions. You saved my day.

Kind regards, Lord Saumagen.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

4 participants