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

Restore support for static interface properties #5590

Closed
jfirebaugh opened this issue Dec 29, 2017 · 8 comments
Closed

Restore support for static interface properties #5590

jfirebaugh opened this issue Dec 29, 2017 · 8 comments

Comments

@jfirebaugh
Copy link

Support for static properties on interfaces was removed in 0.62.0 because they were "never well supported, and in most cases their types were not actually checked".

Was there also a type theoretical basis for removing them, or was it merely pragmatic, as the changlog suggests? If the latter, I would like to request that they be well supported, and their types actually checked. mapbox-gl-js was relying in several places on them, and when upgrading to 0.62.0, it appears I will not only have to comment out or remove these properties, but also disable type checking with any casts where the properties are used.

@samwgoldman
Copy link
Member

Where are they used in mapbox-gl-js? Happy to take a look and recommend alternatives.

@jfirebaugh
Copy link
Author

Thanks @samwgoldman! The use that looks like it's going to require an any cast is this one. Expression is an interface for an AST node type, parse implementations define recursive-descent parsing for concrete expression types. parse is used here, where Expr is of type Class<Expression>.

@samwgoldman
Copy link
Member

samwgoldman commented Dec 29, 2017

Instead of a single Expression interface with statics and non-statics, what if you exported two interfaces, Expression and ExpressionStatics, and used ExpressionStatics instead of Class<Expression>?

@samwgoldman
Copy link
Member

Going to close this, but let me know if you run into any further issues.

@akalin
Copy link

akalin commented Jan 1, 2018

I have a similar problem: I define a Field interface with static Zero and One members here: https://github.com/akalin/intro-erasure-codes/blob/master/field.js#L15 , and I use it in a Matrix class here: https://github.com/akalin/intro-erasure-codes/blob/234257f63545d59f078738428543337809cb46b4/matrix.js#L60

Splitting Field into Field and FieldStatics doesn't help, since I'd still have to convert a Class<T> into a FieldStatics<T>.

The best thing I can think of is to replace Zero and One with zero-arity functions zero() and one(), which isn't great since I'd have to keep around an instance of T instead of just the constructor function, but I was wondering if you know of other alternatives.

@samwgoldman
Copy link
Member

@akalin Not sure what's best for you, but would another option be to add zero: T, one: T as parameters to the Matrix constructor?

@akalin
Copy link

akalin commented Jan 2, 2018

Yeah, that's another option. Pretty wordy, though. Thanks anyway!

@rhengles
Copy link

Static interface properties are used in Vue.js:

https://github.com/vuejs/vue/blob/dev/flow/component.js#L7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants