More RemoteHostClient refactoring#43928
Conversation
| /// Lock for the <see cref="_globalNotificationsTask"/> task chain. Each time we hear | ||
| /// about a global operation starting or stopping (i.e. a build) we will '.ContinueWith' | ||
| /// this task chain with a new notification to the OOP side. This way all the messages | ||
| /// are properly serialized and appera in the right order (i.e. we don't hear about a |
There was a problem hiding this comment.
| /// are properly serialized and appera in the right order (i.e. we don't hear about a | |
| /// are properly serialized and appear in the right order (i.e. we don't hear about a | |
| ``` #Resolved |
| /// stop prior to hearing about the relevant start). | ||
| /// </summary> | ||
| private readonly object _globalNotificationsGate = new object(); | ||
| private Task<GlobalNotificationState> _globalNotificationsTask = Task.FromResult(GlobalNotificationState.NotStarted); |
| if (previousTask.Result != GlobalNotificationState.NotStarted) | ||
| { | ||
| return previousTask.Result; | ||
| } |
There was a problem hiding this comment.
should we assert we're not in the 'Finished' state? can we oc what hte Finished state actually is? #Resolved
There was a problem hiding this comment.
n/m. i read this wrong. #Resolved
|
|
||
| /// <summary> | ||
| /// Lock for the <see cref="_globalNotificationsTask"/> task chain. Each time we hear | ||
| /// about a global operation starting or stopping (i.e. a build) we will '.ContinueWith' |
There was a problem hiding this comment.
This code moved from RemoteHostClient. #Resolved
| { | ||
| NotStarted, | ||
| Started, | ||
| Finished |
There was a problem hiding this comment.
i don't see the Finished value ever used. did i miss it?
#Resolved
There was a problem hiding this comment.
I see, it used to be used. I deleted that code :) Will remove this value.
In reply to: 419027233 [](ancestors = 419027233)
|
|
||
| await _endPoint.InvokeAsync( | ||
| nameof(IRemoteHostService.OnGlobalOperationStarted), | ||
| new object[] { "" }, |
There was a problem hiding this comment.
previously we sent empty string, now we send nothing, is that ok? #Resolved
There was a problem hiding this comment.
Yes, there probably used to be some bug in JSON-RPC. I tested this works.
In reply to: 419027340 [](ancestors = 419027340)
| continuation, _cancellationToken, TaskContinuationOptions.None, TaskScheduler.Default); | ||
| } | ||
|
|
||
| async Task<GlobalNotificationState> continuation(Task<GlobalNotificationState> previousTask) |
There was a problem hiding this comment.
| async Task<GlobalNotificationState> continuation(Task<GlobalNotificationState> previousTask) | |
| return; | |
| async Task<GlobalNotificationState> continuation(Task<GlobalNotificationState> previousTask) | |
| ``` #Resolved |
There was a problem hiding this comment.
IDE style is to have explicit exit above the local functions that way the read knows tehre's no 'outer' code that executes beyond that point. (same for the above method plx). #Resolved
There was a problem hiding this comment.
I just moved the method. But I can add it. It looks odd though, maybe it would be better if the local function was above .
In reply to: 419027397 [](ancestors = 419027397)
There was a problem hiding this comment.
I just moved the method. But I can add it. It looks odd though, maybe it would be better if the local function was above .
In general, IDE style is:
- local functions at the end. This enables someone to immediately see the main-thread code of the function without having to go through the helpers first.
- an explicit exit prior to the local functions. This ensures that you can immediately see there's no additional code that runs. And the local functions don't intersperse hte actual method code.
- local functions are PascalCased at the IDE layer. We tend think of them as 'scoped sibling helper methods' versus 'a local variable of a function type'.
- Optionally: sometimes we put
// local functionsabove hte local functions. This has helped clarify things in PRs where sometimes it looks like a sibling method, and it gets confusing (esp. with captures) when you can't immediatley tell that it's a local-function. However, this is rarer now now that most people are comfortable with them.
There was a problem hiding this comment.
Seems like it's better then to make it a method because all of the above is just adding extra stuff to make it clearer.
There was a problem hiding this comment.
tbh, that's my general preference. but i get the desire to occasionally have a helper method that is just scoped narrowly. in practice though, if your class is well contained, just having these be helper methods is 100% fine (And how we survived for decades) :)
There was a problem hiding this comment.
Especially the need to add a comment means the style is bad, imo.
No description provided.