domenic at domenicdenicola.com (2013-09-09T01:47:48.988Z)
Filip Pizlo <mailto:fpizlo at apple.com> September 4, 2013 4:45 PM > What about being consistently odd? To me, 'struct.f' means allocating > a new [sic] array buffer view object. That new object thus has all of > the features you'd expect from a new object: it won't have custom > properties, it will have some default prototype, and it will not be == > to any other object. Hence if you say "struct.f.foo = 42", then > "struct.f.foo" will subsequently return undefined. No big deal - it > was a new object. In WebIDL, IIRC, this is considered bad style. You are supposed to use a method, not an IDL attribute (getter), when returning a fresh object each time. Anne can vouch, cc'ing him. I'm not saying we must match WebIDL good style -- doing so would mean binary data does not support interior extractions via struct.foo.bar -- rather something awful such as struct.foo().bar, which won't fly. But it seems worth considering that the "odd" or "bad style" design decision is upstream of our petty difference over expandos. > >> But "lost expandos" due to loss of identity are an especially nasty >> kind of bug to find. > > I'm actually curious - are you aware of such bugs, and what do they > actually look like? Search for "disappearing expando" on the web.
> Filip Pizlo <mailto:fpizlo at apple.com> > September 4, 2013 4:45 PM > > On Sep 4, 2013, at 2:41 PM, Brendan Eich <brendan at mozilla.com > <mailto:brendan at mozilla.com>> wrote: > >> Filip Pizlo wrote: >>> I agree that both of these aspects of binary data are quirky. My >>> observation is that prohibiting custom properties doesn't fix the >>> underlying issue. >>> >>> [snip] >>>> var MyArray = new ArrayType(...); >>>> var MyStruct = new ArrayType({f: MyArray}); >>>> var struct = new MyStruct(...); >>>> var array1 = struct.f; >>>> var array2 = struct.f; >>>> >>>> then `array1` and `array2` would have disjoint sets of extensible >>>> properties.] >>> >>> Yes, they would. But even if they didn't, then array1 != array2, >>> which is equally odd. >> >> Both adds up to two, not one, so the counterargument is odd beats >> odder, and prohibiting expandos keeps the oddness down to == and >> nothing else. > > What about being consistently odd? To me, 'struct.f' means allocating > a new [sic] array buffer view object. That new object thus has all of > the features you'd expect from a new object: it won't have custom > properties, it will have some default prototype, and it will not be == > to any other object. Hence if you say "struct.f.foo = 42", then > "struct.f.foo" will subsequently return undefined. No big deal - it > was a new object. In WebIDL, IIRC, this is considered bad style. You are supposed to use a method, not an IDL attribute (getter), when returning a fresh object each time. Anne can vouch, cc'ing him. I'm not saying we must match WebIDL good style -- doing so would mean binary data does not support interior extractions via struct.foo.bar -- rather something awful such as struct.foo().bar, which won't fly. But it seems worth considering that the "odd" or "bad style" design decision is upstream of our petty difference over expandos. > >> But "lost expandos" due to loss of identity are an especially nasty >> kind of bug to find. > > I'm actually curious - are you aware of such bugs, and what do they > actually look like? Search for "disappearing expando" on the web. /be