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

Re: Objects that can stringify in multiple ways

From: Shane McCarron <shane@spec-ops.io>
Date: Wed, 15 Mar 2017 20:01:55 -0500
Message-ID: <CAJdbnOD48fqT0O7NYwSTVj=d7xLsKYRwYSrmeveBPEVy9HgDpQ@mail.gmail.com>
To: Travis Leithead <travis.leithead@microsoft.com>
Cc: Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, public-script-coord <public-script-coord@w3.org>
+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
Received on Thursday, 16 March 2017 01:02:56 UTC

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