'instanceof' should not completely expand RHS

[kpreid]

Original issue 31 created by ihab.awad on 2008-01-15T01:27:55.000Z:

If I have --

function foo() {}
... x instanceof foo ...

the current expansion will expand the RHS of the 2nd line completely, to --

... x instanceof .primFreeze(___OUTERS.foo)) ...

we need an expansion which re-scopes to _OUTERS_ but does not prematurely freeze.

[kpreid]

Comment #1 originally posted by mikesamuel on 2008-01-18T06:05:36.000Z:

What about the operand to typeof?

Should
typeof foo
=>
typeof .primFreeze(___OUTERS.foo)
?

[kpreid]

Comment #2 originally posted by erights on 2008-01-18T22:40:41.000Z:

On Jan 18, 2008 10:21 AM, Mike Samuel mikesamuel@gmail.com wrote:

On Jan 17, 10:08 pm, "Mark Miller" erig...@gmail.com wrote:

Good point. It should not. And while we're thinking to enumerate such
things, neither should === or !==, whereas == and != should expand
operands. Hmmm. Getting kinda complex and hard to remember. ;(

What's the rule of hand?

"of hand?"?

If an expansion could cause an implied valueOf or toString invocation,
then it needs to check frostiness?

At least. If an expansion could cause an access of any sort with a function's
properties other than one of the exempted initialization actions, then this must
cause the function to be frozen.

Thanks for prodding me to clarify this. In the process I realize that my proposed
exemption for instanceof is wrong. "x instanceof T" causes an access of
"T.prototype". Until the function is frozen this can change. Had Ihab implemented the
rule I'd proposed, this change would have been observable. I now realize that Ihab's
implementation is correct and my spec is wrong. I'm closing bug
http://code.google.com/p/google-caja/issues/detail?id=31 as Invalid.

[kpreid]

Comment #3 originally posted by mikesamuel on 2008-01-20T03:37:46.000Z:

But typeof still shouldn't be frozen, right