Question

Is there a way to work around naming conflicts between Script# and other scripts loaded on a page? For example, we’ve built a component using Script# that will run on an existing site we don’t have the ability to change (beyond the addition of our scripts). However, another script on the site also defines some of the same types and extensions (such as Boolean.parse) that cause all kinds of chaos.

Answer 1

Script# is a pretty bad citizen (as of the current 0.7.4) in the world of JavaScript library compatibility. Its mscorlib.js modifies the prototypes of global classes such as Object, Boolean, Date, Error, Number, String and Array. The latter is particularly galling given the well-known “for…in” JavaScript quirk whereby prototype properties are enumerated along with all local object properties, forcing the use of object.hasOwnProperty to guard your iteration.

In my assessment, Script# essentially assumes that it is either A) the only library in use, or B) the only library that will attempt to mess with global prototypes. Given Script#’s formally-maintained support for jQuery, B seems more likely.

To deal with your particular situation will take some hard work. It is possible to write Script# code without relying on any mscorlib functionality, and then run/ship your code without that file. Since you can’t modify the other code, that’s likely the only way here (I wouldn’t want to try to rewrite mscorlib, and don’t know if it’s possible given the not-fully-open-source composition of Script#). It takes some discipline and care to avoid using mscorlib – you can’t/shouldn’t actually remove mscorlib as a formal project dependency (due to the compiler), you just have to avoid using it.