Яростный МечПрограмёр1. Зачем в прототип писать полноценный объект, если точно тот же объект с расширенными возможностями станет результирующим. То есть по сути создаётся одна дополнительная копия объекта, все свойства которого перекрыты потомком.
2. Если я на входе конструктора Animal ожидаю объект, с которым собираюсь проводить некоторые манипуляции (например это массив, и я хочу получить его длину и т.д.), то Bird.prototype = new Animal(); может привести к ошибке, если я не предусмотрю такой вызов. А причина моих попыток как-раз в том, что бы как можно больше предусматривалось автоматически, то есть не писать лишней логики.

Вместо этих двух пунктов я просто ввёл собственную цепочку прототипов (точнее их конструкторов) и обернул такое "наследование" в отдельный метод.именно эти два пункта учтены в том варианте, который я привел 15393424 - там создается стандартная цепочка прототипов, но без полноценного объекта в прототипе.

Вполне полноценный и работоспособный подход. Есть явные преимущества перед предложенным мной? Цепочка прототипов заполняется, однако всё-ровно не совсем полноценно. например alert(b.constructor.prototype._legs); вместо ожидаемого "2" выведет "undefined" :)
В общем ничего против такого варианта не имею, но имеет смысл менять привычку только если в новом варианте есть преимущества. Так что, если есть, прошу пояснить.

spПроблема многих, кому чегото не хватает в javascript, в том что приходя в javascript они мыслят и пытаются использовать его как предыдущий язык.

Чего греха таить - я тоже после C# хотел классов, но после изучения языка и многих лет работы мне становится смешно, когда ктото в очередной раз хочет классов в javascript)

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

JavaScript тем и прекрасен, что в нем нет строгой типизации, помню сколько огорода приходилось городить на C# чтобы иметь возможность обрабатывать различные типы классов в одно коде. Чур меня чур от такого!)

JavaScript гибок, легок и прекрасен именно в таком виде какой он есть и переделывать его не надо - надо переделывать программистов, которые хотят его переделать) Не хотите всех его плюшек - переходите на другие языки

Переход на другой язык не представляется возможным... Как-то я себе не представляю как клиентскую часть сайта возможно написать на С#, не написав собственный интерпретатор :)

А как различные типы классов в одном коде то обрабатывать? Если вызывать методы класса, или обращаться к определённым свойствам, то для этого и придумали наследование и интерфейсы (просто структуру классов надо правильно строить).

И как динамическая подгрузка сводит на нет использование классов? В пхп include тоже динамически код грузит, но там это никак не мешает использовать классовое ООП на полную катушку.

spjavascript тем и хорош что в нем не нужна никакая структура классов, что в одном коде обработать любые, т.е. абсолютно любые заранее неизвестные структуры данных

то есть js Вам нравится тем, что перед тем как что-то написать не надо думать и проектировать? Начал писать, а дальше уж как пойдёт?! :)

Но основная суть всё-же не в этом... Как уже писал, мне больше всего не хватает перегрузки методов, когда один метод с разными аргументами работает по-разному, при чём без дополнительной логики в теле метода. Этого я как-раз таки и добился (хотя пришлось в итоге некоторые изменения внести, так как IE как всегда не очень понравились некоторые моменты :)) + для оптимизации по скорости).

spДинамическая подгрузка в таком случае сводится не подгрузке одного класса а всей иерархии классов сразу - что лишает смысла динамическую подгрузку в целом!

Повторюсь... php также умеет грузить код частями и динамически, при этом классовое ООП и динамическая подгрузка кода там очень даже хорошо уживаются (взять тот же yii с его достаточно сложной структурой и "lazy loading"). При динамической загрузке грузить надо не всю иерархию классов (в моём случае модулей, так как у меня основная делёжка не по классам, а по модулям), а только зависимости для данного модуля.

Насчёт mixin, а чем он лучше множественного наследования (чем так принципиально отличается)? Ведь в принципе то же самое, за исключением вызова конструкторов предков (подобно наследованию от нескольких классов без конструкторов). Нет, конечно на уровне языка, отличие в реализации очень большое... Но вот уже на уровне создания приложения - я не понимаю особой разницы. Ну да, паттерн mixin позволяет расширить функционал отдельного объекта, что не принято делать при классовом наследовании. Однако "не принято", не значит "запрещено" :)

spПрограмёр,

ну зачем вы специально все утрируете?))
если у вас есть молоток, но вы привыкли работать с топором - зачем переделывать молоток под топор. чтоб забивать им гвозди???

У меня есть опыт работы с топором (дэлфи и php), и есть в руках молоток (js), кстати, есть и опыт работы с ним. Так вот я как-раз хочу сделать молоток таким, что бы одной стороной можно было гвозди забивать удобно, а повернув - дрова рубить )). То есть я к молотку просто стараюсь прикрутить функцию топора, при этом как можно меньше ограничив оригинальные функции инструмента.

Пока удаётся... ))

в копилку кстати свалилась возможность быстрой выборки элементов DOM по селектору (по производительности сравнима с jQuery), а также инструмент для анимаций (он кстати по производительности не уступает jQuery, пока на глаз с анимированием в несколько десятков элементов).

С новыми доработками пишется очень удобно... надеюсь что-то в итоге и получится ))

st_stПрограмёрв копилку кстати свалилась возможность быстрой выборки элементов DOM по селектору (по производительности сравнима с jQuery), а также инструмент для анимаций (он кстати по производительности не уступает jQuery, пока на глаз с анимированием в несколько десятков элементов).

С новыми доработками пишется очень удобно... надеюсь что-то в итоге и получится ))

Выборка по DOM - querySelectorAll(), анимация - CSS3 Animation.

querySelectorAll() - это да... штука хорошая... Именно её и использовал у себя. Но сама по себе выборка не несёт смысла без методов быстрого изменения свойств элементов и тому подобное (как в jQuery)

CSS3 Animation - до IE10 про неё можно забыть... если там и есть какая-либо поддержка, то как минимум animation-timing-function в ie ниже 10 не поддерживается.
В итоге да, можно и его использовать, но ещё рано.