Extend the dfn of object types. #211

tobie · 2016-10-27T10:21:33Z

Update [SameObject] and [NewObject] to rely on it.

Fixes #71
Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605

Preview (#dfn-object-t…) (#NewObject) (#SameObject) | Diff w/ current ED | Diff w/ base

Update [SameObject] and [NewObject] to rely on it. Fixes whatwg#71 Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605

annevk · 2016-10-27T11:18:23Z

index.bs

+the [=promise type=],
+the [=exception types=],
+the [=buffer source types=], and
+[=union types=] whose [=member types|members=] are [=object types=]


s/are/contain/, no? Otherwise a union with a string would not be considered.

Otherwise a union with a string would not be considered.

Mistakenly thought this was the point. Good catch.

tobie · 2016-10-27T11:50:20Z

Do we have to account for null types, especially within unions? i.e. are the following object types (currently neither are, if my understanding of what I wrote is correct)?

(DOMstring or DOMException?)
(float or (DOMstring or DOMException)?)

domenic · 2016-10-27T14:52:34Z

This LGTM but I'd like @bzbarsky and/or @heycam to check, as I'm not confident about the cases like union types or null types. For example I'm not sure we actually want [SameObject]/[NewObject] to apply to (DOMString or DOMException), but I guess in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605#c1 @bzbarsky says we do, so I'd rather trust him on this.

tobie · 2016-11-07T13:33:32Z

Two questions for @bzbarsky so I can fix and merge this:

In your bugzilla comment you say:

I think restricting [NewObject] to only things that return interface types is just wrong. It should be allowed if the return value is any object type. Specifically, any interface type, "object", a promise, an Error, a DOMException, any buffer source type, or a union of types on which [NewObject] is allowed.

It is not clear, from my perspective, whether "a union of types on which [NewObject] is allowed" means (object_type or object_type) or (object_type or non_object_type) (@annevk needs the latter for "fetch", I think you mean the former).
Do we have to account for null types, especially within unions? See my previous comment.

bzbarsky · 2016-11-07T19:55:45Z

it is not clear, from my perspective, whether "a union of types on which [NewObject] is allowed" means (object_type or object_type) or (object_type or non_object_type)

Good question.

For a return value that doesn't always return an object (i.e. the latter case), it's not clear what [NewObject] would really mean. Or rather, the current definition of [NewObject] as "a reference to a newly created object must always be returned" doesn't make sense in that case, right? Nullable types have the same concern. That makes the given PR not really make much sense, when read literally.

We could make that definition more complex to make it more broadly applicable, of course. But normally [NewObject] functions would be some sort of a "construct an object and return it" function. It's pretty odd to allow such a thing to also return non-objects.

What is the fetch use case here?

tobie · 2016-11-07T20:11:21Z

That makes the given PR not really make much sense, when read literally.

Agreed, my initial commit read: [=union types=] whose [=member types|members=] are [=object types=], which I believe is what you had in mind.

What is the fetch use case here?

I'm not sure. @annevk?

bzbarsky · 2016-11-07T20:16:26Z

my initial commit read: [=union types=] whose [=member types|members=] are [=object types=], which I believe is what you had in mind.

It's what I had in mind, but I'm open to considering the other option, and a more complicated definition of [NewObject], once I understand the use cases.

Note that [SameObject] need not be restricted to the same types as [NewObject]; we can have a [Constant] annotation that makes sense for all types, not just object types.... and I think we should have done that instead of [SameObject].

tobie · 2016-11-07T20:21:04Z

we can have a [Constant] annotation that makes sense for all types, not just object types.... and I think we should have done that instead of [SameObject].

If the issue is just the name, I'm sure we can find something more suitable than [NewObject] to express the opposite of [Constant].

bzbarsky · 2016-11-07T20:26:27Z

Well, the opposite of [Constant] is "yeah, it might change". [NewObject] is not the same thing as the opposite of [Constant] at all. ;)

tobie · 2016-11-07T20:29:30Z

Yeah, I meant something with the same semantics as [NewObject] but whose name would make sense for literals too.

annevk · 2016-11-08T07:22:43Z

Sorry, for Fetch I only need [NewObject] to work for promises. I don't need it to work for strings or nullables. I think I ended up confusing this issue a bit.

#212 (and its corresponding Bugzilla bug) has a proposal for revamping [SameObject]. I agree with @bzbarsky that we don't have to retain parity with [NewObject]. [SameObject] or [Constant] should be its own thing with its own semantics that make sense for it.

tobie · 2016-11-08T15:05:01Z

Sorry, for Fetch I only need [NewObject] to work for promises. I don't need it to work for strings or nullables. I think I ended up confusing this issue a bit.

It's absolutely all your fault. :)

There are currently no use cases for the (non_object or object) construct, so I can just remove that out from the PR, e.g.:

The {{object}} type,
all [=interface types=],
the [=promise type=],
the [=exception types=],
the [=buffer source types=], and
[=union types=] whose [=member types|members=] are [=object types=]
are known as <dfn id="dfn-object-type" export>object types</dfn>.

On the other hand, as @dontcallmedom mentions in #71, The ServiceWorker spec uses a bunch of constructs with a nullable type, e.g.:

[SameObject] readonly attribute (Client or ServiceWorker or MessagePort)? source;

Would something like this work to cover that use case and still make sense given the dfn name?

The {{object}} type,
all [=interface types=],
the [=promise type=],
the [=exception types=],
the [=buffer source types=],
[=union types=] whose [=member types|members=] are [=object types=], and
[=nullable types=] whose [=inner type=] is an [=object type=]
are known as <dfn id="dfn-object-type" export>object types</dfn>.

annevk · 2016-11-08T15:14:55Z

I don't think we should focus on addressing [SameObject] use cases here. I think everyone is coming around that we want to do it differently per the other issues. If we did that, we'd automatically account for nullables and strings and such there I think.

tobie · 2016-11-08T15:29:09Z

Well, my understanding is the only difference between the requirements is [SameObject] wants objects to be nullable.

Given null is always === null, it doesn't bother me that [NewObject] could return the same null twice and thus to treat both [NewObject] and [SameObject] similarly (of course, we'd need to special case the language for the case of null in [NewObject]).

bzbarsky · 2016-11-08T15:29:30Z

Here's a concrete example of why the current [SameObject] thing is silly: Node has various string-or-null-valued attributes (localName, namespaceID) that can never change and we should be able to annotate that. Right now we can't.

annevk · 2016-11-08T15:35:09Z

@tobie do we have a case where a [NewObject]-operation can return null or a string? On the face of it something like that seems rather weird.

tobie · 2016-11-08T16:02:02Z

@bzbarsky wrote:

Here's a concrete example of why the current [SameObject] thing is silly: Node has various string-or-null-valued attributes (localName, namespaceID) that can never change and we should be able to annotate that. Right now we can't.

Oh, OK. So there are requirements I wasn't aware of.

So what's the plan?

Define object types as:

The {{object}} type,
all [=interface types=],
the [=promise type=],
the [=exception types=],
the [=buffer source types=], and
[=union types=] whose [=member types|members=] are [=object types=]
are known as <dfn id="dfn-object-type" export>object types</dfn>.

Make [NewObject] refer to it.
Add a new [Constant] extended attribute that's works on any type and always returns the same reference for objects and the same value otherwise (so [Constant] readonly attribute DOMString tagName; means that if tagName returns "DIV" once, it'll always do so.)
What to do with [SameObject]? Mark it as legacy?

@annevk wrote:

do we have a case where a [NewObject]-operation can return null or a string? On the face of it something like that seems rather weird.

I wasn't aware string was a requirement for [SameObject]. Agreed it's potentially a bit weird for [NewObject] but null doesn't strike me as absurd.

annevk · 2016-11-08T17:08:23Z

Maybe not absurd, but if we have no legit cases… I think we should just remove [SameObject] when we add the improved version and file issues downstream.

tobie · 2016-11-08T17:12:11Z

Maybe not absurd, but if we have no legit cases… I think we should just remove [SameObject] when we add the improved version and file issues downstream.

What's the process for removing something like that? Keep it around the spec and mark it as deprecated? Remove it altogether? How do we easily know what specs to file against? Or should we just get a warning out in Bikeshed and Respec and hope for the best?

annevk · 2016-11-08T18:16:32Z

Just doing it and gradually fixing dependencies seems fine. Browser engineers can prolly grep all IDL files too to see what needs fixing.

bzbarsky · 2016-11-08T19:12:20Z

How do we easily know what specs to file against?

In Gecko's IDL, looks like [SameObject] is used for:

WorkerGlobalScope.caches: https://w3c.github.io/ServiceWorker/#self-caches
SVGElement.dataset: SVG2 spec?
ServiceWorkerGlobalScope.clients/registration: https://w3c.github.io/ServiceWorker/#serviceworkerglobalscope-interface
Window.caches: https://w3c.github.io/ServiceWorker/#self-caches
Response.headers: https://fetch.spec.whatwg.org/#response-class
ServiceWorkerMessageEvent.source: https://w3c.github.io/ServiceWorker/#serviceworkermessageevent-interface
ServiceWorkerContainer.ready: https://w3c.github.io/ServiceWorker/#serviceworkercontainer-interface
Request.headers: https://fetch.spec.whatwg.org/#request-class
PushSubscriptionOptions.applicationServerKey: https://w3c.github.io/push-api/ (note that this one is nullable!)
PresentationReceiver.connectionList: https://w3c.github.io/presentation-api/#interface-presentationreceiver
PresentationConnectionAvailableEvent.connection: https://w3c.github.io/presentation-api/#interface-presentationconnectionavailableevent
Presentation.receiver: https://www.w3.org/TR/presentation-api/#receiving-user-agent (again, nullable!)
Node.childNodes: https://dom.spec.whatwg.org/
Navigator.serviceWorker: https://w3c.github.io/ServiceWorker/#navigator-serviceworker
MediaStreamTrackEvent.track: http://dev.w3.org/2011/webrtc/editor/webrtc.html#mediastreamevent (but note that this stuff apparently got changed around and may no longer exist).
Location.ancestorOrigins: HTML spec, I'd think
FetchEvent.request: https://w3c.github.io/ServiceWorker/#fetchevent-interface
ExtendableMessageEvent.source: https://w3c.github.io/ServiceWorker/#extendablemessageevent (also nullable)
Element.attributes: https://dom.spec.whatwg.org/
DOMQuad.p1/p2/p3/p4/bounds: https://drafts.fxtf.org/geometry/#DOMQuad

There are also some cases of specs using it while Gecko does not (e.g. PushSubscription.options)...

tobie · 2017-03-27T07:57:41Z

This needs to be completely revisited. Closing.

Extend the dfn of object types.

ffedfcb

Update [SameObject] and [NewObject] to rely on it. Fixes whatwg#71 Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605

annevk reviewed Oct 27, 2016

View reviewed changes

All union members don't need to be objects.

e3b6245

domenic assigned bzbarsky and heycam Nov 3, 2016

tobie assigned annevk and unassigned bzbarsky and heycam Nov 7, 2016

tobie unassigned annevk Nov 9, 2016

annevk mentioned this pull request Nov 9, 2016

Make [SameObject] beneficial #212

Open

tobie closed this Mar 27, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Extend the dfn of object types. #211

Extend the dfn of object types. #211

tobie commented Oct 27, 2016 •

edited

Loading

annevk Oct 27, 2016

tobie Oct 27, 2016

tobie commented Oct 27, 2016

domenic commented Oct 27, 2016

tobie commented Nov 7, 2016 •

edited

Loading

bzbarsky commented Nov 7, 2016

tobie commented Nov 7, 2016

bzbarsky commented Nov 7, 2016

tobie commented Nov 7, 2016

bzbarsky commented Nov 7, 2016

tobie commented Nov 7, 2016

annevk commented Nov 8, 2016

tobie commented Nov 8, 2016

annevk commented Nov 8, 2016

tobie commented Nov 8, 2016

bzbarsky commented Nov 8, 2016

annevk commented Nov 8, 2016

tobie commented Nov 8, 2016

annevk commented Nov 8, 2016

tobie commented Nov 8, 2016

annevk commented Nov 8, 2016

bzbarsky commented Nov 8, 2016

tobie commented Mar 27, 2017

Extend the dfn of object types. #211

Extend the dfn of object types. #211

Conversation

tobie commented Oct 27, 2016 • edited Loading

annevk Oct 27, 2016

Choose a reason for hiding this comment

tobie Oct 27, 2016

Choose a reason for hiding this comment

tobie commented Oct 27, 2016

domenic commented Oct 27, 2016

tobie commented Nov 7, 2016 • edited Loading

bzbarsky commented Nov 7, 2016

tobie commented Nov 7, 2016

bzbarsky commented Nov 7, 2016

tobie commented Nov 7, 2016

bzbarsky commented Nov 7, 2016

tobie commented Nov 7, 2016

annevk commented Nov 8, 2016

tobie commented Nov 8, 2016

annevk commented Nov 8, 2016

tobie commented Nov 8, 2016

bzbarsky commented Nov 8, 2016

annevk commented Nov 8, 2016

tobie commented Nov 8, 2016

annevk commented Nov 8, 2016

tobie commented Nov 8, 2016

annevk commented Nov 8, 2016

bzbarsky commented Nov 8, 2016

tobie commented Mar 27, 2017

tobie commented Oct 27, 2016 •

edited

Loading

tobie commented Nov 7, 2016 •

edited

Loading