@Enet4, Im a newcomer, but that wasnt clear at all. Would anybody care to reply with a solution to my question here: http://stackoverflow.com/questions/44047874/dynamically-modify-typescript-classes-through-a-generic-function. 
However, I do remember when I was starting to work with C# (over a decade ago) I tried to do exactly this and found out this was not possible. B. It just took a little bit of time getting familiar with the environment and available packages. Sign up for a free GitHub account to open an issue and contact its maintainers and the community. ), I want to talk specifically about static factories which are used usually to create a connection to a db or provide some kind of service. Which btw, is a hack. 
Which do you see more clearly? Already on GitHub? And one keyword less. I am not saying it's a perfect solution (and probably it leaves some scenarios uncovered) but it works also with React, there some examples already you can look at. I imagine abstract classes are what you're looking for. So we cannot type check static factory methods in classes that implement the same interface? . Have a question about this project? I guess, you may open your mind as well and try different styles of programming. https://github.com/Deviad/virtual-life/blob/master/utils/sqldb/client.ts @andy-hanson Thanks for taking the time to correct me. The check is done at use site any ways regardless if you have an implements clause or not. I have to agree with you. What is the status of this? The reason it compiles successfully is that interface A extends JsonSerializable declares the implementation to be valid without actually checking it. This also works, and show error at compile time without any extra function call: I ran into this and I also want to use static interface: Most people forget that there are already static interfaces in the sense that a constructor function/class has two interfaces already, the constructor interface and the instance interface. You may find programming with functions, plain objects and (and to some degree) prototypes pleasurable and even better. And IMO that is more unsafe than the type cast presented in my answer, which was only performed to allow the insertion of a field in an object. solutions like yours, using type casting, is actually not type safe, and if this is the only way to solve the situation of working with the class type as a value, we're losing a lot of the flexibility of a dynamic language. What that would mean is that (new ((new X()).constructor)).fromJson({}) would have to work. The last two decades have mostly just been them trying to detox the language imo. If you would like to continue this discussion, let's consider doing so elsewhere to reduce noise. I think you may find this interesting: @aluanhaddad I find your code a workaround of something which is obvious. There might be some programmers who would go down this route. The big difference is that in this case you treat the class as an object, which continues to be logically consistent.
Probably related (since it deals with typing static methods): #5863. @grantila In my defense, that is debatable. @aluanhaddad: Your example has a mistake: JsonSerializable's constructor member would actually refer to an instance property called constructor, which when invoked with new would return a JsonSerializableStatic. There are still two things that give me discomfort (admittedly neither are show stoppers): We still aren't able to declare that Bar explicitly implements or conforms to Factorizable. @rozzzly In this example, abstract class is not valid. By clicking Sign up for GitHub, you agree to our terms of service and If its actually by design, and those in charge dont want it, they should write a public doc, and cross link it into this and other threads. From my perspective, the approach you propose is not particularly well suited to TypeScript (and JavaScript development) as classes are kind of a hack/second class citizens. I am building an entity framework which uses annotations to define columns, databases, etc and would like to have a static function mixed in to my entity classes which would allow convenient access to the correctly typed repository. This would save us a lot of time over keeping us in limbo. On a side note, I agree JS is slowly shifting towards OOP-esque patterns (at least on the committee level), but that's because of the huge push of people not being comfortable with different programming paradigms and development techniques. Your declaration: is irrelevant as it basically re-declares the interface of the JSON object. This is a long long long thread on how the static side of class is a separate interface to the instance side and implements points to the instance side.
The world neither starts nor ends with OOP. But there's no reason we can't use an interface to describe the shape of the class itself, since classes are objects too. Having siad that, this is rather a style issue. Plus the .NET collections mess caused by broken "interfaces" design would never need to have happened. This is a pattern I use frequently in Swift (using protocols) and I think it would be really nice in TypeScript. So, who knows? Dependency Injection and IOC containers have been made popular thanks to frameworks like Symfony and Spring. public static fromJson(obj: any); Having static deserialization and instance serialization implemented on a class by class basis and thereby encapsulated and typesafe. Interfaces should define the functionality an object provides. For me, it is still a cognitive burden to declare the type of y on the right side of the assignment. args: any[]): self in your interface, it would have to be checked in runtime for existence before a call. But actually makes me to implement: There is no technical reason for not allowing to define static methods on interfaces. @Deviad @aluanhaddad Since my post I have been using InversifyJS and it has been absolutely great and definitely a much better way to go. Mixing these two in one type is not correct. This is a real problem I have, code that I began porting to TypeScript but now have kept as JavaScript, since I currently cannot rewrite such massive amounts of code as would have been necessary otherwise. thanks for the example! We have already linked to #14600 in this thread and that is the issue to follow for the feature request. @Serginho I don't think it's a particularly good fit for TypeScript. https://github.com/Deviad/virtual-life/blob/master/models/generic.ts, https://github.com/Deviad/virtual-life/blob/master/service/user.ts, https://github.com/Deviad/virtual-life/blob/master/models/user.ts, https://github.com/Deviad/virtual-life/blob/master/utils/sqldb/client.ts, https://github.com/Deviad/virtual-life/blob/master/bootstrap.ts, https://www.youtube.com/watch?v=e-5obm1G_FY&t=1487s, In practice, I imagine this really isn't a problem. As @aluanhaddad already wrote, TypeScript actually already has a mechanism to express what you desire. There are two types involved, 1. constructor function (e.g. See also #17545 (comment). You can always degrade type safety far enough to make every use case compile, but that is ignoring the fact that this is a feature request and a not-so-crazy one at that. But if your only concern now is that you are setting the right property, then casting to a maker type and setting the property from there seems to address that. Indeed, but mine is not a workaround, it is a justification for your usecase. this was implemented in Java 8 in the last version, so I think I'm not talking nonsense. No errors Java added this functionality in the last version. In that sense, the resulting class type C & Maker should remain compatible with everything else relying on a C. I also tried picturing where static methods in interfaces could help you here, but I might be missing something. https://github.com/Deviad/virtual-life/blob/master/models/user.ts
Mocking Current Time with a Simple Time Provider, IReaderFactory.cs file in the StaticMembers project, https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/default-interface-methods-versions#provide-parameterization, C# 8 Interfaces: Public, Private, and Protected Members. public toJson(): string;
Statics are a parallel concept to dynamic behaviour/virtual methods.
@andy-ms Yes obviously it works but the entire point of type checking is to.. check types. Hello, I don't wanna be out of topic or out of the scope of this conversation. The class does not have to implement the interface. Your use case is distinct from those presented in this issue, in that your class type may (or not) provide a method depending on runtime conditions. class A implements JsonSerializable should make me implementing both methods. Sign in For me it's a deeply saddening and disappointing thing. https://github.com/Deviad/virtual-life/blob/master/bootstrap.ts. At the time of my post I had just started using Typescript/Node after having been PHP/C# previously. since 2002. This functionality should be overridable and interchangeable (that's why interface methods are virtual). Yes obviously it works but the entire point of type checking is to.. check types. We would have features like default method implementations, static interface members etc. Open your mind. Also, I suggest you to look at this video about functional programming that covers this aspect about which one is better: https://www.youtube.com/watch?v=e-5obm1G_FY&t=1487s Static checking can only go so far here. However, since you brought in discussion different programming paradigms (should we use OOP or functional? of all the candy and shortcuts that C# could use, I'm flummoxed that they chose to implement statics in interfaces. interface JsonSerializable { I don't want to write a new factory class just for this. In many languages like PHP and Java, static factories have been like deprecated in favor of Dependency Injection. The real issue cannot be fixed by the Object.defineProperty() hack unfortunately. I think that whole issue would be solved by being able to specify static members on interfaces, and if this issue is closed because it's not needed, I would very much like to see how to solve it instead. : @mhegazy that is a relatively good solution. I think this issue (13462) should be looked at again, as solutions like yours, using type casting, is actually not type safe, and if this is the only way to solve the situation of working with the class type as a value, we're losing a lot of the flexibility of a dynamic language. In fact, since you are using a decorator, you can actually is its type to verify that the annotated classes provides required static methods. Since It would be true that if the. Had the C# designers realized this, the language would be much simpler. Typescript has a wonderful IOC container named InversifyJS. We are slowly discovering what has long been known in the C++ world: interfaces are just classes without any data members. Thanks for the article! @Enet4 I updated the question, it was overly-simplified. The text was updated successfully, but these errors were encountered: What do you wan to achieve with this? You don't need both and it would actually be rather redundant. @Enet4 that's a working solution, thanks.
Suggestion: Add abstract static methods in classes and static methods in interfaces, http://stackoverflow.com/questions/44047874/dynamically-modify-typescript-classes-through-a-generic-function. Though not being a language designer or compiler implementor I'm not sure if it fits the intended direction of TypeScript or is realistic to be implemented. The currently prevailing patterns count on ducktyping/shape programming, not on rigid classes. SPOILER: no one is better, it depends on the problem you want to solve. C. A small minority dont believe it should be doable at all, and would rather delete the current weird way to do it. privacy statement. For example, this compiles without error: @Serginho Not a Java user, but it doesn't look like the language allows you to define an interface for the static side of a class (meaning classes implementing the interface would have to implement a static method to conform). @andy-ms was indicating to @tyteen4a03 how to get a snippet of code working, because it was wrong, not to forgo type checking. I want to ensure not to having misspelled make - basically proper static checking.
} My use case for allowing static methods to use the class generic parameter is for mixin classes. If you deal with users, classrooms, teachers OOP will be better to model your problem using objects. Preferably as something verifiable? We dont like (each) specific syntax weve seen so far. @Serginho I am not arguing that the situation is ideal. @rmblstrp Can you show how you would use the proposed feature in your example? Weirder still this syntax would enable this behavior. @Serginho Java allows you to define a static method with a body in an interface, the TypeScript equivalent of which would be: What if you were trying to make a generic factory? To me, interfaces are abstractions and I would have done this using a static or abstract class. Your declaration seems should work, but it's too verbose for the case. Thank you for providing that! Pseudo-OOP features like interfaces, overemphasis of classes, inline access modifiers -- C# got all these downgrades of programming language design from Java. Do you think typescript should allow static methods in Interfaces? Personally, my recommendation is to not use type annotations explicitly unless you have to; let the types flow through he system. . (Unfortunately, the error is at const _ rather than at the method.). In theory you can have implements and static implements but in practice, as you noted, this is seldom used, and the implements clause really does not add much. As previously mentioned in this issue, unless you have further requirements not mentioned there, this is easily solvable by treating classes as objects. Add support Interfaces to define static methods, /*static implements JsonSerializableStatic*/, /* this statement implements both normal interface & static interface */. I fixed the error in my example. https://github.com/Deviad/virtual-life/blob/master/service/user.ts to your account, Expected behavior: @rmblstrp that doesn't require this feature. You are loosing the concept of Interface. @grantila I have answered your question. Reading this and other related issues, it sounds like it mostly the following issues: A. Its hard If you need a parser that scans a website maybe functional can be better to use function generators that return partial results, etc. Why doesn't TypeScript provide a way to implement an interface on the static side? [Question] How come save works and find returns undefined? :). You signed in with another tab or window. static side of the the class), and 2. the instance side (what comes out when calling new). Well occasionally send you account related emails. Unsupported. Failing to meet the signature of either toJson or fromJson results in a compile error. And I just tried abstract classes, but it seems not support static with abstract.
you just define the interface, and structural type checks will cache any issues at usage site, e.g. As @gcnew said, an interface describes the shape of an individual object, not its class. I was just trying to illustrate that it can be expressed. If you aren't using abstract classes, then you already have the power. @aluanhaddad Come on! I'm not sure about the interface syntax I'm proposing here but I know the "usage" syntax is what I'm trying to achieve. Such a style is much more in line with what JavaScript was initially designed for. I want to ensure not to having misspelled make - basically proper static checking. That absolutely does not require static interface methods in any way. Actual behavior: @tyteen4a03 Remove IObject from that example, and it will compile. https://github.com/Deviad/virtual-life/blob/master/models/generic.ts can you elaborate on the scenario? I think this would be pretty cool! @mhegazy thank you for the discussion/perspective.
Interweaving the two doesn't feel right from a design point to me. The two mean different things, var y = x.bar(Bar) declares a new variable y with the same type as x.bar(Bar); where as var y: Bar[] = x.bar(Bar) declares a new variable y with type Bar[] and verifies that the type of x.bar(Bar) is assignable to Bar[]. I believe this is one of those cases where the issue should be explicitly labelled with "wontfix", as the choice of not having static methods in interfaces is by design. These are the files where you can see how the whole thing is handled. Why do you keep closing unresolved issues in the repo? I have seen code bases, however, where the style guide is the opposite, where everything has an explicit type annotation.
However, I do remember when I was starting to work with C# (over a decade ago) I tried to do exactly this and found out this was not possible. B. It just took a little bit of time getting familiar with the environment and available packages. Sign up for a free GitHub account to open an issue and contact its maintainers and the community. ), I want to talk specifically about static factories which are used usually to create a connection to a db or provide some kind of service. Which btw, is a hack. Which do you see more clearly? Already on GitHub? And one keyword less. I am not saying it's a perfect solution (and probably it leaves some scenarios uncovered) but it works also with React, there some examples already you can look at. I imagine abstract classes are what you're looking for. So we cannot type check static factory methods in classes that implement the same interface? . Have a question about this project? I guess, you may open your mind as well and try different styles of programming. https://github.com/Deviad/virtual-life/blob/master/utils/sqldb/client.ts @andy-hanson Thanks for taking the time to correct me. The check is done at use site any ways regardless if you have an implements clause or not. I have to agree with you. What is the status of this? The reason it compiles successfully is that interface A extends JsonSerializableProbably related (since it deals with typing static methods): #5863. @grantila In my defense, that is debatable. @aluanhaddad: Your example has a mistake: JsonSerializable's constructor member would actually refer to an instance property called constructor, which when invoked with new would return a JsonSerializableStatic. There are still two things that give me discomfort (admittedly neither are show stoppers): We still aren't able to declare that Bar explicitly implements or conforms to Factorizable. @rozzzly In this example, abstract class is not valid. By clicking Sign up for GitHub, you agree to our terms of service and If its actually by design, and those in charge dont want it, they should write a public doc, and cross link it into this and other threads. From my perspective, the approach you propose is not particularly well suited to TypeScript (and JavaScript development) as classes are kind of a hack/second class citizens. I am building an entity framework which uses annotations to define columns, databases, etc and would like to have a static function mixed in to my entity classes which would allow convenient access to the correctly typed repository. This would save us a lot of time over keeping us in limbo. On a side note, I agree JS is slowly shifting towards OOP-esque patterns (at least on the committee level), but that's because of the huge push of people not being comfortable with different programming paradigms and development techniques. Your declaration: is irrelevant as it basically re-declares the interface of the JSON object. This is a long long long thread on how the static side of class is a separate interface to the instance side and implements points to the instance side.
The world neither starts nor ends with OOP. But there's no reason we can't use an interface to describe the shape of the class itself, since classes are objects too. Having siad that, this is rather a style issue. Plus the .NET collections mess caused by broken "interfaces" design would never need to have happened. This is a pattern I use frequently in Swift (using protocols) and I think it would be really nice in TypeScript. So, who knows? Dependency Injection and IOC containers have been made popular thanks to frameworks like Symfony and Spring. public static fromJson(obj: any); Having static deserialization and instance serialization implemented on a class by class basis and thereby encapsulated and typesafe. Interfaces should define the functionality an object provides. For me, it is still a cognitive burden to declare the type of y on the right side of the assignment. args: any[]): self in your interface, it would have to be checked in runtime for existence before a call. But actually makes me to implement: There is no technical reason for not allowing to define static methods on interfaces. @Deviad @aluanhaddad Since my post I have been using InversifyJS and it has been absolutely great and definitely a much better way to go. Mixing these two in one type is not correct. This is a real problem I have, code that I began porting to TypeScript but now have kept as JavaScript, since I currently cannot rewrite such massive amounts of code as would have been necessary otherwise. thanks for the example! We have already linked to #14600 in this thread and that is the issue to follow for the feature request. @Serginho I don't think it's a particularly good fit for TypeScript. https://github.com/Deviad/virtual-life/blob/master/models/generic.ts, https://github.com/Deviad/virtual-life/blob/master/service/user.ts, https://github.com/Deviad/virtual-life/blob/master/models/user.ts, https://github.com/Deviad/virtual-life/blob/master/utils/sqldb/client.ts, https://github.com/Deviad/virtual-life/blob/master/bootstrap.ts, https://www.youtube.com/watch?v=e-5obm1G_FY&t=1487s, In practice, I imagine this really isn't a problem. As @aluanhaddad already wrote, TypeScript actually already has a mechanism to express what you desire. There are two types involved, 1. constructor function (e.g. See also #17545 (comment). You can always degrade type safety far enough to make every use case compile, but that is ignoring the fact that this is a feature request and a not-so-crazy one at that. But if your only concern now is that you are setting the right property, then casting to a maker type and setting the property from there seems to address that. Indeed, but mine is not a workaround, it is a justification for your usecase. this was implemented in Java 8 in the last version, so I think I'm not talking nonsense. No errors Java added this functionality in the last version. In that sense, the resulting class type C & Maker
Mocking Current Time with a Simple Time Provider, IReaderFactory.cs file in the StaticMembers project, https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/default-interface-methods-versions#provide-parameterization, C# 8 Interfaces: Public, Private, and Protected Members. public toJson(): string;
Statics are a parallel concept to dynamic behaviour/virtual methods.
@andy-ms Yes obviously it works but the entire point of type checking is to.. check types. Hello, I don't wanna be out of topic or out of the scope of this conversation. The class does not have to implement the interface. Your use case is distinct from those presented in this issue, in that your class type may (or not) provide a method depending on runtime conditions. class A implements JsonSerializable should make me implementing both methods. Sign in For me it's a deeply saddening and disappointing thing. https://github.com/Deviad/virtual-life/blob/master/bootstrap.ts. At the time of my post I had just started using Typescript/Node after having been PHP/C# previously. since 2002. This functionality should be overridable and interchangeable (that's why interface methods are virtual). Yes obviously it works but the entire point of type checking is to.. check types. We would have features like default method implementations, static interface members etc. Open your mind. Also, I suggest you to look at this video about functional programming that covers this aspect about which one is better: https://www.youtube.com/watch?v=e-5obm1G_FY&t=1487s Static checking can only go so far here. However, since you brought in discussion different programming paradigms (should we use OOP or functional? of all the candy and shortcuts that C# could use, I'm flummoxed that they chose to implement statics in interfaces. interface JsonSerializable { I don't want to write a new factory class just for this. In many languages like PHP and Java, static factories have been like deprecated in favor of Dependency Injection. The real issue cannot be fixed by the Object.defineProperty() hack unfortunately. I think that whole issue would be solved by being able to specify static members on interfaces, and if this issue is closed because it's not needed, I would very much like to see how to solve it instead. : @mhegazy that is a relatively good solution. I think this issue (13462) should be looked at again, as solutions like yours, using type casting, is actually not type safe, and if this is the only way to solve the situation of working with the class type as a value, we're losing a lot of the flexibility of a dynamic language. In fact, since you are using a decorator, you can actually is its type to verify that the annotated classes provides required static methods. Since It would be true that if the. Had the C# designers realized this, the language would be much simpler. Typescript has a wonderful IOC container named InversifyJS. We are slowly discovering what has long been known in the C++ world: interfaces are just classes without any data members. Thanks for the article! @Enet4 I updated the question, it was overly-simplified. The text was updated successfully, but these errors were encountered: What do you wan to achieve with this? You don't need both and it would actually be rather redundant. @Enet4 that's a working solution, thanks.
Suggestion: Add abstract static methods in classes and static methods in interfaces, http://stackoverflow.com/questions/44047874/dynamically-modify-typescript-classes-through-a-generic-function. Though not being a language designer or compiler implementor I'm not sure if it fits the intended direction of TypeScript or is realistic to be implemented. The currently prevailing patterns count on ducktyping/shape programming, not on rigid classes. SPOILER: no one is better, it depends on the problem you want to solve. C. A small minority dont believe it should be doable at all, and would rather delete the current weird way to do it. privacy statement. For example, this compiles without error: @Serginho Not a Java user, but it doesn't look like the language allows you to define an interface for the static side of a class (meaning classes implementing the interface would have to implement a static method to conform). @andy-ms was indicating to @tyteen4a03 how to get a snippet of code working, because it was wrong, not to forgo type checking. I want to ensure not to having misspelled make - basically proper static checking.
} My use case for allowing static methods to use the class generic parameter is for mixin classes. If you deal with users, classrooms, teachers OOP will be better to model your problem using objects. Preferably as something verifiable? We dont like (each) specific syntax weve seen so far. @Serginho I am not arguing that the situation is ideal. @rmblstrp Can you show how you would use the proposed feature in your example? Weirder still this syntax would enable this behavior. @Serginho Java allows you to define a static method with a body in an interface, the TypeScript equivalent of which would be: What if you were trying to make a generic factory? To me, interfaces are abstractions and I would have done this using a static or abstract class. Your declaration seems should work, but it's too verbose for the case. Thank you for providing that! Pseudo-OOP features like interfaces, overemphasis of classes, inline access modifiers -- C# got all these downgrades of programming language design from Java. Do you think typescript should allow static methods in Interfaces? Personally, my recommendation is to not use type annotations explicitly unless you have to; let the types flow through he system. . (Unfortunately, the error is at const _ rather than at the method.). In theory you can have implements and static implements but in practice, as you noted, this is seldom used, and the implements clause really does not add much. As previously mentioned in this issue, unless you have further requirements not mentioned there, this is easily solvable by treating classes as objects. Add support Interfaces to define static methods, /*static implements JsonSerializableStatic
you just define the interface, and structural type checks will cache any issues at usage site, e.g. As @gcnew said, an interface describes the shape of an individual object, not its class. I was just trying to illustrate that it can be expressed. If you aren't using abstract classes, then you already have the power. @aluanhaddad Come on! I'm not sure about the interface syntax I'm proposing here but I know the "usage" syntax is what I'm trying to achieve. Such a style is much more in line with what JavaScript was initially designed for. I want to ensure not to having misspelled make - basically proper static checking. That absolutely does not require static interface methods in any way. Actual behavior: @tyteen4a03 Remove IObject from that example, and it will compile. https://github.com/Deviad/virtual-life/blob/master/models/generic.ts can you elaborate on the scenario? I think this would be pretty cool! @mhegazy thank you for the discussion/perspective.
Interweaving the two doesn't feel right from a design point to me. The two mean different things, var y = x.bar(Bar) declares a new variable y with the same type as x.bar(Bar); where as var y: Bar[] = x.bar(Bar) declares a new variable y with type Bar[] and verifies that the type of x.bar(Bar) is assignable to Bar[]. I believe this is one of those cases where the issue should be explicitly labelled with "wontfix", as the choice of not having static methods in interfaces is by design. These are the files where you can see how the whole thing is handled. Why do you keep closing unresolved issues in the repo? I have seen code bases, however, where the style guide is the opposite, where everything has an explicit type annotation.