The check is done at use site any ways regardless if you have an implements clause or not. Sign up for a free GitHub account to open an issue and contact its maintainers and the community. @andy-hanson Thanks for taking the time to correct me. Static checking can only go so far here. However, since you brought in discussion different programming paradigms (should we use OOP or functional? 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. Having siad that, this is rather a style issue. 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? https://github.com/Deviad/virtual-life/blob/master/service/user.ts 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. The class does not have to implement the interface. Interweaving the two doesn't feel right from a design point to me. this was implemented in Java 8 in the last version, so I think I'm not talking nonsense. The reason it compiles successfully is that interface A extends JsonSerializable declares the implementation to be valid without actually checking it. 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. Sign in 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[]. We dont like (each) specific syntax weve seen so far. of all the candy and shortcuts that C# could use, I'm flummoxed that they chose to implement statics in interfaces. These are the files where you can see how the whole thing is handled. I guess, you may open your mind as well and try different styles of programming. So we cannot type check static factory methods in classes that implement the same interface? I want to ensure not to having misspelled make - basically proper static checking. Your declaration seems should work, but it's too verbose for the case. I was just trying to illustrate that it can be expressed. 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. : @mhegazy that is a relatively good solution. @rmblstrp that doesn't require this feature. . :). See also #17545 (comment). Typescript has a wonderful IOC container named InversifyJS. @mhegazy thank you for the discussion/perspective. Thanks for the article! What is the status of this? Weirder still this syntax would enable this behavior. Yes obviously it works but the entire point of type checking is to.. check types. For me it's a deeply saddening and disappointing thing. @andy-ms was indicating to @tyteen4a03 how to get a snippet of code working, because it was wrong, not to forgo type checking. Open your mind. We are slowly discovering what has long been known in the C++ world: interfaces are just classes without any data members. It just took a little bit of time getting familiar with the environment and available packages. static side of the the class), and 2. the instance side (what comes out when calling new). @grantila In my defense, that is debatable. https://github.com/Deviad/virtual-life/blob/master/utils/sqldb/client.ts https://github.com/Deviad/virtual-life/blob/master/bootstrap.ts. By clicking Sign up for GitHub, you agree to our terms of service and You don't need both and it would actually be rather redundant. Already on GitHub? Dependency Injection and IOC containers have been made popular thanks to frameworks like Symfony and Spring. thanks for the example! Add support Interfaces to define static methods, /*static implements JsonSerializableStatic*/, /* this statement implements both normal interface & static interface */. 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). Probably related (since it deals with typing static methods): #5863. There might be some programmers who would go down this route. since 2002. Why do you keep closing unresolved issues in the repo? You may find programming with functions, plain objects and (and to some degree) prototypes pleasurable and even better. No errors

I want to ensure not to having misspelled make - basically proper static checking. SPOILER: no one is better, it depends on the problem you want to solve. There are two types involved, 1. constructor function (e.g. At the time of my post I had just started using Typescript/Node after having been PHP/C# previously. But there's no reason we can't use an interface to describe the shape of the class itself, since classes are objects too. public toJson(): string; 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. Hello, I don't wanna be out of topic or out of the scope of this conversation. 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. 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. To me, interfaces are abstractions and I would have done this using a static or abstract class. This functionality should be overridable and interchangeable (that's why interface methods are virtual). Do you think typescript should allow static methods in Interfaces? . Failing to meet the signature of either toJson or fromJson results in a compile error. Indeed, but mine is not a workaround, it is a justification for your usecase. If you need a parser that scans a website maybe functional can be better to use function generators that return partial results, etc. public static fromJson(obj: any); @andy-ms Yes obviously it works but the entire point of type checking is to.. check types. The world neither starts nor ends with OOP. You signed in with another tab or window. Had the C# designers realized this, the language would be much simpler. 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. Which btw, is a hack. And I just tried abstract classes, but it seems not support static with abstract. The last two decades have mostly just been them trying to detox the language imo. We would have features like default method implementations, static interface members etc. to your account, Expected behavior: you just define the interface, and structural type checks will cache any issues at usage site, e.g. 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. But actually makes me to implement: There is no technical reason for not allowing to define static methods on interfaces. Which do you see more clearly? @Serginho 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. Plus the .NET collections mess caused by broken "interfaces" design would never need to have happened. [Question] How come save works and find returns undefined? Well occasionally send you account related emails. https://github.com/Deviad/virtual-life/blob/master/models/generic.ts In many languages like PHP and Java, static factories have been like deprecated in favor of Dependency Injection. I think you may find this interesting: @aluanhaddad I find your code a workaround of something which is obvious. 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. https://github.com/Deviad/virtual-life/blob/master/models/user.ts Mixing these two in one type is not correct. (Unfortunately, the error is at const _ rather than at the method.). Your declaration: is irrelevant as it basically re-declares the interface of the JSON object. 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. @Deviad @aluanhaddad Since my post I have been using InversifyJS and it has been absolutely great and definitely a much better way to go. } In fact, since you are using a decorator, you can actually is its type to verify that the annotated classes provides required static methods. If you deal with users, classrooms, teachers OOP will be better to model your problem using objects. @rmblstrp Can you show how you would use the proposed feature in your example? The real issue cannot be fixed by the Object.defineProperty() hack unfortunately. As @gcnew said, an interface describes the shape of an individual object, not its class. @tyteen4a03 Remove IObject from that example, and it will compile. @Serginho I don't think it's a particularly good fit for TypeScript. Thank you for providing that! The text was updated successfully, but these errors were encountered: What do you wan to achieve with this? 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. The big difference is that in this case you treat the class as an object, which continues to be logically consistent. For me, it is still a cognitive burden to declare the type of y on the right side of the assignment. Have a question about this project? 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. 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. If you aren't using abstract classes, then you already have the power. I have to agree with you. This is a pattern I use frequently in Swift (using protocols) and I think it would be really nice in TypeScript. I think this would be pretty cool! The currently prevailing patterns count on ducktyping/shape programming, not on rigid classes. I don't want to write a new factory class just for this. As previously mentioned in this issue, unless you have further requirements not mentioned there, this is easily solvable by treating classes as objects. 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. 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. args: any[]): self in your interface, it would have to be checked in runtime for existence before a call. 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 Such a style is much more in line with what JavaScript was initially designed for. Preferably as something verifiable? Actual behavior: Personally, my recommendation is to not use type annotations explicitly unless you have to; let the types flow through he system. 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. @aluanhaddad Come on! Pseudo-OOP features like interfaces, overemphasis of classes, inline access modifiers -- C# got all these downgrades of programming language design from Java. You are loosing the concept of Interface. What that would mean is that (new ((new X()).constructor)).fromJson({}) would have to work. Unsupported. I fixed the error in my example. 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. @Serginho I am not arguing that the situation is ideal. @Enet4, Im a newcomer, but that wasnt clear at all. Statics are a parallel concept to dynamic behaviour/virtual methods. We have already linked to #14600 in this thread and that is the issue to follow for the feature request. 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. I have seen code bases, however, where the style guide is the opposite, where everything has an explicit type annotation. Reading this and other related issues, it sounds like it mostly the following issues: A. Its hard 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. If you would like to continue this discussion, let's consider doing so elsewhere to reduce noise. 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. Why doesn't TypeScript provide a way to implement an interface on the static side? Having static deserialization and instance serialization implemented on a class by class basis and thereby encapsulated and typesafe. 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. C. A small minority dont believe it should be doable at all, and would rather delete the current weird way to do it. 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. And one keyword less. @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. This would save us a lot of time over keeping us in limbo. 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. My use case for allowing static methods to use the class generic parameter is for mixin classes. Interfaces should define the functionality an object provides. 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 want to talk specifically about static factories which are used usually to create a connection to a db or provide some kind of service. privacy statement. class A implements JsonSerializable should make me implementing both methods. Since It would be true that if the. B. Java added this functionality in the last version. @Enet4 that's a working solution, thanks. I imagine abstract classes are what you're looking for. @rozzzly In this example, abstract class is not valid. @grantila I have answered your question. As @aluanhaddad already wrote, TypeScript actually already has a mechanism to express what you desire. So, who knows? can you elaborate on the scenario? That absolutely does not require static interface methods in any way. @Enet4 I updated the question, it was overly-simplified. interface JsonSerializable {

• Hoi4 Yugoslavia Limited Self-government
• Northern Virginia Community Foundation
• Hialeah La Ciudad Que Progresa
• Keplr Wallet Extension Firefox
• Best Adjustable Table Legs
• Weimar Republic Gender Roles
• Bandidos Australia Documentary
• Cambodia National Anthem