[widgets] Comments on section 5.1 protected preferences

I've investigated this issue, and I'm afraid it does not seem possible  
to have protected attributes in a pure JavaScript implementation.  
While private attributes and protected methods are supported using  
closures, protected attributes are not; a private attribute exposed  
using a public or protected method would protect the attribute, but  
would not provide the functional behaviour required by the spec (i.e.  
a widget.preferences.foo would return "function" and not the value of  
the private attribute "_foo"). I'm open to alternative suggestions,  
but I've had a good go at this and haven't found anything that would  
work as specified.

I suggest as a way forward that, as the "read only" definition  
provided by IDL for metadata attributes does support a pure JavaScript  
implementation, that 5.1 also adopts the same approach:

"The attribute is read only if the "readonly" terminal is used in the
definition. An object that implements the interface on which a read
only attribute is defined will not allow assignment to that attribute.
It is language binding specific whether assignment is simply
disallowed by the language, ignored or an exception is thrown. "

E.g., if a Widget package defines a read-only preference "foo", and  
the runtime Widget instance calls "foo = bar", a JavaScript  
implementation is still conforming if it does not persist the change  
for subsequent sessions (the "ignore" clause).

This would probably be quite simple in terms of text, as all that  
would be required would be to state that protected keys should be  
treated as read-only attributes.

S

>> Section 5.1 and "syntactic sugar"
>> ==========================
>> Section 5.1, para 4 reads:
>> "Upon invocation of the setItem() or removeItem() method by an author
>> script on a protected key, user agent must throw
>> a NO_MODIFICATION_ALLOWED_ERRexception. The  
>> NO_MODIFICATION_ALLOWED_ERR is
>> defined in the [DOM3Core] specification."
>> OK, this is fine, we can implement this. However, what about:
>> widget.preferences.blah = "new value"; // where "blah" is a read- 
>> only key
>> We really don't have any way to prevent this happening or throwing an
>> exception. Luckily for us the conformance statement above doesn't  
>> mention
>> it, which means we don't have to!
>
> Hmm...
>
>> However I don't think this was the intention - it just shows one of  
>> the
>> problems with the "syntactic sugar" interpretation of WebStorage.  
>> For any UA
>> other than a browser, you really don't get the option to protect  
>> exposed
>> javascript properties.
>
> Are you absolutely sure about this? No fancy closures, or using
> Crockfords' methods will help here?
>
>> I suggest changing the example in 6.4.2 to use getItem(), and  
>> adding a note
>> re: alternative syntax.
>> Personally I'd rather exclude them for the sake of  
>> interoperability. If not,
>> 5.1 para 4 & 6.4 para 4 need changing to cover semantically- 
>> equivalent
>> operations using alternative syntaxes; however unless the conformance
>> requirement is reworded as per my suggestion above for read-only  
>> metadata
>> attributes, we probably have to give up any hope of ever conforming  
>> to the
>> spec :-(
>
> Nah! we will work it out :)