- 1
- 2
- 3
- 4
- 5
var api = angular.module('GithubApi', []);
api.controller('GithubStatus', function ($scope, $http) {
$http.get('/api.json')
.success(function (response) { $scope.api = response; });
});-
JavaScript / Говнокод #18996
−3
Пейсатели ж.скрипт фреймоврков не перестают радовать. Код несколько упрощен, но суть должна быть очевидна каждому: переменная api будет затерта как только она будет создана строкой типа "[object Object]" потому что в $scope есть поле с таким же значением.
Запостил:
wvxvw,
09 Ноября 2015
Follow us!
я не работал с ангуляром и понятия не имею что такое переменная $scope
по мне так api и $scope это две совершенно разные вещи, которые почти не пересекаются
$scope - это так, по большому счету ангулар называет элемент ХТМЛя куда складываются разные данные посредством создания новых аттрибутов у этого элемента. К одному и тому же элементу можно прикрепить и скоп и контроллер (оба делают то же самое, но зачем-то в ангулар их два). Приложение на ангулар должно иметь как минимум один контроллер. Но вот незадача: переменные в области видимости скрипта контроллера ангулар похерит когда будет создавать аттрибуты скопа, если, случайно, имена совпадут, и оба будут прикреплены к одному и тому же элементу.
Звучит так, как будто в остальных языках такого нет.
Какая разница, какой язык (ну, кроме сильно модульных/функциональных), если библиотека портит наши переменные, никто об этом не должен по умолчанию знать.
Язык, поддерживающий модульность и структурное программирование?
Так это почти любой современный язык, ну кроме разве что PHP и JavaScript
И уж конечно в сях функция не видит адресов в стеке вызвавшей её функции, если ей их явно не передали, и испортить чужие переменные не может
Да может в общем-то, если с указателями поиграть... Но это уже UB.
Синдром утёнка?
не.
Я не вижу не обходимости делать глобальные переменные менее глобальными. Они же не "проваливаются" сами по себе внутрь методов.
Нету ни стандартного описания модуля, ни стандарта на описание депенденсов, не говоря уже о едином репозитории.
Пеар был, да сдулся. Компосёр в альфе. У JS вообще их 100500 между собой не совместимых.
ну нормальная такая себе альфа. работает и не жужу.
>У JS вообще
я только 2 знаю npm и Bower
В ангуляре ещё, емнип, что-то было.
это фигушки которые могут ставить с репозитария и обновлять при необходимости.
Ангуляр использовал requirejs
Вот на пистончике я могу написать библиотеку, опубликовать её в pypi, и другие люди смогут её использовать и на нее депендится.
А как мне написать библиотеку на js? через requirejs? через npm? bower?
я просто оставлю это
Ёбанаврот...
Проводится каждый год 31 декабря новогодним обращением президента РФ.
В нашей супергитлерасинхронной экмапараше нету примитивов синхронизации, поэтому давайте срать калбеками в кучу и делать вид, что они как бы и есть
Сильная модульность - когда нет глобальных переменных, модули зависят только от своих параметров и т.п. Сильномодульные языки предоставляют лёгкий способ реализовать сильную модульность и сложный/невозможный способ сломать её.
Например, JS - среднемодульный, т.к. простым образом за счёт замыканий можно реализовать полностью изолированные модули. Но есть глобальные переменные и переменные внешних скопов, которые можно менять изнутри.
Аналогично, брейнфак - слабомодульный.
Спасибо.
В PHP/python функции стремятся к сильной модульности огороженности.
В функциональных языках скорее всего сильная огороженность.
то функция выродится в приложение и все переменные станут глобальными:)
Слушайте, Дийкстра еще в 70х писал про стуктурное программирование
Итого: сильномодульным можно назвать такой, и только такой язык который позволяет написать 2 функции. Одну пустую. Во второй - весь код.
И кстати а паскале и бейсике можно писать процедуры, а не функции
лажа определение
Главное в определении учесть брейнфак.
Ну нет, блять, минус одно.
a + b как a .add (b) vs add(a,b)
С динамическими/виртуальными всё хуже. При вызове такого метода нельзя быть уверенным в том, какая именно «функция» вызовется, потому что результат зависит от текущего состояния таблицы виртуальных методов объекта. Фактически виртуальный метод — это не функция, а переменная, указывающая на функцию.
Кстати, в пистоне есть разница между статическими и класс-методами
О, вот хорошее отличие.
Хотя, программист описывает именно эти функции. Про указатели же он (или вообще не он) говорит где-то в отдельном месте, порождая объекты: A a = new B;
И из-за какого-то return придумали новый язык?
можно его вернуть
void foo(void) -- функция без аргументов,
void bar() -- функция с любыми аргументами.
Вот так бывает с теми, кто много пишет на JS.
>>объектно-ориентированный
Использующий концепцию объекта как сущности, содержащей данные и методы для работы с ними.
Хотя: даже в ЯП без ООП можно реализовать полуООП с opaque types, что и делают Win32API, Linux итд.
>>динамическая типизация
Знание о типе данных в момент исполнения программы.
Хотя: например в java в рантайме у генериков может потеряться информация о параметре: является-ли джава динамически типизированной?
>>байт
Ну тут все просто: байт это октет. Восемь бит.
В практически всех архитектурах, разработанных за последние 40 лет.
Хотя: термин конечно иплементейшен депендент, именно потому во всяких RFC предпочитают термин octet, а в нормальных изыках типа сей нету типа byte
От привода к обжекту ничего не изменится: тип выражения все равно можно будет посчитать
в хуй?
В питоне тоже во многих случаях можно узнать тип возвращаемого значения если он не зависит от внешних данных, и? В нем есть тот же object - PyObject
>> в хуй?
>>
Я под столом
> тип выражения все равно можно будет посчитать
Только если исполнить программу.
Возьмём какой-нибудь язык со статической типизацией:
p - void*, type - int, годнота, статика, тип посчитан!
Я с таким же успехом могу сказать, что любой язык - статически типизированный т.к. хотя бы об одном типе "object" известно на этапе компиляции, а некоторые авторы компиляторов/интерпретаторов в целях оптимизации не считают тип выражения, т.к. он всё равно будет заранее известен и равен "object", из-за чего языки считают динамически типизированными и говорят, что на этапе компиляции типы не проверяются, но они-то на самом деле проверяются!
Ну и что даёт нам знание о типе void*? Только то, что компилятор не смог на этапе компиляции вычислить реальный тип.
Ах это я засунул туда int, я и виноват? Но компилятор засунул в слова и байты наши intы, floatы, char*ы и struct pitux, зачем тогда говорить о интах и питухах, когда все типы вычислены на этапе проектирования процессора?
Итого, тип данных - понятие, зависимое от уровня абстракции. На одном уровне это слова и байты, на другом - указатели и целые, на третьем - пользовательские питухи. Языки со статической типизацией просто предоставляют нам возможность посчитать чуть больше типов на каком-то уровне абстракции. Если же мы поднимаемся выше этого уровня абстракции ("легальный" путь - динамический полиморфизм), мы получаем шиш и динамическую типизацию (может быть, рукотворную).
> лёгкий способ реализовать сильную модульность
// внутри сишки
static int x = 0;
> сложный/невозможный способ сломать её
Только через прямое ковыряние в памяти на грани UB'а. Адекватными способами обойти эту модульность нельзя.
Хм, вот заняли слово "модульность" подключающимися кусками кода, а не разделяющимися кусками. Надо другое слово придумать. Инкапсулирующий? Изолирующий? Огораживающий? Разделяющий? Наверно, огораживающий.
«Хорошилище грядет из ристалища на позорище по гульбищу в мокроступах и с растопыркой» («Франт идет из цирка в театр по бульвару в галошах и с зонтиком»)
знаешь спеки ecmascript, какие-то библиотеки js и тд уже не проблема.
не знаешь - появляются такие посты негодования, если честно я даже сейчас не понимаю, что у автора поста не так с кодом, он даже объяснить нормально не смог.