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.
I am a lot more swayed by this argument against adoption.
At this point, my concerns are not of a technical nature, but rather
of a "real life web" nature - either you force FFX and IE8 to remove
it, you have others adopt it, or the spec introduces a de facto
incompatibility on the web.
I have no solution, only this particular awareness of the problem.
~Brady
Regards,
Maciej
