Pull to refresh
32
0.2

Пользователь

Send message
Не шарите вы кароче
http://cs4.pikabu.ru/post_img/2015/05/16/4/1431753754_409078117.gif
ну ясно что взрывы это для эффектности и они не настоящие, это и так понятно.

Я имел дела с коптерами и имею представление об их стабилизации. Я не вижу вообще никаких проблем стабилизировать выстрел или же очередь.

К тому же как можно так колхозно доказывать, что его сдует? там банальный пистолет-пулемет, с механизмом которого вы незнакомы, быть может он гасит инерцию по вертикальному вектору
А что там фейкать? стабилизация коптера и удаленное управление оружием это уже обыденность
Тю так и любой другой беспилотный активно юзается в боевых действиях. Думал в посте увижу по типу коптера с оружием как тут: https://www.youtube.com/watch?v=SNPJMk2fgJU
Так как я истинный приверженец Backbone, не могу не заметить, что Backbone ставить в один ряд или хотя бы даже сравнивать с фреймворками не стоит. Backbone одним только своим видом пропагандирует распределенную разработку и является библиотекой с набором конструкций на основе которых вы проектируете свою собственную архитектуру или же более абстрактную вещь как фреймворк.
Лучше добавьте в сравнение react.js, как компонентный фреймворк
Почему то, мне кажется, что нового создания переменной не происходит, а лишь передача значения (хотя в виде переменной) в scope конкретной итерации.

А с const уходит в бесконечный так как поведение хрома достаточно интересно. Он не бросает каких либо исключений, а просто игнорирует присвоение, инкремент.
Первый пример разумеется работоспособный, но какого либо преимущества над использованием обычного оператора var нет. Но если вы напишите например такое:
const a = 10;
const a = 11;

То отхватите ошибку дублирования.
Второй же содержит ошибку, так как константа iread-only, и не может быть инкрементирована или деинкрементирована
Разумеется оригинал предпочтительней, особенно по технической литературе.
Так именно это я и имел ввиду. Но — инкапсуляция это не только сокрытие реализации. Она так же может преследовать следующие цели:
Организовать доступ пользователя к атрибутам и методам так, чтобы предотвратить несанкционированное использование (у нас пока нет интерфейсов, но есть необходимость).
Защита от ошибок программиста заключается в неразрешенных объектах, способах использования методов (атрибутов).

Концептуальная модель ООП предполагает 2 области видимости: — методы видны для всех пользователей класса — методы видны только для объектов данного класса.

Для кого-то это важно, для кого-то нет. JS является решением множества проблем. И есть ряд задач где сокрытие как данных так и реализации необходимы в равной степени. Я привел отличный пример выше.
Инкапсуляция.
Подход приведенный в публикации активно используется индженерами в мазиле. Например Антон Ковалев использовал его при сокрытии нижнего слоя редактора. Для чего? Они не хотели показывать пользователям их API, что у них под капотом CodeMirror. Не из соображений сокрытия реализации, а из за соображений того, что они могут его свободно обновлять, изменять, или сменить полность на другой. Без страха сломать сторонние плагины под CodeMirror, что черевато крахом продакшена
Да конечно их можно использовать в некотором роде. Но мы полностью не спрячем такие поля. Символы могут быть получены с помощью методов Object.getOwnPropertySymbols и Object.getOwnPropertyKeys.

UPD. Выше меня опередили.
12 ...
30

Information

Rating
2,385-th
Registered
Activity