Comment #2 on issue 1878 by erights: Refactor repairES5
http://code.google.com/p/google-caja/issues/detail?id=1878
I think this is a good plan. And I like the "more radical" idea as well.
But the whole thing makes we wonder if perhaps we've gotten the overall
flow of SES initialization inverted. Perhaps the multi-phase
test-and-repair framework currently in repairES5 should be in charge, and
all parts of turning a JS platform into a SES platform be driven by
test-and-repair records within phases of that?
The overall flow might be to load in abstraction-level order from bottom to
top (e.g., console/logger, es5, weakmaps, ses, caja), where each does not
do any repairs to the platform at load time (as in your "more radical") but
does patch the list of phases of tests-and-repairs to be done. Perhaps this
would also subsume acceptableProblems?
Only once all levels of abstraction have patched this list is the
test-and-repair framework run. Since the final client determined the
criteria for success, iff the framework completes successfully, we assume
the final client is satisfied.
Does this sound plausible?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
