W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

Re: Figuring out easier readonly interfaces

From: Mark S. Miller <erights@google.com>
Date: Wed, 2 Oct 2013 18:08:07 -0700
Message-ID: <CABHxS9hujb62=GhXosWq3pMsDzePTYssvDR_4JTA7Avt-P7vvw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
If Foo is a subtype of Bar and you pass a Bar to a function that takes a
Foo, what should happen?

I ask because Foo is a almost an LSP subtype of readonly<Foo>. The LSP
common supertype of Foo and readonly<Foo> has exactly the signature of
readonly<Foo>.


On Wed, Oct 2, 2013 at 6:02 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

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


-- 
    Cheers,
    --MarkM
Received on Thursday, 3 October 2013 01:08:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC