Added support for :ns key in nrepl message to cause eval to be within the namespace #386
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.
This is to support nrepl's eval which states that:
Documented here:
https://github.com/nrepl/nrepl/blob/master/doc/modules/ROOT/pages/ops.adoc#eval
Some additional notes:
*ns*
value, I don't believe it's supposed to. If it is supposed to change the current*ns*
value, then line 212, can be deleted.Otherwise the code below will need to be inserted somewhere to create this effect:
Additionally I've written some statements that I believe should be true =)... Sorry if it's not 100% bit tired at this point ;)...
Things that should work!
Load in this file:
Then eval the below within the comment block in that same namespace!
Having evaled this:
Then this:
should give:
and evaling this:
should not give:
But instead give:
(in-ns 'some.namespace)
should change the namespace to some.namespace.This must work, evaling the below:
should produce in the REPL:
This currently doesn't work:
The
*ns*
should have changed togame.fishing
, but stays asgame.core
as that was the namespace it was called from. Directly entering it into the REPL will change the namespace.(I'm not 100% certain this is correct behaviour)
Finally, this is all a bit rough and ready, I just wanted to get a conversation started about what it needs to look like and make sure this implementation doesn't cause issues with other implementations =)...