Its a hazard when objects change nativeness and without it we can also get rid of dropProperty if we play our cards right.

gal, do you work on this? I would like to eliminate at least the drop method as the first step with the ultimate goal of avoiding recursive lookupProperty calls on non-native prototypes in js_LookupProperty and friends.

We can buddy up on this. I am planning major surgery on this, but we can do it in steps. My goal was to eliminate lookupProperty/dropProperty/get+setAttributes and replace them with hasProperty/getPropertyDescriptor/setPropertyDescriptor (getting/setting via JSPropertyDescriptor). get/setPropertyDescriptor will do its own lookup. JSScopeProperty is no longer exposed. Basically we will mirror the level of abstraction of procies with a few mild modifications and simplifications (merging enumerate and enumerateOwn) for example. I am also trying to figure out whether to do the proto walk inside or outside the API. Both has merit. Proxies (and e4x) want to lookup along proto on their own (or in case of e4x skip to NULL and stop the lookup). I was thinking maybe I will return the proto to consult next, then the loop is outside the api, but the api can stop the lookup.

No activity in a long time. Are we still doing this?

Yeah, but not for FF4 and we found a way around this for swap.

It isn't clear to me whether this bug is still relevant. Is it?

(In reply to David Bruant from comment #5) > It isn't clear to me whether this bug is still relevant. Is it? NI?ing Jason.

Barely relevant. I think the right way to interpret this now is to s/JSProperty/js::Shape/, at which point the only remaining op is lookupProperty. Once that operation dies, we can consider this bug fixed. Looking now, it appears at a skim that lookupProperty and LookupProperty and friends are basically used only for scope lookups of a name. I'm not sure how much work it would be to remove that, just yet, but certainly we're closer to it than we've ever been.