[whatwg] WebIDL vs HTML5 storage changes
mjs at apple.com
Mon May 19 16:17:45 PDT 2008
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]
>>> 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]
>> 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
- 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
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 = 'value';
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
More information about the whatwg