Operator overloading revisited

[Brendan Eich]

On Jul 1, 2009, at 8:14 AM, Christian Plesner Hansen wrote:

>> This cuts both ways. A multimethod reifies that "global" (lexically  
>> scoped,
>> rather) cache.
>
> Sure, I'm not saying it's unique to my proposal.  I mention it because
> it's an important aspect to keep in mind when considering the cost of
> implementing it in practice.

All of us optimizing JS VM hackers agree, you will have no failure to  
object to over-specification that deoptimizes or rules out important  
optimizations. But the spec should not overspecify in favor of a  
particular optimization either, since what is observable other than  
performance won't differ between the overspecified standard and a  
hypothetical "just right" spec.

Of course getting it "just right" is hard.


>> Sorry, I kept typing "asymmetric" when I meant "symmetric". Tired
>> here (new baby at home :-)).
>
> Congratulations!  And congratulations on firefox 3.5 too by the way!

Thanks. Helps to keep things in perspective ;-).


> I'm all for internal properties rather than "this+" and "+this".

How about an alternative spec that does not preclude hidden class  
optimizations based on + overloadings whether by multimethods or "this 
+"/"+this"?

I suppose we can't defer the "type" issue, though...


> Relying on a connection between constructor functions and instances is
> fragile, as I mentioned in a previous message to Mark about
> instanceof.  You can make changes to a constructor function that is
> not reflected in existing instances.

Constructor properties don't show up in instances, so I'm not sure why  
this is a problem.


> You can make changes both to
> instances and constructors that disconnect the two completely.

Yes, with extensions such as writable __proto__ -- but that's  
something we are trying to get rid of.

Likewise, for user-defined function foo, foo.prototype is writable --  
but not so for built-in constructor functions, and not so for classes  
as sugar (more below).

Point so far is not to disagree but to cite cases showing a mix of  
higher- and lower-integrity connections between constructors and their  
prototypes.


> Constructor functions are implementation types (as opposed to
> interface or behavior types) which is inherently problematic.  I
> wouldn't make this weak connection the cornerstone of operator
> dispatch.

I suppose Object.freeze could be seen as a "fix" here, but it is  
advisory -- therefore not used when most needed.

The original "classes as sugar" sketch Mark did to general agreement  
at Oslo included freezing the class object (constructor function)  
*and* bind the class name as a const (neither writable nor  
configurable in the binding object or frame).

So a higher-integrity "fix" would be to make classes as proposed for  
Harmony (details still in flux, I think) the cornerstone for operator  
dispatch. I think this is the plan for "value types", based on  
discussion at the last TC39 meeting. Mark will let us know if he  
disagrees.


> The connection between prototypes and instances is a much more direct
> one.  If you change a prototype that change is reflected in the
> instances (modulo shadowing).  If I want my type B to have all the
> same behavior as A I can mix all the methods of A into B's prototype
> and I will in effect have made B a subtype of A.  If operators reside
> in A's prototype, in whatever form, I can do the same for operators.

You could, but your proposal nicely avoided noisy ".prototype"  
expressions all over, as Allen suggested in reply.

Adding Complex, Decimal, Rational, Point, etc. for most users implies,  
nay cries out for being able to use these names without having to  
suffix them with ".prototype". If the binding of the constructor name  
in its object or frame *and* the binding of its 'prototype' property  
are locked down due to how classes as sugar work, then we should be  
able to rely on the constructor / prototype relationship.


> Whether or not A's '+' operator uses 'this', it's still a part of A's
> behavior and the most consistent place to put it is where A's other
> behavior is, its prototype.

Could be, or one could use an optimized multimethod matrix, or some  
other implementation approach. Again I do not see why the spec should  
dictate observable prototype properties, internal or otherwise. If it  
just uses this model but keeps it concealed, then I'm ok with it  
provided we don't close the door on multimethods prematurely.

If we want multimethods, then we might prefer the spec to go a  
different direction and avoid internal "this+"/"+this", etc.

Not sure this helps get a operators (and only operators) proposal  
together. Good discussion, though!

/be