- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 02 Oct 2013 21:02:01 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 10/2/13 7:02 PM, Tab Atkins Jr. wrote: > Okay, so that's a no go in general. So here's a question. What set of use cases are we trying to addres? Defining something where setters have to automatically no-op or throw on an object because it's readonly is not too bad. The complicated thing is (mutator) methods. To address that you have to mark which methods are mutators or something. That then still leaves the question of what happens when you pass a readonly<Foo> to a function that takes Foo, I guess. > Interfaces can opt into readonly behavior with a [ReadonlyCapable] > extended attribute Right, this would be explicit opt-ins. -Boris
Received on Thursday, 3 October 2013 01:02:32 UTC