Ensure workspace is read from WorkspaceContextService #17494

Merged
merged 2 commits into from Dec 21, 2016

Projects

None yet

5 participants

@rothfels
Contributor

In most of the codebase (examples linked below), the services, parts, etc which depend on workspace context declare that through the dependency injection system, and always read workspace from the WorkspaceContextService (versus some cached instance state). This change replaces hard wires with getter method calls on the injected WorkspaceContextService, and prefers always using these method calls to read workspace. The primary motivation for the change is consistency.

Examples from past commits of the appropriate pattern:

@msftclas

Hi @rothfels, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

@jrieken jrieken was assigned by kieferrm Dec 19, 2016
@msftgits

Hi, I am closing and re-opening this PR to bump the CLA bot. Sorry for the inconvenience!

@msftgits msftgits closed this Dec 19, 2016
@msftgits msftgits reopened this Dec 19, 2016
@msftclas

Hi @rothfels, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

@msftgits msftgits removed the cla-required label Dec 19, 2016
@rothfels rothfels Ensure workspace is read from WorkspaceContextService
25dcdbb
@jrieken jrieken assigned bpasero and unassigned jrieken Dec 20, 2016
@jrieken
Member
jrieken commented Dec 20, 2016

The primary motivation for the change is consistency.

Not convinced that justified such a change.

@bpasero
Member
bpasero commented Dec 20, 2016

Me neither, I think it is fine to pass around workspace object instead of using the context service. Though in the future we might have to revisit this when we support multiple workspaces in one window.

@rothfels
Contributor

Not convinced that justified such a change.

Fair, though the secondary motivation is what @bpasero described. I figured this might not be on the roadmap so a consistency argument would make more sense. But for context, I'm running a patched version of vscode which loads a workbench in the user's web browser, similar to https://github.com/spiffcode/ghedit. We provide a "go-to-definition" feature which can navigate the user to a different workspace (e.g. for external dependencies). For the in-browser use case, we are forced to work with one window. Centralizing access to workspace state allows us in our patch to mutate that state exactly once.

I can see this change being unnecessary if you don't intend to support multiple workspaces in one window.

@bpasero bpasero Merge remote-tracking branch 'upstream/master' into workspace-context…
…-hygiene
9eef84b
@bpasero
Member
bpasero commented Dec 21, 2016

LGTM, thanks.

@bpasero bpasero merged commit 68a4cb8 into Microsoft:master Dec 21, 2016

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@bpasero bpasero added this to the January 2017 milestone Dec 21, 2016
@rothfels rothfels deleted the rothfels:workspace-context-hygiene branch Feb 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment