Callability of <object> (was: Re: Array-with-item in WebIDL)

On 6/17/15 10:48 AM, Garrett Smith wrote:
> With an attitude like that, how likely are web programmers to read it
> and give feedback on it?

For this part it doesn't matter much, because it's a legacy feature that 
doesn't particularly require feedback.

> That's a sub sub point to the bigger point. And if that subpoint is
> corret, then the spec/draft should say that. Does it?

Yes.

> No, looks like it says that OBJECTs have a legacycaller property whose name or type
> is `any`.

Well, then the question is what "have a legacycaller" means, no?  And 
what it means is defined at 
<http://heycam.github.io/webidl/#idl-legacy-callers>,

> The bigger point is "What's arraylike and has a contains method on the
> web"?

No, the question at hand is "what's arraylike, might get replaced by an 
Array subclass, and has a contains method on the web?"  That's not the 
same as your version at all.

> I read: "We tried to add contains to Array.prototype for ES7 but it turns out
> to break the web."

Sure.

> Ducktyping and feature testing is relevant in JavaScript. Feature
> tests for contains might be along the lines of:—
>
> if(typeof x.contains == "function") {

That hasn't been an issue.

 > Mootools also adds a `contains` method.

Yes, I'm well aware.  That's what broke adding Array.prototype.contains 
in ES7.

> The HTML5 spec saying OBJECT *has* a `legacycaller` property is
> confusing. It doesn't clearly say that the OBJECT element *is*
> callable.

It says that there is a legacycaller; the behavior is then defined by 
the IDL spec.  Just like it says that there is a "attribute DOMString 
data" but what that actually means (a property named "data" with a 
getter and a setter) is defined by the IDL spec.

This is a legacy and deprecated feature (note the name!) that people 
should not be using; it's in the spec because UAs need to implement it 
for compat with some old sites.  It makes perfect sense to not spend too 
much time in the spec talking about it.

> Most web developers don't read specs because the specs are
> confusing.

I agree that this is a problem.  The way to solve it is to have web 
developer facing documentation... but that documentation is likely to 
not mention legacy deprecated features in the first place.

> You have an arrogant attitude about bad documentation for
> bad API design and I don't like it.

This isn't about API _design_.  It's just a legacy compat issue.  If 
your beef here is about the design of this API, you need a time machine 
to talk to the folks who initially added plug-in support to Netscape...

You are of course free to not like my attitude, and I am free to 
reciprocate.  But I think in this case the spec makes the right call in 
not spending too much time discussing the intricate details of a 
deprecated feature.

-Boris

Received on Wednesday, 17 June 2015 15:11:39 UTC