Return value of extend.myNamespace intentional?

[jasonkarns]

Is there a use-case for returning the extend function itself from extend.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:

window.myApp = extend.myNamespace({});

Perhaps a new method is in order?

window.myApp = extend.createNamespace();

[searls]

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.

[jasonkarns]

• [x] return the namespace, not the #extend method itself
• [x] create the namespace if given undefined
• [x] update the shared examples to test the extender. (shared examples are defined before the result is set by beforeEach)

[jasonkarns]

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.