(In reply to Domenic Denicola from comment #0)
> Only DOMPoint and friends currently have constructors, but their base
> classes should too. It's impossible to do inheritance in JavaScript unless
> the base class is also constructible, so having DOMRect inherit from a
> non-constructible class is C++ magic that cannot match JavaScript semantics.
> 
> Besides, if the platform wants read-only interfaces, then so will users.

It is not correct that DOM*ReadOnly can not exist without constructors. Authors can just not create them.

There were no use case for adding constructors for DOM*ReadOnly. The idea for adding them is so that implementations can return mutable objects that can not be modified by the user. Especially layout and SVG has use cases for that.

If you have good use cases, please send them to the public mailing lists.

> It is not correct that DOM*ReadOnly can not exist without constructors. Authors can just not create them.

Right, they can only be created through C++ magic, which is not explicable through JavaScript semantics. This is not acceptable from a technical architecture point of view for the web platform, and is something the TAG has been repeatedly pointing out and correcting throughout specs recently in an attempt to align them with the semantics of the host language.

(In reply to Domenic Denicola from comment #2)
> > It is not correct that DOM*ReadOnly can not exist without constructors. Authors can just not create them.
> 
> Right, they can only be created through C++ magic, which is not explicable
> through JavaScript semantics. This is not acceptable from a technical
> architecture point of view for the web platform, and is something the TAG
> has been repeatedly pointing out and correcting throughout specs recently in
> an attempt to align them with the semantics of the host language.

These are DOM objects, no JS objects. It is important that the DOM can create the *ReadOnly objects, not the author.

I actually follow another sentiment where we should not expose any functionality that is not explicitly requested. Exposing unused functionality is much worst for the web platform because it is a bigger burden to get rid of it later when a different API replaces the functionality.

> These are DOM objects, no JS objects.

The point we're trying to make is that this distinction is actively hurtful to developer ergonomics and to the health of the web platform. We will be writing a TAG finding on this soon to make it clearer.

> It is important that the DOM can create the *ReadOnly objects, not the author.

Why? Is this a security boundary of some sort? If you create *ReadOnly objects, will users break the security of the browser? I didn't see any such holes in the spec.

> I actually follow another sentiment where we should not expose any functionality that is not explicitly requested.

This argument is not tenable when it involves breaking language semantics. You are not exposing any capabilities that don't already exist as part of the language.

Besides, if we're talking about requests, I'd love to see where anyone requested read-only versions of these objects at all. They are unidiomatic and useless to developers, who would simply expect mutable snapshots with data properties instead of these getter-laden prototypes.

(But that's another story.)

> Exposing unused functionality is much worst for the web platform because it is a bigger burden to get rid of it later when a different API replaces the functionality.

We wouldn't have to keep replacing APIs if they were designed to be idiomatic in the first place.

(In reply to Domenic Denicola from comment #4)
> Besides, if we're talking about requests, I'd love to see where anyone
> requested read-only versions of these objects at all. They are unidiomatic
> and useless to developers, who would simply expect mutable snapshots with
> data properties instead of these getter-laden prototypes.

We had very long discussions on public-script, www-style and even at WebApps F2F and CSS F2F in Shenzhen. The specified result was the conclusion of it.

(In reply to Dirk Schulze from comment #5)
> (In reply to Domenic Denicola from comment #4)
> > Besides, if we're talking about requests, I'd love to see where anyone
> > requested read-only versions of these objects at all. They are unidiomatic
> > and useless to developers, who would simply expect mutable snapshots with
> > data properties instead of these getter-laden prototypes.
> 
> We had very long discussions on public-script, www-style and even at WebApps
> F2F and CSS F2F in Shenzhen. The specified result was the conclusion of it.

I was told that Blink has similar issues as olliej described with constructors. For now Blink did not implement it with Blink-in-JS but with C++ in DOM.
https://codereview.chromium.org/404803002/

(In reply to Dirk Schulze from comment #6)
> (In reply to Dirk Schulze from comment #5)
> > (In reply to Domenic Denicola from comment #4)
> > > Besides, if we're talking about requests, I'd love to see where anyone
> > > requested read-only versions of these objects at all. They are unidiomatic
> > > and useless to developers, who would simply expect mutable snapshots with
> > > data properties instead of these getter-laden prototypes.
> > 
> > We had very long discussions on public-script, www-style and even at WebApps
> > F2F and CSS F2F in Shenzhen. The specified result was the conclusion of it.
> 
> I was told that Blink has similar issues as olliej described with
> constructors. For now Blink did not implement it with Blink-in-JS but with
> C++ in DOM.
> https://codereview.chromium.org/404803002/

Ignore this comment. It was not meant to be on this bug report.

I added constructors to all read-only interfaces in the spec now. Please review the changes to DOMMatrix

IndexSizeError feels a bit wrong to me. I would have expected TypeError.

(In reply to Simon Pieters from comment #9)
> IndexSizeError feels a bit wrong to me. I would have expected TypeError.

We only throw IndexSizeError when you have more or less values in a sequence then expected. I thought it would be the proper way in those situations but can be convinced otherwise.

Right. The description of IndexSizeError is "The index is not in the allowed range.".
https://dom.spec.whatwg.org/#indexsizeerror

However, there is no index provided. There is no allowed range.

What we have is more like arguments, with 6 or 16 arguments allowed. When an API is called with too few arguments, WebIDL throws TypeError.

(In reply to Simon Pieters from comment #11)
> Right. The description of IndexSizeError is "The index is not in the allowed
> range.".
> https://dom.spec.whatwg.org/#indexsizeerror
> 
> However, there is no index provided. There is no allowed range.
> 
> What we have is more like arguments, with 6 or 16 arguments allowed. When an
> API is called with too few arguments, WebIDL throws TypeError.

Sounds reasonable. I'll update the spec.

LGTM. I've added Alex to the CC since I think he was hoping for something that would allow users to modify the DOMRectReadOnly they create, e.g.

var setter;
var drro = new DOMRectReadOnly(setter_ => setter = setter_);

// give drro to someone; they cannot modify it

// but you can modify it:
setter({ x: 5, y: 10 });

I believe he was going to come up with use cases for this. I think it's a nice-to-have but not too important.

Let's close this bug.