Allow World constructor to callback without explicit world instance

[jbpros]

This is how the World constructor is now expected to call back:

this.World = function World(callback) {
  callback(this);
}

Calling back without a parameter is currently forbidden, leading to an exception:

this.World = function World(callback) {
  callback(); // error!
}

Cucumber is using the new keyword when calling the World() function. It means it could (and should) use the fresh World instance when no explicit one is passed to the callback.

this.World = function World(callback) {
  callback(); // would be the same as: callback(this)
}

[keithamus]

This has broken passing back a custom object as the world. For example, I can no longer do this:

//world.js
module.exports = function (callback) {
    var myworld = {
        doStuff: function (){}
    }
    callback(myworld);
}

Instead I now have to do this:

//world.js
module.exports = function (callback) {
    var myworld = {
        doStuff: function (){}
    }
    callback();
    return myworld;
}

This should be pointed out in documentation.

[jbpros]

Damn, I kind of stupidly hoped nobody was doing that just yet.

I had a second thought on the callback parameter thingy and felt it was overcomplicating the API. However, your example is enough to convince me I was wrong. Cucumber.js is actually using a lot of those "inner-constructors" in its own API.

I'll add it back soon.

[keithamus]

As an aside you should look into SemVer, which provides nice guidelines on how to assign version numbers to your releases.

In SemVer, it describes how patch version (x.y.Z) must only fix bugs, without introducing backwards incompatible changes to the code. This allows the rest of us to hang off of the x.y.* branch, automatically updating and all the while fixing bugs, without having to change our code.

[keithamus]

Nevertheless, thanks for your hard work on this. Using it is great fun and I appreciate what you've done.

[jbpros]

You are right, it's the second time I receive complaints about the version numbers. Up until now, I've considered minor numbers to be milestones and patch numbers to be steps within them. There were no more granular version numbers to announce fixes.

I'll stop linking milestones to minor versions and consider patch numbers to be fixes only. Because of the current scheme, we've been stuck on 0.2 for months and it does not make sense anymore.

Thank you for your feedback and encouragement.

[jbpros]

@keithamus I was reading the SemVer spec and the fifth rule states the following:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

We're still in this initial development phase and I think it makes sense to use minor versions to refer to "initial development milestones".

Milestones 0.3 and 0.4 will have to be completed before we can consider releasing 1.0.

As soon as we hit 1.0, the versioning will be strict and patch versions will contain backward-compatible changes only.

[jbpros]

@keithamus 0.2.12 was released. You can pass a world object to the constructor callback again.

[keithamus]

Great to hear. Will give it a try tomorrow. Thanks for the quick work!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.