Re: Figuring out easier readonly interfaces

I agree with Mark. There is no way to automatically derive the read-only
version of an interface. So at least we'd need per-member annotations that
describe how to a readonly<Foo> is related to a Foo.

The approach I'm pushing for DOMRect in www-style seems much simpler to me:
have (conceptually) three separate interfaces:
-- DOMRectReadOnly: an interface exposing read-only accessors to the
current state of a DOMRect. Nothing is said about whether the object is
mutable or not.
-- DOMRect: a subinterface of DOMRectReadOnly, exposing mutating APIs.
-- DOMRectImmutable: a subinterface of DOMRectReadOnly, which guarantees
that the state never changes.
This approach satisfies the LSP. There's minimal duplication of
methods/attributes. It works well in WebIDL since WebIDL already allows
attributes to be readonly in DOMRectReadOnly and writable in DOMRect. (In
this specific example we don't need DOMRectImmutable right now so we won't
define it.) What's not to like? :-)

FWIW we give the mutable type the shortest, most obvious name since we
expect the most common usage of any of these names in user code will be to
construct new instances of the mutable type.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*