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

RE: [matrix][cssom-view] DOMPoint, DOMPointLiteral definitions

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 27 Sep 2013 22:22:58 +0000
To: "robert@ocallahan.org" <robert@ocallahan.org>, Simon Pieters <simonp@opera.com>
CC: www-style <www-style@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F9B25D3DD@BY2PRD0510MB354.namprd05.prod.outlook.com>
Also, just from a general OOP design point of view, imposing constraints like immutability on a subclass, but not a superclass, is a violation of the time-honored Liskov Substitution Principle. LSP is not an ironclad law of course, but a good principle to follow when designing interfaces used by humans. Ignoring it gets you into the usual trouble of e.g. `class Square extends Rectangle`, where the subclass has more constraints than the superclass (and thus can't be substituted for it in generic operations which accept an instance of the subclass). Indeed, that seems to be exactly the situation you're creating here.

http://www.oodesign.com/liskov-s-substitution-principle.html

Violations of this abound in the DOM, to be sure, but I contend that it's such violations that made DOM APIs so awkward, e.g. not being able to use an Element in all the places you can use a Node.
Received on Friday, 27 September 2013 22:23:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC