Re: Figuring out easier readonly interfaces

On Oct 17, 2013, at 8:22 PM, Mark S. Miller <erights@google.com> wrote:

> 
> 
> 
> On Thu, Oct 17, 2013 at 10:58 AM, James Graham <james@hoppipolla.co.uk> wrote:
> On 17/10/13 16:49, Mark S. Miller wrote:
> Yes. I don't like DOMRectView but I will not object to it.
> 
> Isn't this confusing with ArrayBufferView, which afaict is read/write?
> 
> I think DomRectReadOnly is a fine name. Anyone who expects "readonly" to mean "immutable"
> 
> Hi James, did you miss the immediately preceding messages? No one is arguing that readonly implies immutable. Through an immutable object, no changes can be observed or caused. Through a readonly object, changes to some underlying state can be observed but not caused. 

Isn't the last point exactly what we try to archive? So isn't ReadOnly the right name according to your own definition?

Greetings,
Dirk

> 
> 
>  
> will already be confused by DOM, WebIDL, and numerous other libraries and frameworks that use "readonly" in some situation where the mutability depends on who is trying to make the change (e.g. [1], [2])
> 
> [1] https://developer.apple.com/library/mac/documentation/cocoa/reference/CocoaBindingsRef/Concepts/BindingTypes.html
> 
> [2] http://qt-project.org/doc/qt-4.8/qml-textinput.html#readOnly-prop
> 
> In a quick skim of these I did not find anything that contradicts the view that a read-only object implies the inability to modify the underlying state *via that object*. But there's a lot of text there and searching for "who" didn't find anything. Where do these APIs violate the LSP interpretation of read-only?
> 
> 
> -- 
>     Cheers,
>     --MarkM