On Oct 8, 2012, at 1:21 PM, Brendan Eich wrote: > Tom Van Cutsem wrote: >> 2012/10/8 Allen Wirfs-Brock <[email protected] >> <mailto:[email protected]>> >> >> >> Internal abstraction operations (helper functions) are just >> editorial devices that reduce the need to duplicate (and perhaps >> introducing errors) specification steps. If it makes sense I'll >> use one in specifying these traps, but it doesn't make a normative >> difference to the specification. >> >> >> I understand. That's why I think it's perfectly OK to use helpers such as >> GetPropertyKeys internally, but to not expose them via the Proxy API. With >> my above suggestion, we get a clean spec/trap interface and at the same time >> less redundancy in the spec. > > Just to make sure, a couple more points to get agreement on: > > * Spec internal helper structure matters, both in terms of aesthetics and > best-practices from software engineering, so people will opine on it from > time to time and it's fair game for comment.
Oh definitely, everything is fair game for comment and discussion. Often both in the spec. and the real world it is a judgement call as to whether or not adding a layer of prodedural abstraction is a beneficial or not. In particular, an extra layer of abstraction doesn't always improve readability and the probability of correct implementation. > > * Implementors do look to match the spec where optimization is not critical, > even on internal helpers. This is not just spec-following, of course -- the > logic driving shared helpers being factored out applies to implementations as > well as spec. Or really, spec is just a paper implementation. Yes, but it isn't required and as you say, for performance critical functionality directly following the structure of the spec. is much less likely. BTW, an issue that I have seen in some ES test is an implicit assumption that the implementation factoring and abstraction layering necessarily follows that used by the specification. Just because the spec. uses procedural abstraction to define some functionality doesn't mean that the functionality can be verify by exercising only one of multiple features that depend upon it. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
