From 1d34f11a873d640ac2611bcabee5875a27f43a2e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=BF=B7=E6=B8=A1?= Date: Wed, 28 Aug 2019 21:51:36 +0800 Subject: [PATCH] doc: fix list style (#2823) --- website/style_guide.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/website/style_guide.md b/website/style_guide.md index d1eff835..e701ac0b 100644 --- a/website/style_guide.md +++ b/website/style_guide.md @@ -54,17 +54,22 @@ When designing function interfaces, stick to the following rules. there is only one, and it seems inconceivable that we would add more optional parameters in the future. + + + 3. The 'options' argument is the only argument that is a regular 'Object'. Other arguments can be objects, but they must be distinguishable from a 'plain' Object runtime, by having either: - - a distinguishing prototype (e.g. `Array`, `Map`, `Date`, `class MyThing`) - - a well-known symbol property (e.g. an iterable with `Symbol.iterator`). + - a distinguishing prototype (e.g. `Array`, `Map`, `Date`, `class MyThing`) + - a well-known symbol property (e.g. an iterable with `Symbol.iterator`). This allows the API to evolve in a backwards compatible way, even when the position of the options object changes. + + ```ts // BAD: optional parameters not part of options object. (#2) export function resolve( -- GitLab