Namespaces as Sugar (was: complexity tax)
Maciej Stachowiak
mjs at apple.com
Tue May 27 23:46:32 PDT 2008
On May 27, 2008, at 12:18 PM, Mike Shaver wrote:
> 2008/5/27 Maciej Stachowiak <mjs at apple.com>:
>> It could save a lot of complexity, by not requiring any first-class
>> support
>> for namespace lookup on arbitrary objects.
>
> Is the expectation then that having two lookup models, one for global
> objects and the other for non-global objects, going to provide less
> complexity?
My proposal is that there is one for lexical scope lookup along the
scope chain (which considers open namespaces when binding unqualified
names) and another for property lookup qualified to an object
reference (which does not). Yes, I believe this will provide less
complexity, because the scope chain and prototype chain algorithms are
quite complex in the current proposal and not the same as each other.
My rough proposal would greatly simplify the prototype chain algorithm
and not make the scope chain algorithm any more complex (it may become
simpler).
> In a browser, "window" is the global object; would property lookup on
> "window" be namespaced when referenced as such? When you have a
> handle to another window? When you use |this.prop| in a global
> function?
My proposed answer to all of these would be no.
> If we have namespace-aware lookup, it seems to me that it would be
> less complex for implementors and script authors alike for it to
> always apply, rather than just for one magical object.
I think it would be simpler to limit the effect of namespaces to
lexical bindings (where we know we can bind to the right name and
namespace statically in any case of interest) and not have them affect
object property lookup in general.
Regards,
Maciej
More information about the Es4-discuss
mailing list