Здравствуйте, Евгений Акиньшин, Вы писали:

N>>Касаемо контроля за количеством передаваемых параметров — так он делается элементарно

ЕА>так это и есть увеличение трудозатрат — напиши в каждом методе проверку на количество параметров, напиши проверку на тип параметров

А зачем в каждом методе-то писать одинаковый код?
Для этой цели можно код вынести в обертку, с которой проверка на количество и тип параметров будет выглядеть примерно так:

var Foo = new Class({
  bar : strictArgs([Number, Array], function (foo, bar) {
    console.log([foo, bar]);
  })
});

За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

ЕА> не забудь написать юнит тест на КАЖДОЕ использование этого метода — мы же не хотим чтобы о неправильном количестве переданных параметров узнал конечный пользователь вместо программиста, не забываем затраты на поддержание этого зоопарка в актуальном состоянии (сравни количество действий при добавлении параметра с типизацией и без: в первом случае надо только добавить параметр и пройти по ошибкам компилятора, во втором еще исправить проверки и в ручную найти все обращения)

Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно. А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.

ЕА>ну и выполнятся эти проверки будут в рантайме, что еще сильнее просадет производительность

Да, на проверке типов теряется примерно 20-30% скорости при вызове метода.
В абсолютном значении для нетяжелых вычислений разница небольшая — 2-4 мс.

ЕА>в нарушение всех законов физики, неумолимо приближающуюся к gcc

Каюсь, про приближение к gcc, конечно, преувеличил. И я не уточнил — приближается к gcc производительность в определенных задачах, за счет JIT компиляции.
Но в то же время на данный момент V8 объективно один из лучших по скорости интерпретаторов для скриптовых языков, оставляя Python, Ruby, и PHP далеко позади.

N>>JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
N>>И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде.

ЕА>как сделать internal protected override член класса? сколько кода тебе на это потребуется? (не забываем, что а нарушении контракта должен узнать программист, а не пользователь)

Пожалуйста:

var Foo = new atom.Class({
  bar : atom.Class.protectedMethod(function(msg) {
    console.log(msg);
  }),
  foo : function(msg) {
        this.bar(msg);
  }
});

var Bar = new atom.Class({
  Extends : Foo,
  bar : atom.Class.protectedMethod(function(msg) {
    console.log('Hello, ' + msg + '!');
  })
});

var a = new Foo();
var b = new Bar();

a.bar('world'); // Error: The method «bar» is protected.
b.bar('world'); // -/ /-

a.foo('world'); // Hello
b.foo('world'); // Hello, world!

Теперь у меня встречный вопрос — как средствами самого языка в Java добавить mixin'ы?