Develop #61
Develop #61
Conversation
| } | ||
|
|
||
| // QueueFileParse queues the reparse of a file. Reparse is signaled to the caller | ||
| // via a WorkspaceUpdateCallback. | ||
| func (id WorkspaceID) QueueFileParse(fileName string, reader io.Reader, versionId uintptr) *error { | ||
| if reader == nil { |
There was a problem hiding this comment.
Doesn't the Go linter prefer tabs? I've been of the opinion when in Rome...
There was a problem hiding this comment.
I'm ok with switching to spaces so long as we can put the right .editorconfig or whatever is needed to keep the files consistent in the project.
There was a problem hiding this comment.
idk actually. I never changed the default settings of the builtin to Goland.
There was a problem hiding this comment.
In Visual Studio + VS Code we can configure these settings usually with .EditorConfig files. We can probably for Goland too.
There was a problem hiding this comment.
Yea for sure. Actually, I looked a bit closer and Goland is pulling from my IDE settings repository that's configured for other languages and I think it might have gotten messed up. I'll configure it before the next commit.
There was a problem hiding this comment.
No worries, this is a low-key side project. There are no standards :)
| RESOLVEDTYPE TokenType = 4 | ||
| LITERAL TokenType = 5 | ||
| COMMENT TokenType = 6 | ||
| KEYWORD = iota |
There was a problem hiding this comment.
Are these guaranteed ascending?
Note that I hard coded integer values here to ensure they match the C# side if reordered
There was a problem hiding this comment.
Ok, it's definitely worth a comment at least to ensure they don't get messed up.
I'd actually feel a bit more comfortable leaving the int values in place because this is a binary compatibility issue and not just a source code one.
There was a problem hiding this comment.
Yea, I'd agree with that, will change back. Perhaps move their declarations to the token_service with a comment as well?
| "go/token" | ||
| ) | ||
|
|
||
| type tyNode interface { |
There was a problem hiding this comment.
What's the benefit of the interfaces in this particular case given that they're all different? I think they're a helpful addition when they can be used to reduce boiler plate but in this particular case they don't seem to have.
There was a problem hiding this comment.
It's not so much about reducing boiler plate as it is about reducing dependencies on the token components. I.E. in another instance where you have to do something with many tokens but specific to each one, you just have to add that type of action as an interface method.
|
Interfaced out the switch that determined ast.Node type and appended token accordingly. Cleaned up the way Token types were declared as constants. Removed 'getWorkspace' returning a *error.