Make functions on the built-in object non-writable.

src/messages.js

Index: src/messages.js
diff --git a/src/messages.js b/src/messages.js
index cbbb70eb1a8e37392676cc8258cdfb17afacd89b..0a00d356246a52a0e7ae62e924f921ba6e8f959f 100644
--- a/src/messages.js
+++ b/src/messages.js
@@ -29,17 +29,17 @@
 // -------------------------------------------------------------------
 //
 // Matches Script::Type from objects.h
-var TYPE_NATIVE = 0;
-var TYPE_EXTENSION = 1;
-var TYPE_NORMAL = 2;
+const TYPE_NATIVE = 0;

[Kevin Millikin (Chromium), 2011/09/01 07:58:24]

Is this change necessary?

If it is, can you instead define them as const macros in macros.py?  Our
implementation of const is slower than var, prevents optimization, and the
semantics of global const is somewhat up in the air and not something we should
rely on.

[Lasse Reichstein, 2011/09/01 09:26:58]

Nothing here is *necessary*, but it's an attempt to lock down the builtins
object to prevent tampering in case someone gets a hold of it (i.e., security in
depth).
Making them macros.py-macros is a better idea.

I do need some constants that can't be moved to macros.py, though (two of the
vars below have been changed in another CL). Is there a better way to make them
const than using "const" declarations? E.g., using %SetProperty(builtins, ...) ?

[Kevin Millikin (Chromium), 2011/09/01 09:53:14]

I think something like that, even if you have to implement a custom function,
might be better.

If we match Safari's behavior, we'll have surprising stuff like consts whose
value can change (a global const declaration overrides a pre-existing one).

+const TYPE_EXTENSION = 1;
+const TYPE_NORMAL = 2;
 
 // Matches Script::CompilationType from objects.h
-var COMPILATION_TYPE_HOST = 0;
-var COMPILATION_TYPE_EVAL = 1;
-var COMPILATION_TYPE_JSON = 2;
+const COMPILATION_TYPE_HOST = 0;
+const COMPILATION_TYPE_EVAL = 1;
+const COMPILATION_TYPE_JSON = 2;
 
 // Matches Messages::kNoLineNumberInfo from v8.h
-var kNoLineNumberInfo = 0;
+const kNoLineNumberInfo = 0;
 
 // If this object gets passed to an error constructor the error will
 // get an accessor for .message that constructs a descriptive error
@@ -1007,7 +1007,7 @@ function DefineError(f) {
   // user code.
   var name = f.name;
   %SetProperty(global, name, f, DONT_ENUM);
-  this['$' + name] = f;
+  %SetProperty(this, '$' + name, f, DONT_ENUM | DONT_DELETE | READ_ONLY);
   // Configure the error function.
   if (name == 'Error') {
     // The prototype of the Error object must itself be an error.
@@ -1024,7 +1024,7 @@ function DefineError(f) {
   %FunctionSetInstanceClassName(f, 'Error');
   %SetProperty(f.prototype, 'constructor', f, DONT_ENUM);
   // The name property on the prototype of error objects is not
-  // specified as being read-one and dont-delete. However, allowing
+  // specified as being read-only and dont-delete. However, allowing
   // overwriting allows leaks of error objects between script blocks
   // in the same context in a browser setting. Therefore we fix the
   // name.