Re: [whatwg] WebIDL vs HTML5 storage changes - delete behavior

2009-01-13 Thread Ian Hickson
On Wed, 14 Jan 2009, Cameron McCormack wrote:
> > 
> >[NameCreator, NameDeleter, NameGetter, NameSetter]
> >interface DOMStringMap {};
> 
> At the moment, the interface is useful only for JS (and other languages 
> that support this kind of indexing).  For other languages, a 
> DOMStringMap object would appear to be a completely opaque object 
> without any means of interacting with it.  Given that this is basically 
> meant to be a shorthand for getting/setting attributes with particular 
> names, I would be happy with it not existing in other language bindings. 
> Web IDL doesn’t have a mechanism to state that an interface member or 
> a definition should only be included if the target language binding is a 
> particular one, though.
> 
> An alternative would be to put operations on the interface to act as the 
> getters/setters/etc., and use the [NoIndexingOperations] extended 
> attribute to indicate that these operations won’t correspond to 
> properties in language bindings such as ECMAScript.  That would then at 
> least make the interface useful for other languages.

What I would like to be able to say is: "This is how it works in JS. If 
you are implementing this in another language binding, contact me and 
we'll come up with a solution for that language."

I don't want this to only work in JS, I just haven't designed the API for 
the other languages. And I don't want to introduce a suboptimal design -- 
e.g. the above IDL would be meaningless for Perl, where objects don't have 
a concept of name getters, etc. But for Perl what we'd want is to expose a 
tied hash, which is the equivalent of what this is in JS. But we don't yet 
have WebIDL magic for Perl, so I can't say that yet.

Does that make sense?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] WebIDL vs HTML5 storage changes - delete behavior

2009-01-13 Thread Cameron McCormack
Ian Hickson:
> > > For DOMStringMap, my intention was to not provide methods at all, and 
> > > only provide the JS-native mechanisms.

Maciej Stachowiak:
> > A bold choice, but I would not recommend it as the sole available 
> > mechanism.

Ian Hickson:
> See above for UndoManager, but for DOMStringMap I don't want to add any 
> other mechanisms, because they introduce name clashes. Right now the IDL 
> for DOMStringMap is:
> 
>[NameCreator, NameDeleter, NameGetter, NameSetter]
>interface DOMStringMap {};
> 
> It basically emulates a JS Object. It's intended only for JS. I don't see 
> why this is a bad idea.

At the moment, the interface is useful only for JS (and other languages
that support this kind of indexing).  For other languages, a
DOMStringMap object would appear to be a completely opaque object
without any means of interacting with it.  Given that this is basically
meant to be a shorthand for getting/setting attributes with particular
names, I would be happy with it not existing in other language bindings.
Web IDL doesn’t have a mechanism to state that an interface member or a
definition should only be included if the target language binding is a
particular one, though.

An alternative would be to put operations on the interface to act as the
getters/setters/etc., and use the [NoIndexingOperations] extended
attribute to indicate that these operations won’t correspond to
properties in language bindings such as ECMAScript.  That would then at
least make the interface useful for other languages.

-- 
Cameron McCormack ≝ http://mcc.id.au/


Re: [whatwg] WebIDL vs HTML5 storage changes - delete behavior

2009-01-13 Thread Ian Hickson

On Sun, 18 May 2008, Maciej Stachowiak wrote:
> On May 18, 2008, at 3:18 PM, Brady Eidson 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.

On Sun, 18 May 2008, Brady Eidson wrote:
> 
> WebKit has the ability to add custom property deletion on a per-class 
> basis - therefore not slowing down the common case at all.  That's how I 
> fixed the bug to make us compatible with IE8 and Firefox for now as this 
> debate gets underway...

On Mon, 19 May 2008, Geoffrey Garen wrote:
> 
> It is *very* weird, and therefore not a "useful shorthand."
> 
> In JavaScript, "delete" means "remove this property / interface from 
> this JavaScript object." I can't think of any context in which it means 
> anything else.
> 
> For example, "delete node.parentNode" attempts to remove the 
> "parentNode" property from "node". It does not remove "parentNode" from 
> the document or anything like that.
> 
> "delete window" attempts to remove the "window" property from the global 
> object. It does not close the window or anything like that.
> 
> In other words, you can be certain that "delete" is a simple operation 
> with a consistent side-effect.
> 
> As a JavaScript programmer, I would find it very difficult to reason 
> about objects that might or might not change the behavior of the 
> "delete" operator. One reason i would find it very difficult is that 
> operator overloading does not exist in JavaScript at all, so to 
> understand this one API, I would need to understand a vast corpus of 
> programming language goobery that is not at all covered in any 
> JavaScript manual. Another reason I would find it very difficult is that 
> the overloaded meaning of "delete" here ("remove persistent storage from 
> disk") is far afield from the original meaning ("remove interface from 
> temporary object in memory"). To give you an analogy, even in C++, where 
> you're allowed to overload operator delete, if you overloaded operator 
> delete to mean "do not free this object's memory, but do delete the file 
> it references from the file system", well, let's just say that your 
> patch would not pass code review with any of your four reviewers :).
> 
> I am not sure if any JS decoration or collection libraries depend on the 
> canonical behavior of operator delete, but if they do, I would hate for 
> them all to have to ship with the asterisk, "BEWARE: do NOT use this 
> decoration / collection library with that one weird DOM object that 
> interprets 'delete' to mean 'remove important data from the user's 
> disk'". Oy!

On Mon, 19 May 2008, Brady Eidson wrote:
> 
> I'm unsure if you have the proper background with the Storage interface 
> that is in question here.  I'm guessing that the reason that Firefox 2 
> and IE8 support the "modified" behavior of delete for Storage items is 
> because the "way of thinking about Storage items" we're trying to get 
> across meets most of the expectations of manipulating properties that 
> you lay out below.
> 
> On May 19, 2008, at 3:18 PM, Geoffrey Garen wrote:
> > 
> > In JavaScript, "delete" means "remove this property / interface from 
> > this JavaScript object." I can't think of any context in which it 
> > means anything else.
> 
> The spec makes it clear that storage items and properties on the Storage 
> object are interchangeable.
>
> `storage.foo = "bar"` happens to be equivalent to 
> `storage.setItem("foo", "bar")`, but is also no different from 
> `someRandomObject.foo = "bar"` as far as keeping a collection of 
> properties on an object.
> 
> This also applies for enumeration, etc.
> 
> Equivalently and more relevant to the discussion, `delete storage.foo` 
> happens to be equivalent to `storage.removeItem("foo")`, but is also 
> *little* different from `delete someRandomObject.foo`
> 
> > For example, "delete node.parentNode" attempts to remove the 
> > "parentNode" property from "node". It does not remove "parentNode" 
> > from the document or anything like that.
> >
> > "delete window" attempts to remove the "window" property from the 
> > global object. It does not close the window or anything like that.
> 
> In