compose and prototype.constructor

[kitsonk]

In conversations with other developers, the question was raised "what happens when you mixin in a method named constructor into a compose class"?

Should we guard against methods named constructor being mixed in and throw?

[mwistrand]

Resetting prototype.constructor is standard fare in classical JS inheritance schemes, so throwing an error for any base function passed to compose that happens to do so (e.g., third-party modules installed via Bower) could prove problematic. Since constructor functions of other bases are ignored, it would be nice if these constructors were treated the same. In order to prevent these constructors from overriding factory.prototype.constructor, they could be deliberately excluded from the internal copyProperties method, or factory.prototype.constructor = factory could placed after the call to copyProperties within compose, instead of within cloneFactory.

[maier49]

As far as I can tell, a base having a method called constructor isn't really a problem. If there's a method called constructor on the base, the resulting factory will just create instances that also have a constructor method. I'm not sure why somebody would have a method called constructor but it doesn't seem like it would cause any more problems for compose than it would in the first place.

In the case that the constructor is actually on the base.prototype it seems like @mwistrand 's suggestion would be sufficient to handle this. This would just require adding one or two lines to create and extend, as mixin passes the object through create if it's not a ComposeFactory anyway.

[kitsonk]

Agreed that we should exclude constructor from copyProperties.