archives

« Bugzilla Issues Index

#1098 — ToPrimitive's PreferredType parameter

• bug_id: 1098
• creation_ts: 2012-11-29 11:27:00 -0800
• short_desc: ToPrimitive's PreferredType parameter
• delta_ts: 2015-02-18 18:21:01 -0800
• product: Draft for 7th Edition
• component: Deferred from 6th edition
• version: unspecified
• rep_platform: All
• op_sys: All
• bug_status: CONFIRMED
• priority: Normal
• bug_severity: enhancement
• everconfirmed: true
• reporter: Michael Dyck
• assigned_to: Allen Wirfs-Brock

---

• commentid: 2906
• comment_count: 0
• who: Michael Dyck
• bug_when: 2012-11-29 11:27:42 -0800

The nature of ToPrimitive's PreferredType parameter is odd. It's described as "an optional hint", and its values are denoted (in the ToPrimitive algorithm, and in invocations of it) as "hint Number" and "hint String".

You could eliminate this ad-hoc-ness by using the same convention as @@ToPrimitive and OrdinaryToPrimitive. I.e., change:
hint Number to "number"
and
hint String to "string"

(If you also renamed 'PreferredType' as 'hint', you could delete steps 2 and 3 of the ToPrimitive algorithm.)

---

• commentid: 2937
• comment_count: 1
• who: Allen Wirfs-Brock
• bug_when: 2012-12-01 09:53:05 -0800

I have mixed feelings about this approach. Just using strings would simplify things. However, the hint is strictly a specification artifact (at this level). It seems like good hygiene to avoid using ECMAScript language values as such specification meta values.

I realize the historically the spec. has been very inconsistent in the application of this "rule" and I suspect we will never get away from using true, false, and maybe undefined as both language and spec meta values.

So, I'm still not really sure which way to go on this.