Re: Objects that can stringify in multiple ways

+1 to Travis point...

On Wed, Mar 15, 2017 at 7:04 PM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

> 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.
>



-- 
Shane McCarron
Projects Manager, Spec-Ops