You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I've been looking at the descriptor attributes for ES5, even pushed my initial implementation to the ecmascript5-branch. There is a subtle difference between the attributes between ES3 and ES5, basically:
In ES3, the attributes are called DontEnum, DontDelete and ReadOnly. In ES5 they are called Enumerable, Configurable and Writable. They map like this to eachother:
DontEnum = Enumerable
DontDelete = Configurable (actually means more then just not delete-able in ES5, but not important here)
ReadOnly = Writable
The main difference is that the ES3 attributes are make up a "black list" of non-allowed actions, while the ES5 attributes make up a "white list" of allowed actions. The most common state in ES3 is that no attributes are set, since 99% of all properties allow all three actions. The most common state in ES5 is that all attributes are set, for the same reasons as ES5.
Having bit-flags to signal "set" state in ES5, since this is the most common case, would require us to set the three common flags on every descriptor that is created. This would cost performance, so I choose a different route.
I kept the semantics of the ES3 attributes in place: a non set bit signals an allowed action, and a set bit signals a disallowed action. However I renamed the attributes to better match the ES5 ones, and they are called NotWritable, NotEnumerable and NotConfigurable.
This basically forces you to do a boolean not operation when you test if something is writable, since the bit flag will be zero. An added benefit is also that we don't have to re-write any of our already existing code that works with these attributes, since the semantics are the same as ES3.
Confusing?
The text was updated successfully, but these errors were encountered:
I've thought about this and believe that it will cause a small amount of confusion. That being said I don't believe this will be an issue for experienced developers.
I'm not sure I like this shortcut. If it's too much work adding the ES5 attributes everywhere manually, can't it be done through AOP with LinFu, PostSharp or something similar (as a post-build process, for example)?
So I've been looking at the descriptor attributes for ES5, even pushed my initial implementation to the ecmascript5-branch. There is a subtle difference between the attributes between ES3 and ES5, basically:
In ES3, the attributes are called DontEnum, DontDelete and ReadOnly. In ES5 they are called Enumerable, Configurable and Writable. They map like this to eachother:
DontEnum = Enumerable
DontDelete = Configurable (actually means more then just not delete-able in ES5, but not important here)
ReadOnly = Writable
The main difference is that the ES3 attributes are make up a "black list" of non-allowed actions, while the ES5 attributes make up a "white list" of allowed actions. The most common state in ES3 is that no attributes are set, since 99% of all properties allow all three actions. The most common state in ES5 is that all attributes are set, for the same reasons as ES5.
Having bit-flags to signal "set" state in ES5, since this is the most common case, would require us to set the three common flags on every descriptor that is created. This would cost performance, so I choose a different route.
I kept the semantics of the ES3 attributes in place: a non set bit signals an allowed action, and a set bit signals a disallowed action. However I renamed the attributes to better match the ES5 ones, and they are called
NotWritable
,NotEnumerable
andNotConfigurable
.This basically forces you to do a boolean not operation when you test if something is writable, since the bit flag will be zero. An added benefit is also that we don't have to re-write any of our already existing code that works with these attributes, since the semantics are the same as ES3.
Confusing?
The text was updated successfully, but these errors were encountered: