[Webkit-unassigned] [Bug 74718] Remove the `value' argument to op_push_new_scope

Tue Dec 20 13:21:36 PST 2011

https://bugs.webkit.org/show_bug.cgi?id=74718

--- Comment #6 from Gavin Barraclough <barraclough at apple.com>  2011-12-20 13:21:36 PST ---
(In reply to comment #5)
> It's not sound to use the same mechanism for block scope as we currently use for catch. Catch is rare, and already slow, so it's OK that catch requires an object allocation and scope chain push/pop. But if "let is the new var", it's not acceptable to allocate a new scope object and push/pop the head of the scope chain every time you enter/exit a let scope. We want a new solution that distinguishes between variables that are captured and variables that aren't, allocates uncultured variables on the stack, and tears of captured variables as needed.

Hey Geoff,

Actually I think Andy's approach may be the right one here.  For scopes that contain captured let/const variables we're going to potentially need multiple copies of the value, each with share-by-reference semantics between a set of closures (basically the same as catch, which is by intention).  Clearly for the common case where values are not captured we will want something that is more optimal, but I think it makes sense to develop the correct and compete form first, and then optimize.

By landing a scope based mechanism first, we can get this checked in (disabled by default, but being switched on in some cases by DRT to test it) with layout tests checking for correct behavior – and then add the complexity of a mechanism to optimize let/const values that are not captured to regular locals (also perhaps merging nested block scopes where safe - particularly it may make sense to merge outer scopes into the activation).

Having a functional (but not yet optimal) implementation for const will also allow us to answer another question, which is that we'd like to be able to test enabling this in place of the existing const implementation would be compatibility with the web (if so we'll only need to support one set of semantics going forwards).

What are your thoughts? - we could implement this the other way around - we could start out by treating let/const as a block-scoped version of locals with var-like capture semantics, and then bolt on a scope-based mechanism to handle correct capture semantics, but that seems less desirable to me.

G.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.