“Check for plain object” may be have a problem about co HOT 8 CLOSED

is that really a problem?

from co.

The second "like in browser" will slow down the code as call is slower than a direct function call, plus, the current implementation does not require a function call at all (meaning, it's faster).

You should not yield anything else than a Promise, a GeneratorFunction, a Function or a plain Object anyhow. So, when you say "may have a problem", what kind of problem do you have in mind? Can you give any example of a potential issue with the current implementation? I am all in favor of preventive maintenance, but if it creates bottle necks and does not improve the code in any way...

from co.

return val && 'Object' == val.constructor.name;

This one should fail if someone creates a constructor like this:

var Ctor = function () {}

Because .name will not exist. This can be fixed by changing the expression to var Ctor = function Ctor() {}; however, it is likely that it you'll see the first version instead.

from co.

@wilmoore , no, it will not fail, as co is looking if the yielded object context is a function before it checks if it's an Object, So, no problem here.

from co.

as co is looking if the yielded object context is a function before

OH, cool. Well, that's fine then.

from co.

@juliangruber @yanickrochon if the object is just a plain object, that's ok.

If i want to yield a object through a constructor(eg. function A(a) {this.a=a}, yield new A('aaa')),
i think Object.prototype.toString.call(val) === '[object Object]' is always okey.

ps. Actually, constructor can be modified by you, so i think it is not safe. That's the reason that you use Array.isArray(val) instead of Array == val.constructor.

from co.

"If it ain't broke don't fix it"

Is there a use case where this fails?

from co.

yielding non-plain objects would be pretty weird and likely break in most cases, it's a pretty questionable feature in the first place haha, handy, but questionable

from co.