-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
TypeScript definition error #635
Comments
Not being able to replace a static method like in this case seems just wrong to me. A There are solutions for this, of course, and it will probably be necessary to implement one of these:
We'll probably end up doing either 2. or 3. but then why exactly are we emitting TypeScript definitions again if we have to break them anyway... 😕 |
Conceptually you are right with omitting the name for a |
Are you ok with adding a new (non-exported) type Then export class Namespace extends ReflectionObject implements NamespaceMixin {
static fromJSON(name: string, json: { [k: string]: any }): Namespace;
}
export class Root ReflectionObject implements NamespaceMixin {
static fromJSON(json: ({ [k: string]: any }|any), root?: Root): Root;
} |
Just to follow up on your first reply: From a fundamental OOP perspective, you are absolutely correct. But what we have here is something that breaks only if a configuration options is present that is not specifically there to guarantee any fundamental laws of OOP - in a language that compiles to JavaScript, where there is absolutely no benefit of making this restriction. Don't get me wrong, I don't know much about the design principles behind TypeScript, I am just saying that having to deal with such an issue doesn't make a lot of sense to me in the first place. On your second reply: Sure, I am open to cool hacks. That'd definitely be preferable over breaking something! Though, I am not sure how to integrate this into the automated JSDoc / .d.ts generation we have in place, yet. |
The design goal of TypeScript is to make programming more strict by introducing type safety (including an OOP system which JavaScript lacks). But i completely understand that not everybody likes these strict programming model. Tested your commit fe4d97b and it solves the problem for every TypeScript developer. So now it's time to wait for the next tag to specify the new version as dependency. |
Now on npm as 6.4.6. Cheers! |
I am seeing this on 6.7.3 version now
|
me too protobufjs@6.8.8 |
Issue
TypeScript reports the following error when using
strictNullChecks
as already reported with #552 but closed without a solution:The definitions are:
Versions
protobuf.js version:
6.4.5
typescript version:
2.1.4
(same withtypescript@2.2.0-dev.20170110
)Reproduction
The text was updated successfully, but these errors were encountered: