> But this should be a usable ocap language, not gratuitously lacking any > features from full Harmony that could have been provided safely, merely > because Harmony unnecessarily chose to provide them in an insecurable manner.
That's a bit hyperbolic; no one's proposing an "insecurable" system. Our proposal strives to let simplicity and conciseness outweigh isolation in the common case, and yet still make isolation possible. Within that isolation there should plenty of room for building secure subsets. For example, much of the first-class module strawmen have attempted to build off a secure eval; simple modules + isolation would essentially provide that. (If that's not obvious, it's entirely our fault, since we haven't written up anything on isolation yet.) > In particular, it would be bizarre for Harmony to have two distinct and > disjoint module systems, A and B, simply because module system A was > unnecessarily inappropriate for the ocap subset. Well, they can be addressing different concerns, especially when they have pretty dramatic differences. But more to the point, starting with the goal of supporting all the features needed for an objcap subset is needlessly tying our hands behind our backs. Nobody's trying to jeopardize objcap subsetting, but we also can't let objcap goals eclipse others. Dave _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
