value objects

Tab Atkins Jr. jackalmage at
Mon Mar 26 20:48:49 PDT 2012

On Mon, Mar 26, 2012 at 6:23 PM, Allen Wirfs-Brock
<allen at> wrote:
> As a followup, I've written a strawman[1] that explains how we could specify
> and implement operator overloading that supports an open-ended set of value
> types.  I look at this as an adjunct to Dave's proposal that suggests that
> the coercion/promotion rules  should be pushed out of the actual operator
> semantics and placed into an extensible set of methods.
> [1]

Python (and others, like my own slow homebrew version of operator
overloading in JS) provide all binary operations as 'foo' and 'rfoo'.
If the lvalue overloads 'foo', that's used.  Otherwise, if the rvalue
overloads 'rfoo', that's used.

This makes it easier to define symmetric operations without having to
monkeypatch another class.  It's limited, of course, since you have to
ensure that the lval doesn't preempt you with its own overload that
doesn't understand how to use you.  In the future when we have guards
(and, presumably, guard-based overloads), this limitation can be
avoided as well.


More information about the es-discuss mailing list