compose and prototype.constructor about compose HOT 3 CLOSED

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.

from compose.

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.

from compose.

Agreed that we should exclude constructor from copyProperties.

from compose.