On Jun 30, 2008, at 9:18 PM, Allen Wirfs-Brock wrote: > This is an interesting exercise because I'm trying to find a path > that is tolerable for a number of different individuals who seem to > have different and sometimes seemingly contradictory goals:
That is a warning sign. Adding more switches won't make everyone happy, and it will make a nightmare of a testing matrix, within a single implementation and among implementations. > Brendan: I don't see these subsets as "profiles", if a profile is a > subset of the language that an implementation is allowed to limit > itself to supporting. That's my point -- profiled standards may pretend that implementations can pick and choose among profiles to support, but on the web's winner-take-all network effects force every implementation to agree on the full standard. Users choosing subsets from full implementations do not simplify the implementation space, and too many subsets make a mess of the spec and its implementation. What users -- as opposed to es3.x-discuss participants who may have different and seemingly contradictory goals -- have asked for these subsets? > Maciej: The conditions for violating the "cautious" will be part of > the 3.1 specification. I actually don't understand your > interoperability concerns. The complexity of multiple subset modes, or whatever they are, will increase the odds of interoperation bugs in the wild. > There is only one language, the full language since every valid > "cautious" subset program (or any other subset, for that matter) > must execute identically in the full language (except for possibly > fewer error exceptions). The "use subset" directive is a statement > of voluntary self constraint on the part of the programmer. Of > course, there is no particular reason for an implementation to > accept the programmer's assertion regarding their self constraint. > So the directive also acts as authorization from the programmer to > the implementation that it may reject or restrict a program unit > according to a subset definition. A wise programmer will test any > such constrained program on an implementation that actually > enforces the subset limitations. They would also want to test it > without the limitations. There goes the QA budget :-/. This is a recipe for testing costs driving everyone away from all but one mode, probably the one that's web-compatible. > Regarding whether or not ES4 is in agreement...Before anybody can > agree or not to anything, there first has to be a proposal on the > table to consider. That's what I'm trying to put on the table. How many proposed subsets or modes are there? > Mark: To the degree you are agreeing with Maciej about > interoperability concerns, I've already addressed that. I'm trying > to trade-off your safety objective against compatibility issues and > what I see as a overall lack of consensus about what is required or > alternatively tolerated in a "strict mode". Making enforcement > optional seem to increase the possible space of compromise. > > Personally, I would be perfectly happy to require support for "use > subset cautious" but I'm concerned that it could make it harder to > get the consensus we need. These statements are grounds for leaving out any subset modes from a standard that you hope to finish this calendar year. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
