Mithril.js: Bug & possible size improvement

[userpixel]

hyperscript.js#L51:

if (arguments[1] == null || typeof arguments[1] === "object" && arguments[1].tag === undefined && !Array.isArray(arguments[1])) {

So if arguments[1] is null then the part after && will be executed but arguments[1].tag will throw an TypeError exception.
I suspect it was meant to be arguments[1] !== null but if this is correct we can totally remove arguments[1] == null because typeof arguments[1] === "object" will be true weather it is null or an actual object.

[pygy]

Because of operator precedence rules, a || b && c really means a || (b && c).

typeof(null) is "object" in some circumstances (is it sloppy mode or old IE versions? I don't remember exactly). Maybe we don't need this check anymore...

[isiahmeadows]

typeof null === "object" is required by spec.

On Mon, Feb 27, 2017, 08:47 Pierre-Yves Gérardy [e-mail]
wrote:

Because of operator precedence rules, a || b && c really means a || (b &&
c).

typeof(null) is object in some circumstances (is it sloppy mode or old IE
versions? I don't remember exactly). Maybe we don't need this check
anymore...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lhorie/mithril.js/issues/1667#issuecomment-282723953,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AERrBKFdxTD0JKgyqP2WAcXP4YiXPRcmks5rgtQDgaJpZM4MNCwt
.

[pygy]

Another bug crystallized into spec for Web compat reasons, I suppose :-/

I didn't know it was universal... It could have been addressed with strict mode or modules (things that allow clean breaks from the past).

[isiahmeadows]

@pygy Sadly, it is, and here's a little bit of history for you on why typeof null === "object"

Edit: Also, strict mode was designed to still generally work the same way when run in sloppy mode. The only breaking changes were regarding this not being the global object and various errors. Fixing typeof null wouldn't have worked, because then, people would've written code that didn't work in engines that didn't support strict mode.

[isiahmeadows]

@userpixel Here's some equivalent code, with parentheses to show precedence:

// Original, with `arguments[1]` factored out for readability
var arg = arguments[1]
if (arg == null || typeof arg === "object" && arg.tag === undefined && !Array.isArray(arg)) {
  // ...
}

// Same, with explicit precedence
var arg = arguments[1]
if (
  arg == null || (
    typeof arg === "object" &&
    (arg.tag === undefined && !Array.isArray(arg))
  )
) {
  // ...
}

[pygy]

Strict mode also allows raw primitives passed as this, where as sloppy mode would wrap them in heap object containers...

I knew (but had overlooked while commenting) the bw/ compat. thing for strict mode.

[barneycarroll]

Can we produce an actionable bug report for this? I felt I was on the ball earlier but having forgotten & reading the thread back it looks like a series of disconnected academic observations…

[userpixel]

Considering the operator precedence the current behavior is not a bug.

[isiahmeadows]

If you can produce one @barneycarroll. So far, this appears to involve
generally correct behavior (although the tag check could admit nulls to
recover a few bits). Apart from that one nit, I don't see anything
actionable here.

On Mon, Feb 27, 2017, 16:27 Barney Carroll [e-mail] wrote:

Can we produce an actionable bug report for this? I felt I was on the ball
earlier but having forgotten & reading the thread back it looks like a
series of disconnected academic observations…

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/lhorie/mithril.js/issues/1667#issuecomment-282859601,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AERrBJsyzAe6c7nJRpj9hNz0W_D_Q_7yks5rgz_SgaJpZM4MNCwt
.