Конструктор нового объекта могут и не вызвать, т.e Foo.call(this) может и не наступить а вы продолжите наследование и тп
А хороший тон это когда ваша задача решается - все остальное вторично
Не создавая новый класс вы получите такой косяк - один разработчик решит сделать Element('Text') другой в том же коде Element('Image') и оба получат вместо ожидаемого только Текст или только Image и то и то в одном флаконе.
А вообще старайтесь быть проще. Лучше не мутить множественное наследование и не копировать методы прототипов потому что рано или поздно кто-то захочет понять а что за объект у него в руках и вызовет что то вроде instanceof и получит дырку от бублика.
Так или иначе - да, вам в любом случае надо будет вызывать как конструктор Bar так и Foo
И эти вызовы надо куда то положить.
Ну можно придумать и без этого - конвертнуть констуктор Bar в стринг, заинсертить иннициализацию Foo, выполнить eval :-) ну вобщем еще больше чз зад :-)
@MagoVinch может вы слышали про первый советский телевизор - перед которым располагалась лупа,
например вариант - квадратный дисплей с увеличивающей лупой? Сейчас кучи разных луп есть и если глубина неважна то может оно?
Если скорость не важна то Serializable самое то - в силу простоты.
В этом приложении нет задачи сохранять тысячи объектов в секунду поэтому надо решать более простыми методами.
