- From: Marcos Caceres <mcaceres@mozilla.com>
- Date: Fri, 5 Oct 2018 12:07:19 +1000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "spec-prod@w3.org Prod" <spec-prod@w3.org>, Sid Vishnoi <sidvishnoi8@gmail.com>
Hi Tab, > On Oct 5, 2018, at 4:55 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > > Hm, any particular reason you diverged from Bikeshed's syntax so > significantly? All of these are the exact same syntax in Bikeshed: > > * {{PaymentRequest/id}} > * {{PaymentRequest/show()}} > * {{PayerErrors/"phone"}} (or just {{PayerErrors/phone}}, both work). We wanted something that was more “WYSIWYG”. Otherwise, for instance, it’s unclear what {{PayerErrors/phone}} is (an attribute or a member?) without having to open up the whole spec and having a look. Thus, this is helpful (for me) when I’m reviewing PRs, because it’s immediately clear that PayerErrors[“phone”] is talking about a dictionary member. But I agree that it means that Editors need to know the for Dictionary types, they need to write things `Like[“This”]` (but see below… Foo.bar also works for dictionaries). > (Because all of them, when qualified by the interface/etc they belong > to, occupy shared namespaces, so there's no need to further > distinguish them in syntax.) I agree - but they way ReSpec works is a little different at the moment: We do inline processing of "{{{ }}}” things before we do IDL parsing (at least, today). That means we don’t have an IDL AST at that point on which to do the lookups. We will eventually change this, but right now, this works well for most common cases. > It feels like adding more specific syntaxes to these would make it > slightly harder to remember? I don’t disagree. But it lightens the cognitive load when doing reviews - because “what you see is what you get”: attribute, method(), [“member”], and [[iternal_slot]]. Irrespective {{PayerErrors/phone}} will be converted into markup that renders as `PayerErrors[“phone”]`, so why not just allow it? > Are the syntaxes specific to the type > there - could I write {{{ PayerErrors.phone }}}, like JS would allow, > or does that try to indicate an IDL attribute instead? Yes, that works too, as it doesn’t yet know how to distinguish IDL container types. If we eventually make this a bit smarter, we will automatically convert {{{ PayerErrors.phone }}} to output `PayerErrors[“phone”]` and link/markup everything correctly.
Received on Friday, 5 October 2018 02:07:50 UTC