On May 18, 2008, at 6:44 PM, Brady Eidson wrote:
On May 18, 2008, at 5:58 PM, Maciej Stachowiak wrote:
While I'm on the topic, I'm also curious about that [XXX]
placeholder.
There's a bug in WebKit's bugzilla pointing out that the IE8 beta
and Firefox 2 both support `delete storage.keyName` syntax as an
alias for `storage.removeItem(keyName)`
I'm taking a guess here and assuming supporting the `delete`
syntax is the implied concept behind [XXX]
WebKit's JavaScript engine doesn't currently have the ability to
run custom code when a property is deleted. It would be a
significant challenge to add this capability and possibly a
performance regression; and no other DOM-related spec requires
this, even when there is NameGetter or IndexGetter behavior. For
example NodeLists and HTMLCollections do not let you delete by name
to remove the item (I'm not sure what that would even mean). So I'd
prefer not to have to introducethis concept just for this one case.
WebKit has the ability to add custom property deletion on a per-
class basis - therefore not slowing down the common case at all.
I looked into this and in all other cases we use an override of delete
for the following effects:
- Special case for Arrays since they store some of their properties
differently.
- Prevent deletion (though it would be better in most of these cases
to just rely on DontDelete attributes)/
- Cross-site scripting security checks on delete.
I think the Storage case would be more complicated than this, because
it dispatches an event and so can run arbitrary JavaScript code. I
think our JS interpreter is likely not prepared for "delete" executing
arbitrary JS code, and so may crash when this happens. We can fix it,
but I think delete having special behavior is not that great from the
point of design.
Comparing conciseness and familiarity:
storage.keyName
storage.getItem('keyName')
storage.keyName = 'value';
storage.setItem('keyName', 'value');
delete storage.keyName;
storage.removeItem('keyName');
The getter seems like the biggest relative increase in conciseness,
and the getter and setter will both be much more familiar with
operator syntax. But delete is fairly rarely used (and unlike getters
and setters does not allow overriding at the JS level in many
implementations) so the syntax is not much more familiar. The
improvement in conciseness is also less.
We should also keep in mind that overloading operators is kind of a
big deal and should not be done lightly. If the HTML5 spec required
custom behavior for * or && for certain objects rather than following
the JS rules I think we would all be pretty concerned.
So I'd rather avoid messing with the (relative) purity of the delete
operator.
Regards,
Maciej