[whatwg] WebIDL vs HTML5 storage changes

[Maciej Stachowiak]

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