Я бы рекомендовал не заниматься ерундой с «изоляцией» пространств имён. Прям религиозный фанатизм.
1. Иногда всё-таки нужно залезть в потроха, потому что нужный метод не был вытащен в апи. И не надо рассказывать, что это нехорошо и я не должен этого хотеть. Мне нужно решить задачу здесь и сейчас, а не когда там разработчики библиотеки решат принимать мой патч ИЛИ НЕТ.
2. В целях дебага удобно опять же иметь доступ ко всем потрохам прямо из консоли, не занимаясь ерундой с расстановкой брейкпоинтов и исполнением своего кода в точке останова.
3. Тезис про то, что мы можем под Window в разных модулях понимать разные вещи — на самом деле очень вредный совет. Ибо легко запутаться, когда одна сущность в разных местах называется по разному и наоборот разные одинаково — лишняя путаница. Гораздо лучше, когда одна сущность имеет строго одно глобальное имя. Пространства имён рулят, «модули» не рулят.
4. Зависимости между модулями тут никак не отражены. Но если брать в пример попсовый RJS, то зависимости указываются как строки, являющиеся глобальным идентификатором модуля. Собственно какая разница, где будут глобально храниться все модули: в window или в require. Суть одна и та же.
5. У всех функций есть «отображаемое имя» — оно показывается в профайлере, консоли и вообще очень полезная штука при дебаге. Удобно, когда имя функции представляет из себя глобальный ее идентификатор. Например, при таком объявлении:
JSui.Div.prototype.title = function(){}
Имя функции будет «JSui.Div.prototype.title»
А при таком:
function getNewId(){}
Всего лишь «getNewId» и гадай потом из какого модуля эта веселая функция.
«one var statement» — антипаттерн, поработай с системами контроля версий и поймёшь почему.
«use strict» — разное поведение в разных браузерах. Нафиг оно надо. Защиту от протечек локальных переменных в глобальную область видимости обеспечит вам любой валидатор. Больше ничего полезного в этом стрикте нет.
Зачем заводить константы для литералов? Надо не для минификатора код писать, а для программистов. А умный минификатор может и сам сгруппировать одинаковые литералы в переменную.
В каждом файле у тебя лишних 8 строк копипасты. Я бы переписал эти монструозные divs.js и labels.js попроще:
RxJS — это не FRP, это просто RP.
Для тех кто не в теме, функциональное программирование — это не о функциях первого порядка, это о вычислениях без побочных действий.
На второй же иллюстрации нарисован граф. Почему же вы пытаетесь упихнуть его в документы или таблицы? Используйте графовые базы и не будете иметь проблем. Серьёзно. Расширяйте свой кругозор, вместо того, чтобы в очередной раз менять шило на мыло.
Особенно веселит «специальный приз» за самое медленное решение на эвалах, которое сливает даже выполненным в функциональном стиле)
Эвалы дают +1 к скорости в микробенчмарках и -1 к поддерживаемости в реальных проектах.
Эти «приёмы» правильнее всё же называть «костылями». Агнуляр умудряется тормозить и требовать применения «приёмов» там, где более толковые решения даже не затыкаются. Рендерить только видимые ячейки хорошо, когда они все одного размера и представляют из себя плоский список. Но стоит им начать подстраиваться под размер содержимого, динамически меняться в размерах и представлять из себя иерархическую структуру, так сразу определение что видимо, а что нет становится весьма нетривиальной задачей.
И да, в более других решениях биндинги ничего не стоят (не считая небольшого потребления памяти) и их не надо отключать, лишая себя автоматической актуализации вьюшки.
Как «автор фреймворков» не вижу особого повода для радости.
1. Многие всё ещё поддерживают ie8 где даже акцессоров толком нет.
2. В сравнении с ангуляровскими грязными проверками любой фреймворк выглядит как манна небесная.
3. Никто находясь в трезвом уме не будет светить полями наружу — только через акцессоры. Соответственно вся подписка/отписка/нотификации будут делаться как и сейчас — вручную. Новое апи тут вносит лишь неоднородность реализации не давая ощутимого профита.
4. Единственное полезное применение — отслеживать изменение в чужих объектах. Особенно полезно это было бы для хостовых объектов. Но о них в статье ни слова и что-то мне подсказывает, что с ними будет всё как обычно — плохо.
5. Никак не решена проблема холостых вычислений. Например, переменная А зависит от C и B, а B зависит от C. В результате когда изменится С сначала будет вычислена А, потом В, а потом снова А. В общем с этим АПИ будет та же беда, что и с нокаутом:
диаграмма: nin-jin.github.io/slide/#slide=induction
тест: jsperf.com/reactive-libraries-comparison
6. Они это апи точно согласовали с остальными игроками? А то получится, что в хроме Object.observe, в мозилле watch, а ie вообще не при делах.
tenshi: А при чём тут множество значений Integer?) Map — это сюръекция множества ключей _засунутых в структуру_ на множество значений _тоже засунтых в структуру_. Как ключи, так и значения в общем случае могут быть любых типов. Важно лишь то, что для любого значения найдётся какой-нибудь ключ.
Сюръекция, в строгом математическом смысле, это «отображение на», т.е. такая функция, у которой образ совпадает со множеством значений. В общем случае образ функции может быть меньше области значений. Например, есть функция f(x) = x^2. Ясно, что мы можем считать, что f: R → R. Но Im f = [0, ∞) ⊂ R. Т.е. f — не сюръекция. Это, я думаю, вы знаете.
Аналогично с Map. В декларации Map явно указываются области определения и значения (собственно, почему словарь и назвали «отображением» в английском): Map. Если бы Map m было бы сюръекцией, то для любого Integer i всегда бы нашлось такое String s, что m.get(s).equals(i), что, понятно, не соответствует действительности.
Googolplex: Да, любое отображение можно рассматривать как сюръекцию на его образ. Однако, строго говоря, это будет уже другое отображение, потому что отображение — это тройка множеств (dom f, Im f, f ⊆ dom f × Im f), и если одно из множеств поменяется, то формально само отображение тоже будет другим. В контексте структур данных это существенно. В частности, Java не позволяет описать тип «Множество чисел типа Integer, являющихся значениями данного экземпляра Map», поэтому нельзя говорить о «множестве значений, засунутых в структуру». Следовательно, когда вы имеете на руках Map, вы можете его понимать только как отображение f: String → Integer, и никак иначе. А это уже, очевидно, не сюръекция. Если бы в Java можно было бы описать такой тип (возможно, Agda2 и аналогичные языки с зависимыми типами такое могут), хотя я лично сомневаюсь в его полезности, то тогда, вероятно, можно было бы говорить о сюръекциях, хотя я тут тоже утверждать ничего не могу — не работал особенно с этими языками.
tenshi: Отображение типа на тип — это уже полноценная функция. Map и подобные структуры работают не с типами (которые в общем случае — бесконечные множества), а с конкретным конечным множеством значений. При этом одни значения помещаются в «образ» (ключи), а другие в «отображение» (значения). А Map гарантириует сюръективное отображение первого множества на второе. А запись вида Map — не более чем ограничение на типы ключей и значений. Если вы запросите значение по ключу, которого нет в мапе, то получите что угодно, но только не Integer.
Вы это, напишите, что всё надо писать на английском, ибо проверять это будет не русскоговорящий человек.
Не понятно требование реализовать в точности такой же интерфейс. Все эти однобуквенные сокращения просто невозможно запомнить — приходится безконца лазить в шпоргалки. Кроме того, передавать паттерн при каждом вызове — не удобно и несколько медленнее.
Такое апи было бы куда предпочтительнее:
var formatTime = $jin.date.formatter( 'Weekday, YYYY-MM-DD hh:mm' )
formatTime( new Date ) // Thursday, 2014-05-23 11:45
i.gyazo.com/3d5b12a18a1b5d7870906f2d4bf27ed8.png
i.gyazo.com/10efa8018b2af95ef0bbc1fdd00c33ab.png
i.gyazo.com/695489ae9c22c5b99565e71e4a0d4fe2.png
1. Иногда всё-таки нужно залезть в потроха, потому что нужный метод не был вытащен в апи. И не надо рассказывать, что это нехорошо и я не должен этого хотеть. Мне нужно решить задачу здесь и сейчас, а не когда там разработчики библиотеки решат принимать мой патч ИЛИ НЕТ.
2. В целях дебага удобно опять же иметь доступ ко всем потрохам прямо из консоли, не занимаясь ерундой с расстановкой брейкпоинтов и исполнением своего кода в точке останова.
3. Тезис про то, что мы можем под Window в разных модулях понимать разные вещи — на самом деле очень вредный совет. Ибо легко запутаться, когда одна сущность в разных местах называется по разному и наоборот разные одинаково — лишняя путаница. Гораздо лучше, когда одна сущность имеет строго одно глобальное имя. Пространства имён рулят, «модули» не рулят.
4. Зависимости между модулями тут никак не отражены. Но если брать в пример попсовый RJS, то зависимости указываются как строки, являющиеся глобальным идентификатором модуля. Собственно какая разница, где будут глобально храниться все модули: в window или в require. Суть одна и та же.
5. У всех функций есть «отображаемое имя» — оно показывается в профайлере, консоли и вообще очень полезная штука при дебаге. Удобно, когда имя функции представляет из себя глобальный ее идентификатор. Например, при таком объявлении:
JSui.Div.prototype.title = function(){}
Имя функции будет «JSui.Div.prototype.title»
А при таком:
function getNewId(){}
Всего лишь «getNewId» и гадай потом из какого модуля эта веселая функция.
«one var statement» — антипаттерн, поработай с системами контроля версий и поймёшь почему.
«use strict» — разное поведение в разных браузерах. Нафиг оно надо. Защиту от протечек локальных переменных в глобальную область видимости обеспечит вам любой валидатор. Больше ничего полезного в этом стрикте нет.
Зачем заводить константы для литералов? Надо не для минификатора код писать, а для программистов. А умный минификатор может и сам сгруппировать одинаковые литералы в переменную.
В каждом файле у тебя лишних 8 строк копипасты. Я бы переписал эти монструозные divs.js и labels.js попроще:
//divs.js
this.JSui = JSui || {}
JSui.Div = function(){
…
}
//labels.js
this.JSui = JSui || {}
JSui.Label = function(){
…
JSui.Div()
…
}
Для тех кто не в теме, функциональное программирование — это не о функциях первого порядка, это о вычислениях без побочных действий.
www.orientechnologies.com/orientdb-vs-mongodb/
Эвалы дают +1 к скорости в микробенчмарках и -1 к поддерживаемости в реальных проектах.
И да, в более других решениях биндинги ничего не стоят (не считая небольшого потребления памяти) и их не надо отключать, лишая себя автоматической актуализации вьюшки.
Кстати, куда можно написать, чтобы предложить разработчикам браузеров реализовать более полезное апи?
1. Многие всё ещё поддерживают ie8 где даже акцессоров толком нет.
2. В сравнении с ангуляровскими грязными проверками любой фреймворк выглядит как манна небесная.
3. Никто находясь в трезвом уме не будет светить полями наружу — только через акцессоры. Соответственно вся подписка/отписка/нотификации будут делаться как и сейчас — вручную. Новое апи тут вносит лишь неоднородность реализации не давая ощутимого профита.
4. Единственное полезное применение — отслеживать изменение в чужих объектах. Особенно полезно это было бы для хостовых объектов. Но о них в статье ни слова и что-то мне подсказывает, что с ними будет всё как обычно — плохо.
5. Никак не решена проблема холостых вычислений. Например, переменная А зависит от C и B, а B зависит от C. В результате когда изменится С сначала будет вычислена А, потом В, а потом снова А. В общем с этим АПИ будет та же беда, что и с нокаутом:
диаграмма: nin-jin.github.io/slide/#slide=induction
тест: jsperf.com/reactive-libraries-comparison
6. Они это апи точно согласовали с остальными игроками? А то получится, что в хроме Object.observe, в мозилле watch, а ie вообще не при делах.
Сюръекция, в строгом математическом смысле, это «отображение на», т.е. такая функция, у которой образ совпадает со множеством значений. В общем случае образ функции может быть меньше области значений. Например, есть функция f(x) = x^2. Ясно, что мы можем считать, что f: R → R. Но Im f = [0, ∞) ⊂ R. Т.е. f — не сюръекция. Это, я думаю, вы знаете.
Аналогично с Map. В декларации Map явно указываются области определения и значения (собственно, почему словарь и назвали «отображением» в английском): Map. Если бы Map m было бы сюръекцией, то для любого Integer i всегда бы нашлось такое String s, что m.get(s).equals(i), что, понятно, не соответствует действительности.
Googolplex: Да, любое отображение можно рассматривать как сюръекцию на его образ. Однако, строго говоря, это будет уже другое отображение, потому что отображение — это тройка множеств (dom f, Im f, f ⊆ dom f × Im f), и если одно из множеств поменяется, то формально само отображение тоже будет другим. В контексте структур данных это существенно. В частности, Java не позволяет описать тип «Множество чисел типа Integer, являющихся значениями данного экземпляра Map», поэтому нельзя говорить о «множестве значений, засунутых в структуру». Следовательно, когда вы имеете на руках Map, вы можете его понимать только как отображение f: String → Integer, и никак иначе. А это уже, очевидно, не сюръекция. Если бы в Java можно было бы описать такой тип (возможно, Agda2 и аналогичные языки с зависимыми типами такое могут), хотя я лично сомневаюсь в его полезности, то тогда, вероятно, можно было бы говорить о сюръекциях, хотя я тут тоже утверждать ничего не могу — не работал особенно с этими языками.
tenshi: Отображение типа на тип — это уже полноценная функция. Map и подобные структуры работают не с типами (которые в общем случае — бесконечные множества), а с конкретным конечным множеством значений. При этом одни значения помещаются в «образ» (ключи), а другие в «отображение» (значения). А Map гарантириует сюръективное отображение первого множества на второе. А запись вида Map — не более чем ограничение на типы ключей и значений. Если вы запросите значение по ключу, которого нет в мапе, то получите что угодно, но только не Integer.
Не понятно требование реализовать в точности такой же интерфейс. Все эти однобуквенные сокращения просто невозможно запомнить — приходится безконца лазить в шпоргалки. Кроме того, передавать паттерн при каждом вызове — не удобно и несколько медленнее.
Такое апи было бы куда предпочтительнее:
var formatTime = $jin.date.formatter( 'Weekday, YYYY-MM-DD hh:mm' )
formatTime( new Date ) // Thursday, 2014-05-23 11:45