Return value of extend.myNamespace intentional? #1
Conversation
This file contains hidden or 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
|
I didn't give a second thought to the return value of myNamespace since it's really just adds an extend method and (I believe?) throws things into a noConflict mode. I'm not sure if the semantic difference of the above createNamespace is really worth it, but I don't think there's any harm in returning the extended object, that's for sure. |
|
Utilizing the existing shared examples to test a variable that is *created* during spec evaluation is impossible without lazy evaluation. (Since the shared examples function accepts the variable in question and essentially writes new examples with the variable in question already in scope.) One way of getting around this is to hang all the shared-examples-arguments off of a context object. This context object is kept in scope via a closure in the example group. This allows any necessary properties to be set on the context object during the course of spec evaluation and they will be accessible in both the beforeEach function and the shared examples because the context object is in scope (via the closure). However, the 'this' object (in Jasmine, the 'Spec' object) is shared among all executing examples. Instead of creating a dummy context object as a carrier, we can just hang any necessary arguments off of the Spec object. And since this is in CoffeeScript, that's just a matter of prefixing the shared variables with '@'. Now shared examples are capable of testing variables that aren't initialized (or modified) until spec execution; in other words, lazily evaluated.
|
Finally figured out a way to get the shared examples to test an extender that wasn't set until the spec runs by using the Spec object. This is ready for review, finally. |
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.
Is there a use-case for returning the
extendfunction itself fromextend.myNamespace? Or was the return value chosen for lack of an alternative?I ask, because of the use-case for returning the extended namespace instead:
Perhaps a new method is in order?