Update ex.BoundingBox to have an additional option based constructor

[eonarheim]

Context

Currently, ex.BoundingBox has a 4 arg parameter list constructor which technically violates the styleguide

Proposal

Create an option back constructor for ex.BoundingBox and preserve the old constructor for backwards compatibility.

export interface BoundingBoxOptions {
   left: number;
   right: number;
   top: number;
   bottom: number;
}

export class BoundingBox {
  ...
  constructor(leftOrOptions: number | BoundingBoxOptions = 0, top: number = 0, right: number = 0, bottom: number = 0) {
       if (leftOrOptions && typeof leftOrOptions === 'object') {
            // initialize properties from leftOrOptions
       } else {
           // initialize from parameter list
       }
  }
  ...
}

const bb = new ex.BoundingBox({
  left: -5,
  right: 5,
  top: 5,
  bottom: -5
});

Acceptance Criteria

• Existing tests pass
• New test written for new constructor
• Changelog entry added under Added section

[JeTmAn1981]

Is it ok for me to make this change?

I don't have a ton of TS experience, but doing a bit of research it's really too bad it can't allow multiple constructor implementations, that's definitely the way I would go in another language to avoid the awkward use of the union typed leftOrOptions.

[eonarheim]

@JeTmAn1981 all yours!

[JeTmAn1981]

I've written the new constructor. Regarding tests, the bounding box spec is prefacing all the tests with a call to the old-style constructor:

describe('A Bounding Box', () => {
// left, top, right, bottom
let bb: ex.BoundingBox;
beforeEach(() => {
bb = new ex.BoundingBox(0, 0, 10, 10);
});

Would you like all the subsequent tests to be run for both construction styles (options parameter vs. individually specified coordinate parameters)? If so, is there a way of referencing the existing tests without having to create a new spec file with that code copied over? The only thing that would really need to change is how the constructor is called.

[JeTmAn1981]

Another couple of questions:

1. I need to test the constructor function on its own. When I run the test suite I get a million errors because something is obviously not working right in the constructor, and that creates a bunch of other failing tests. Buried in all the various errors I'm not seeing anything clues me in to the actual problem; what's wrong with the new constructor. Is there a way to have Karma run just a single test file for that constructor?

2. Should the constructor tests be included in the main BoundingBox test spec file?

[JeTmAn1981]

Ok, I went ahead and created a pull request for what I came up with on this. Let me know how it looks!

[JeTmAn1981]

Huzzah! So nice to find something small to make a contribution with that gets accepted quickly :)