-
Notifications
You must be signed in to change notification settings - Fork 13
Investigate simplifying the TS Rug Parameter model #229
Comments
Proposal 1: Property Injection class SimpleEditor implements ProjectEditor{
name: string = "Simple"
description: string = "My simple editor"
@parameter({description: "num", pattern: "\\d+"})
num: number = 10
edit(project: Project){
this.num == 10;
project.addFile("src/from/typescript", "Anders Hjelsberg is God")
}
} Pros:
Cons:
|
Proposal 2: Mapped types and a Parameters interface: class MyParams implements Parameters {
//name, type and default value from from definition
@parameter({description: "Content", pattern: "$ContentPattern"})
content: number = 10;
}
class SimpleEditor implements ProjectEditor<MyParams> {
name: string = "Simple"
description: string = "My simple editor"
params: MyParams = new MyParams()
edit(project: Project, p: RugParams<MyParams>) {
p.content == 2;
project.addFile("src/from/typescript", "Anders Hjelsberg is God")
}
} Pros:
Cons:
|
Proposal 3: Status Quo: Pros:
Cons:
|
Or any others? |
@kipz, I like option 1 but worry about thread-safety. Right now |
@cdupuis isn't caching instances dangerous anyway? They could mutate fields on the editor object at any time. |
I like option 1 except for inheritance as a grouping mechanism. but it's fine. |
The API in Rug and I think if we can't guarantee thread-safety, Rug needs to handle that internal by creating new instances on invocation. |
@cd - I think we can do that, and as @jessitron - we should already be doing that anyway. So rather than exporting an instance of the class, we'll just export the class itself, and create a new one for each call. |
sounds good. yeah, that is indeed safer. |
I'd be happy with 1 or 3. |
Proposal 1: property injection wins Though we should be doing this already, we'll need to ensure that:
|
Decorator TS parameters. New js rug instance per invocation #229
Currently all parameters to a TS rug are declared in an array on the Rug. While this works, and destructing can be used in simple cases, when there are many parameters, it quickly gets ugly when consuming the parameters in the function implementation (edit/review/populate etc).
At the very least, the duplication of parameter names should be removed if possible.
The text was updated successfully, but these errors were encountered: