Discuss
  • Value types page started

Value types page started

# Brendan Eich (16 years ago)

Value types would be objects that behave like primitives such as
number and string: they are immutable or appear to be, so can be
memoized and compared freely without object identity breaking value
identity (in general; decimal cohort issues notwithstanding).

The Ecma TC39 committee is in favor of exploring adding value types to
allow library authors to implement types such as Decimal, Rational,
Complex, Quaternion, RGBColor, etc. In order to be usable, value types
must "overload", really dispatch from, operator syntax; they also need
to extend literal syntax (e.g. 1.1m for decimal 1.1).

I'm mailing to let folks know about a new wiki page. It's not a proper
strawman proposal yet, alas -- it's my notes from an ad-hoc meeting
last October. But it will become a strawman with enough work,
including valuable feedback from es-discuss.

Here's the wiki link:

strawman:value_types

The issues raised include dispatch design, literal syntax, whether the
built-in primitives can or should be recast as value types, and which
operators are overloadable. Of course, this is an incomplete list of
open issues.

It references (via hyperlinks) thread-head messages on es-discuss with
subjects containing "Operator overloading":

esdiscuss/2009-January/008535
(Mark Miller's double-dispatch proposal)

esdiscuss/2009-June/009603
(Christian Hansen's pretty-much-multimethods-but-with-prototype- mutation counterproposal)

esdiscuss/2009-October/010068
(Jason Orendorff's post about what should be overloadable)

The meeting we had last October was productive, but I'm sorry to say
we didn't have followup meetings since then. But we should, and I'll
help keep the list and wiki updated. So please feel free to reply to
this message if you have something to add. Thanks,

# Mike Samuel (16 years ago)

This would be hugely useful for string interpolation since it would let structured interpolation results transparently behave as strings in many respects.

2010/1/28 Brendan Eich <brendan at mozilla.com>