On Thu, May 27, 2010 at 5:36 PM, Brendan Eich <[email protected]> wrote:
> On May 27, 2010, at 5:21 PM, Sam Ruby wrote: > > a[0] = a[1] could also be made to work with sealed objects reflecting >>> the struct elements of the arrays. The right-hand side reifies or finds >>> the memoized object reflecting a[1], the packed struct. The assignment >>> to a[0] then reads property values from the object (fat ugly numbers!) >>> and writes into the packed struct at a[0] according to the schema. >>> >> >> ... and the value of a[0] === a[1] is? >> > > With any kind of mutable object reflecting the packed struct, the answer > will be false unless we have value types. See > > http://wiki.ecmascript.org/doku.php?id=strawman:value_types#hard_cases > > search for ===. > > Value types were conceived of as shallowly frozen, but we could try to > relax that. > > > > So it still seems to me one could avoid equating value types and these >>> schema structs. They are distinct proposals, but you could tie them >>> together. I think that would be a mistake at this point, especially >>> since WebGL folks have no need for operators and literals (as far as I >>> know). >>> >> >> It is not a matter of whether they "need" === operators to be defined, but >> rather a matter of defining what the value of === operators is to be. >> >> Nor, am I suggesting that === be overloadable. >> >> I am suggesting that if a[0]===a[1] is to be true, and one can assume that >> a[n] is a series of octets, then we are talking about strncmp like behavior. >> And if we can assume strncmp, then I see no reason to preclude >> implementations from using strncpy. >> > > If you want this, whether === is overloadable, and WebGL (lots of folks, > let's say) want structs in the array to be mutable, then we run into the > conflict recorded in the wiki. > > ''Jason: === must be overloadable. Mark: no, Value Types mean === can do a > recursive, cycle-tolerant structural comparison. Jason: not convinced that > complexity is warranted. > ... > > Decision logic: > > if (=== is overloadable) { > The need for egal goes up; > if (egal is added (it is not overloadable)) > {0, -0} and NaN issues go away; > } else { > The need for egal goes down, > because === is well-defined as structural recursive etc. comparison; > } > Value Type means “shallow frozen”.'' > > > > Say we add egal, so one can tell the difference between a[0] and a[1] even > if they happen to contain the same bits, because that difference might > matter due to one of them being mutated to have different bits. Then do the > objections to unfrozen value types go away? Cc'ing Mark. > *Given* that we have added egal as a separate reliable non-overloadable operator, I would then have less objection to allowing === to be overloaded. But should we add egal? I see this as much like the function vs lambda question. I long for a true lambda, as a clean alternative to function. I long for egal, as a clean alternative to ===. However, the argument against lambda is at least as valid as an argument against egal: The functionality represented by lambda or egal is already closely approximated by an existing construct in the language. Adding another similar but subtly different construct to the language adds more confusion and complexity than utility. Imagine how much harder it would be to teach beginning programmers not just about function vs constructors vs methods, but also about these vs lambda. Likewise, imagine teaching beginning programmer not just about === vs ==, but about both of these vs egal. The downside of egal by this argument is just as bad as the downside of lambda. The upside of lambda is much greater than the upside of egal, since === is a much less broken egal than function is a broken lambda. That said, I'm not sure I understand why this should gate anything in this thread. Value types should be frozen (shallowly immutable) regardless, or other things break, e.g., they could no longer be transparently passed by copy. C# got this wrong, and paid a semantic complexity price we must avoid. Non-frozen structs should not be value types. Frozen structs could be value types, or could be wrapped in value types or something. Given these constraints on mutability and value types, I don't see that it matters whether the reliable comparison is named === or egal. Btw, please no one suggest that egal be spelled "====". Thanks. > > > /be > > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
