- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 10 Jul 2012 22:30:21 +0000 (UTC)
- To: whatwg@whatwg.org
On Wed, 2 May 2012, Rick Waldron wrote:
> On Wed, May 2, 2012 at 7:17 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Wed, 2 May 2012, Rick Waldron wrote:
> > >
> > > JS APIs like this should always return the object (constructed
> > > instance or not) and therefore chain implicitly.
>
> Let me rephrase, I simply expect modern DOM APIs to return something
> useful.
I don't think a function should return something just for the sake of
returning something. I agree that when there is something useful to return
(something that the caller doesn't already have at hand, in particular,
and might be able to make use of) that it makes sense to return it.
> > I understand that this is mostly a matter of taste in API design, but
> > IMHO that's an anti-pattern.
>
> If you're writing and designing specifications that will be implemented
> in JavaScript, then you should design them _for_ JavaScript. Section 15
> of EcmaScript specifies more then enough "prior art" that supports my
> statement above.
There's plenty of prior art in the Web platform to support pretty much any
pet design philosophy.
> > It encourages poor style;
>
> 60% of the JavaScript written on the web disagrees.
Disagrees with what? You really think that 60% of the Web is written in
good style?
> > it discourages functional programming patterns, instead favouring
> > state mutation patterns;
>
> JavaScript is a multi-paradigm language, leave your design hangups at
> the door.
...says the guy arguing for a particular paradigm. :-)
> > it makes APIs harder to extend;
>
> This is just outright false, considering JavaScript is probably the most
> extendable and historically extended language at the API level.
If you have a return value, you can't change it. If you don't, you at
least have the chance that you might be able to introduce one. So yes, it
makes APIs harder to extend.
> > it makes APIs that do have useful return values inconsistent with
> > other APIs;
>
> elem.classList.add("foo") returns "undefined". That's hardly what I
> would consider a "useful return value".
Right. But elem.classList.contains() returns a boolean, and
elem.classList.item() returns a string. So they can't be consistent with
the APIs that return self.
> Returning the element's classList instance makes an incredible amount of
> rational sense.
It's an aesthetic choice with some advantages and some disadvantages. I
don't think it's an obvious choice, by any means.
> > it is, in fact, a layering violation: it attempts to shoehorn what
> > should be a language design feature into the API layer.
>
> Much like the DOM and its weird C++ and Java influences.
We're trying to reduce them, not
> Is this group aiming to define APIs that developers will always paper
> over with abstractions, guaranteeing all app code needs a good 50k just
> to provide a decent API?
There are certainly design decisions where one might wonder whether I am
just actively trying to make the Web bad (localStorage comes to mind). But
when it comes to chaining vs not chaining, it's just not the same. I
understand that some people prefer:
a.foo().bar().baz();
...rather than:
a.foo();
a.bar();
a.baz();
...but if an author cares so much about the difference that they'll write
50,000 lines of code (!) to abstract out the difference (!) then I think
they might have their priorities set up wrong.
On Thu, 3 May 2012, Jake Verbaten wrote:
>
> Choosing some mechanism to add multiple classes at once is useful, whether
> that's making add have an arbitary arity, allow it to take an array, allow
> it to take a space seperated string or allowing add calls to be chained.
>
> My personal vote is for arity.
This API is now in the DOM Core specs, so I'll let the DOM Core editors
respond to this.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 July 2012 22:30:49 UTC