@icelaba А если задавать в Foo дополнительные функции прямо в конструкторе через this. По сути, после вызова Foo.call(this), в Bar будут доступны методы с Foo, просто они не будут лежать в прототипе. Хороший ли это тон?
@icelaba да, конструктор один. К примеру разработчик может вызвать Element('Text') и получить свойства и методы Element'а и Text'a. Точно также можно сделать и Element('Image') и получить Element'a и Image'а, в свою очередь. Text и Image классы, которые реализовывают этот самый дополнительный функционал.
@icelaba Предположим что таких Foo, может быть несколько. А конструктор Bar один. Тогда при вызове MyBar можно динамически переопределить прототип с Bar и Foo2, например? Таким образом я хочу реализовать некое подобие Extensions под ядро :)
@GavriKos настроил из готовых режимов для работы с текстом. Глаза не устают, пикселизации и неестественного размытия текста (как на других мониторах) не вижу. Во всех планах считают это лучшим монитором.
@c_pro_lang Python - это back-end яп. Вам предлагают посмотреть на фреймворки и template-engine, в которых можно использовать синтаксические конструкции для генерирования HTML. Разрабатывать веб-приложения хотите - тогда от HTML вы никуда не денетесь, какие бы вы крутые фреймворки и плюшки не использовали.
@dizballanze Спасибо за ответ, считаю это достаточно развернутым ответом. Кучу тяжелых фич IDE никогда не использовал. Процентов 85 кода пишу без темплейтов, снипеттов и т.п., поэтому скорее нужен быстрый и функциональный текстовый редактор. Нужно будет попробовать его, но если бы еще кинуть ссылки на пару хороших мануалов с его основными фичами - было бы хорошо.
Я не путаю хороший текстовый редактор (Sublime Text) с хорошей IDE (PhpStorm). Но задаюсь вопросом, стоит ли пробовать себя в Sublime Text, как замену PhpStorm. По сути все это текстовый редактор же.
При беглом осмотре Sublime все понравилось. Все "навороченные" фишки PhpStorm зачастую не использую. Достаточного хорошего автокомплита и стабильной, быстрой работы.
@OnYourLips что вы понимаете под "сложной" логикой? Согласен, то что нельзя делать JOIN'ы - это был удар. Но решено, что у нас не так часто JOIN и делается. Поэтому в таких местах да, придется на промисах делать выборки с разных моделей. Но в общем суть заключается в выборе с одних моделей, причем очень быстро на отдачу. Так что решили NodeJS, посмотрим что из этого выйдет.
@sergealmazov я не говорил, что большой проект и сразу NodeJS. Я говорю о высоконагруженных проектах. Его преимущества в скорости выполнения запросов и отказоустойчивости. Если еще и прикрутить документоориентированные базы данних и грамотно написать код, то будет выдерживать очень и очень нагрузки. Также хорошо горизонтально масштабируется с помощью кластеров.
String.prototype.slice.call(query, 1, -1);