Maciej Stachowiak wrote: > I think there are two possible perspectives on what constitutes > "magnify[ing] the problem" or "widening the gap" > > A) Any new kind of requirement for implementations of object interfaces > that can't be implemented in pure ECMAScript expands the scope of the > problem. > B) Any new interface that isn't implementable in ECMAScript widens the > gap, even if it is for a reason that also applies to legacy
My view is firmly B, for the reasons given below. > My view is A. That's why I pointed to legacy interfaces - if the > construct can't go away from APIs in general, but we wish to implement > all APIs in ECMAScript, then ultimately it is ECMAScript that must > change, so using the same construct again doesn't create a new problem. Yes it does: - In many cases, APIs are partially redundant, in such a way that developers can choose to avoid some of the legacy interfaces without any significant loss of functionality. By doing so, they can avoid the problems caused by clashes between names defined in HTML, and names of ECMAScript methods. If new APIs also use catch-alls, they are less likely to be able to do this. - The potential name clashes created by catch-alls also create a forward compatibility issue: if a new method is added to an interface, it might clash with names used in existing HTML content. In the case of legacy interfaces, it is less likely that we want to add new methods to them, and so this forward compatibility issue is less of a problem. - Implementors of subsets in which the DOM APIs are "tamed" for security reasons can choose not to implement some APIs that are problematic for them to support; but if new APIs are equally problematic, they will be unable to provide access to that functionality. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
