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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
