Re: Figuring out easier readonly interfaces

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.




> 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<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<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