Objects that can stringify in multiple ways

# Anne van Kesteren (2 months ago)

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?

(I feel like I've asked this question before somewhere, but I can't find it.)

Contact us to advertise here
# Tab Atkins Jr. (2 months ago)

On Wed, Mar 15, 2017 at 3:25 AM, Anne van Kesteren annevk@annevk.nl wrote:

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?

(I feel like I've asked this question before somewhere, but I can't find it.)

If you can come up with reasonable arguments differentiating the different ways (probably named, in an options object?), overloading toString() is reasonable. Number.toString() works well this way, because the "different ways of printing" are just different bases, covered by a single simple argument integer argument.

But if the different ways are relatively different, I think it's better to instead just add different methods to the prototype, and bless one of them as the "default" way.

~TJ

# Anne van Kesteren (2 months ago)

On Wed, Mar 15, 2017 at 7:29 PM, Tab Atkins Jr. jackalmage@gmail.com wrote:

If you can come up with reasonable arguments differentiating the different ways (probably named, in an options object?), overloading toString() is reasonable. Number.toString() works well this way, because the "different ways of printing" are just different bases, covered by a single simple argument integer argument.

But if the different ways are relatively different, I think it's better to instead just add different methods to the prototype, and bless one of them as the "default" way.

For URLs (and hosts, which might end up as URLHost) the main difference we might want to expose is ASCII vs Unicode display. We could indeed have

obj.toString({as: "unicode"})

but this seems only better than

obj.unicode()

if it brings some other benefits (in the future?) around stringification as otherwise it's just a pretty verbose way of expressing the same semantic.

I'm probably overthinking it.

# Domenic Denicola (2 months ago)

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.

# Travis Leithead (2 months ago)

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 (2 months ago)

+1 to Travis point...

# Anne van Kesteren (2 months ago)

On Thu, Mar 16, 2017 at 1:04 AM, 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.

That's a good point.

Domenic's first-class domain concept resonates as well.

I guess the other thing to consider with URLs (not hosts) is that the Unicode conversion might be lossy, due to paths/queries/fragments not always using valid UTF-8 percent-encoded bytes.

I guess we'll go with unicode().

Want more features?

Request early access to our private beta of readable email premium.