W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2017

RE: Objects that can stringify in multiple ways

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 16 Mar 2017 00:04:30 +0000
To: Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, public-script-coord <public-script-coord@w3.org>
Message-ID: <BN6PR03MB3026177DF7FAE08F3CFED108F8260@BN6PR03MB3026.namprd03.prod.outlook.com>
Also consider discoverability: it'll be much easier to feature-detect as a separate property than a parameter.

-----Original Message-----
From: Domenic Denicola [mailto:d@domenic.me] 
Sent: Wednesday, March 15, 2017 1:52 PM
To: Anne van Kesteren <annevk@annevk.nl>; public-script-coord <public-script-coord@w3.org>
Subject: RE: Objects that can stringify in multiple ways

From: Anne van Kesteren [mailto:annevk@annevk.nl] 

> URLs represent a class of objects that can be stringified in multiple ways, each of which is useful. The JavaScript standard library deals with this situation by making toString() take an argument, as seen with the Number class.
> Is that the precedent to follow or is having some other way of accessing such string values reasonable too?

IMO both are reasonable. I guess my gut feeling is that adding an option to toString makes sense when this is a very secondary thing that most code won't use (like non-base-10 serializations for numbers). Whereas adding a separate method makes sense when that particular serialization is a first-class domain concept.

I'd also say that if you were to add an option to toString, ideally it'd be a single enum or other parameter, instead of an options bag. If your serialization configuration is complex enough that an options bag has to get involved them probably splitting into separate methods would be better.
Received on Thursday, 16 March 2017 00:05:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC