RE: Exposing constructors of readonly interfaces to web authors

The interface we're trying to expose here is very simple and conventional:

We have a DOMQuad, whose state is mutable in various ways. We want to
expose a view of its state, the bounding rectangle. This view must be
read-only (since it doesn't make sense to mutate the bounding rect
directly). Since this view is a rectangle, for consistency we want to
expose it as some kind of readonly rectangle object matching, as much as
possible, the API of the mutable rectangle objects returned by other DOM
APIs. It seems more natural to expose this view as an attribute than via a
method getter, and that means repeated gets on the same DOMQuad must return
the same object (which is also a little more efficient), which means that
object needs to be live with respect to changes in the DOMQuad.

In any imperative OO language I know of, this is easy to implement. The
bounds object keeps a hidden reference to the DOMQuad and implements its
readonly APIs as functions of the DOMQuad state, and the DOMQuad keeps an
reference its bounds object. As far as I can tell, this is implementable in
JS too, using getters in the prototype:

var quad = {x1:1, x2:2, x3:3, x4:4};function QuadBounds(q) {  this.q =
q;}Object.defineProperty(QuadBounds.prototype, "left", {get:function()
{  return Math.min(this.q.x1, this.q.x2, this.q.x3, this.q.x4);}});var
b = new QuadBounds(quad);alert(b.left);

So I don't actually know what the problem is here :-).

PS: no DOM API returns DOMRects or DOMQuads that are live with respect to
CSS/DOM state, if anyone's worried about that.

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