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: Mon, 14 Oct 2013 09:28:54 -0700
Message-ID: <CABHxS9j35tesizDABtWypvB2gS2ix--roE=-C4F1FUfjaSQUxQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "Tab Atkins, Jr." <jackalmage@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Robert O'Callahan" <robert@ocallahan.org>
On Mon, Oct 14, 2013 at 9:23 AM, Mark S. Miller <erights@google.com> wrote:

> On Mon, Oct 14, 2013 at 9:05 AM, Anne van Kesteren <annevk@annevk.nl>wrote:
>
>> On Mon, Oct 14, 2013 at 4:59 PM, Mark S. Miller <erights@google.com>
>> wrote:
>> > On Oct 14, 2013 6:58 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
>> >> We have the same notion elsewhere though. E.g. a <input readonly>
>> >> cannot be modified by the user, but can be modified through script.
>> >
>> > In this case, the "only" still describes a meaningful restriction,
>> where the
>> > restricted client is the user.
>>
>> That is the same notion Robbert is using. The user cannot modify the
>> object, but the user agent can.
>>
>
> The user agent is the browser, which can clearly modify any object it
> implements. Are we talking about user vs script, as in your <input
> readonly> example? Can the user modify a DOMRect object? If yes, and a user
> cannot modify a DOMRectReadOnly object, how can a DOMRect be a kind of
> DOMRectReadOnly?
>

This is all basic grade school syllogism stuff:

Socrates is a man.
A man can be read and written.
A man is a person.
A person can only be read, not written.
Therefore Socrates can and cannot be written.



>
> I thought the question was: What do we name the supertype that a
> read-write Foo, a read-only Foo, and an immutable Foo would have in common?
> Clearly, this is one of the questions in this thread, as it also relates to
> future extensions to Maps, Sets, WeakMaps, etc... whose clients are scripts
> but not users. Other possible namings:
>
> BaseFoo, AbstractFoo, CommonFoo,
> FooBase, FooAbstract, FooCommon
>
> but I like the idea of some variation on *read* or *query* to explain what
> these have in common.
>
>
>>
>>
>> >> Attributes annotated in IDL with "readonly" have the same behavior.
>> >
>> > Could you provide a link to the relevant part of the webidl spec, and
>> to an
>> > example of a webidl that makes use of this ambiguity? Thanks.
>>
>> http://dev.w3.org/2006/webapi/WebIDL/#dfn-read-only
>
>
> The text there is self contradictory. First, it says
> "An object that implements the interface on which a read only attribute is
> defined will not allow assignment to that attribute." which supports
> only-means-only.
>
> But then it says: "This[inherit] can be used to make a read only attribute
> in an ancestor interface be writable on a derived interface."
>
> They can't both be true.
>
>
>
>>
>> http://xhr.spec.whatwg.org/#xmlhttprequest (see any readonly attribute
>> defined here)
>>
>
> Looked. Where are these overridden to make them read-write?
>
>
>
>>
>>
>> --
>> http://annevankesteren.nl/
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM
Received on Monday, 14 October 2013 16:29:21 UTC

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