Все знают, что JavaScript - динамический язык, что несет за собой некоторые особенности, например, отсутствие констант. Правильнее было бы сказать, что отсутствие констант - это проблема не самого JavaScript, а браузеров. 

Согласно спецификации ECMAScript 5th Edition, ECMA Script (для простоты понимания и удобства буду использовать термин JavaScript) у объекта Object должен быть метод freeze, который принимает объект и создает на его основе новый неизменяемый (inmutable) объект, у которого все свойства становятся read only и пропадает возможность удалить и/или изменять свойства объекта.

Синтаксис очень простой: Object.freeze(obj);

Для проверки, является ли объект замороженным, существует метод Object.isFrozen(obj).

Пример небольшого кода, чтобы убедится что все работает:

var obj =
   {
      prop: function () {},
      foo: "bar"
   };   
obj.foo = "baz";
obj.lumpy = "woof";
delete obj.prop;
var o = Object.freeze(obj);
alert(o === obj);
alert(Object.isFrozen(obj) === true);
alert(obj.foo);
obj.foo = "hello";
alert(obj.foo);
delete obj.foo;
alert(obj.foo);
obj.func = "function";
alert(obj.function);

Более детальное описание и примеры можно найти на страницы разработчиков FireFox: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/freeze

И всё было бы хорошо, если б не браузеры, а, точнее, их поддержка или неподдержка метода Object.freeze. Если верить таблице http://kangax.github.com/es5-compat-table/, то его поддерживают только последние версии Internet Explorer, FireFox, Google Chrome и всё. Такой код не будет работать в Safari и Opera, что практически уничтожает всю полезность данного подхода. 

Так что использовать такие “константы” или нет - решать нужно исход из специфики проекта, а именно - списка поддерживаемых браузеров. В моём случае, к сожалению, поддержка Safari и Internet Explorer 8 намного важнее, чем использование почти настоящих констант в JavaScript’е.

 


 

Иногда я просто поражаюсь, как некоторые простые вещи приходится делать сложно. Опыт работы с C# в целом и ASP.NET в частности нередко мешают при использовании связки Python + Django. Все-таки скриптовый язык - отличается от строготипизированного не только синтаксисом. Тут нужно мыслить по-другому. 

Возьму для наглядности такой пример: есть какая-то абстрактная модель, которая хранит в себе данные о первых трех местах какого-либо соревнования и нужно быстро сделать минимальный интерфейс для ввода и отображения данных. Пример, конечно, надуманный и делается легко и на ASP.NET WebForms/MVC, но, меня поразила такое свойство моделей в Django, как “choices field”. 

 

Решение настолько простое и понятное, что это привело меня в полный восторг. Нет никаких таблиц-словарей, связей между таблицами, foreign keys и т.д. Только несколько строк кода и все. При этом в стандартной django админке все выглядит так же просто и понятно:

 

Понятно, что такое решение подходит далеко не всегда и только в очень простых случаях, но ведь таких случаев очень много! Не нужно стрелять с пушки по воробьям, а, в случае, когда нужно будет расширить эту модель - choices field легко становится обычным полем с foreign key и практически никак не влияет на работоспособность приложения, в простейшем случае, конечно...