You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The set of overloads in TokenStreamRewriter.tssoon` is seems over-complicated. I'm wondering if a little refactoring is in order, at least for the TypeScript port.
The optional programName argument at the beginning of insertAfter, insertBefore, replace and delete methods seems unnecessary. Instead, clients using this API could create separate instances of TokenStreamRewriter, each one serving as it's own "program".
The token index are overloaded with both number and Token type seem like they could be replaced with number | Token types, further reducing the number of overloads.
Where the API includes a text argument, is there any reason this shouldn't be typed string
Thus I'd suggest the side-effecting methods be reduced to:
This seems like a pretty complete set of operations, but the class as currently defined seems to support sub-classing it, which exposes substantially more surface area (e.g. the nested operation classes). Was a useful application for sub-classing TokenStreamRewriter discovered in Java?
The text was updated successfully, but these errors were encountered:
Years later, answering my own question. Yes, I'm convinced the overloads are wrong for TypeScript when optional parameters can be used. and TokenStreamRewriter is not the only case of this. I believe this calls for a review of the whole codebase.
The set of overloads in TokenStreamRewriter.tssoon` is seems over-complicated. I'm wondering if a little refactoring is in order, at least for the TypeScript port.
The optional
programName
argument at the beginning ofinsertAfter
,insertBefore
,replace
anddelete
methods seems unnecessary. Instead, clients using this API could create separate instances of TokenStreamRewriter, each one serving as it's own "program".The token index are overloaded with both
number
andToken
type seem like they could be replaced withnumber | Token
types, further reducing the number of overloads.Where the API includes a
text
argument, is there any reason this shouldn't be typedstring
Thus I'd suggest the side-effecting methods be reduced to:
This seems like a pretty complete set of operations, but the class as currently defined seems to support sub-classing it, which exposes substantially more surface area (e.g. the nested operation classes). Was a useful application for sub-classing
TokenStreamRewriter
discovered in Java?The text was updated successfully, but these errors were encountered: