E16N: move extension manager from VM to Runtime #2243
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Would love to chat about this — I think a walk through would be the easiest way, so let's do that sometime soon. |
rschamp
approved these changes
Jul 30, 2019
| @@ -169,6 +169,14 @@ class VirtualMachine extends EventEmitter { | |||
| this.variableListener = this.variableListener.bind(this); | |||
| } | |||
|
|
|||
| /** | |||
| * @returns {ExtensionManager} the extension manager, now owned by the runtime. | |||
| * @deprecated Please access the extension manager through the runtime instead. | |||
There was a problem hiding this comment.
Could also log this warning if it's accessed this way so we can find places we've missed in our own code. Although I wonder if we care/want that? Seems like accessing via VM from the outside could be seen as the right thing to do — the VM is the external interface. But internally we refer to the actual location?
kchadha
reviewed
Aug 1, 2019
| @@ -129,7 +128,7 @@ class VirtualMachine extends EventEmitter { | |||
| this.emit(Runtime.BLOCK_UPDATE, blockId, blockInfo); | |||
| }); | |||
| this.runtime.on(Runtime.TOOLBOX_EXTENSIONS_NEED_UPDATE, () => { | |||
| this.extensionManager.refreshBlocks(); | |||
| this.runtime.extensionManager.refreshBlocks(); | |||
There was a problem hiding this comment.
I think there's no longer to bubble this event all the way up to the VM anymore. We could either remove the event all together or just have the runtime listen and handle its own event since it also owns the extensionManager.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed Changes
Move the Extension Manager class from being owned by the VM to being owned by the Runtime.
Reason for Changes
For one thing, the extension manager has more to do with the runtime than the VM, so it seems to make sense that it would be more closely associated with the runtime. I could even see the argument that the extension manager's functionality should be merged into the runtime.
The real reason, though, is that I'm in a situation where it would be really handy to make calls into the extension manager from a place which has access to the runtime but not to the VM. Specifically, in
src/engine/blocks.js. I think it's right thatblocks.jsdoesn't have access to the VM, but it needs access to information that comes from the extension manager, so... here's my proposed change :)Interestingly, the GUI doesn't care about the extension manager moving. All of the interaction between the GUI and the extension manager happens through events, so as long as those events get registered correctly everyone's happy. It's a bit unfortunate that the VM registers the runtime for events externally, but that's a separate problem.EDIT: I was wrong... there are a couple of lines in
scratch-gui/containers/extension-library.jsxthat would need to change but it'd just be a matter of replacingvm.extensionManagerwithvm.runtime.extensionManager.Test Coverage
This change is covered by existing tests, a few of which needed minor changes to access the extension manager in its new home.