в документации почему-то про это не пишут — функции _.max() и _.min(), что в underscore, что в lodash понимают только числа, а не вообще. т.е. их нельзя использовать, например, чтобы найти в коллекции максимальную строку — получается ерунда. все потому, что. авторы underscore пытаются изобразить конкретно Math.min, и Math.max, а авторы lodash изображают underscore.
мне показалось, что они пытаются что-то защитить таким образом. но вряд-ли дело в двух разбитых «ап стену» машинах на скорости 180 км/ч.
очень похоже, что штуки предназначены для дополнительной защиты этих самых сменных аккумуляторов, либо систем их крепления, от всяческого дорожного мусора, воды и грязи, которые им могут вредить и сокращать срок службы. по всей видимости, это недешевые штуки, которые на «заправках» они меняют за так. следовательно, должны быть заинтересованы, чтобы аккумуляторы служили как можно более вечно. вот и предлагают как бесплатный апгрейд всем, а не улучшательный допник для параноиков.
для nss/getnssent_r.c анализатор написал ерунду, и у вас код отквочен не правильно:
смотрим
127 int
128 __nss_getent_r (const char *getent_func_name,
129 const char *setent_func_name,
130 db_lookup_function lookup_fct,
131 service_user **nip, service_user **startp,
132 service_user **last_nip, int *stayopen_tmp, int res,
133 void *resbuf, char *buffer, size_t buflen,
134 void **result, int *h_errnop)
....
144 if (res && __res_maybe_init (&_res, 0) == -1)
145 {
146 *h_errnop = NETDB_INTERNAL;
147 *result = NULL;
148 return errno;
149 }
150
...
159 while (! no_more)
160 {
161 int is_last_nip = *nip == *last_nip;
162
163 status = DL_CALL_FCT (fct.f,
164 (resbuf, buffer, buflen, &errno, &h_errno));
165
166 /* The status is NSS_STATUS_TRYAGAIN and errno is ERANGE the
167 provided buffer is too small. In this case we should give
168 the user the possibility to enlarge the buffer and we should
169 not simply go on with the next service (even if the TRYAGAIN
170 action tells us so). */
171 if (status == NSS_STATUS_TRYAGAIN
172 && (h_errnop == NULL || *h_errnop == NETDB_INTERNAL)
173 && errno == ERANGE)
174 break;
тут видно, что в первом случае (145) присваивается значение, в указатель, пришедший в функцию в качестве параметра. он не может быть NULL по соглашению. в 163 этот указатель передается по ссылке функции DL_CALL_FCT, и в 172 проверяется уже новое значение, возвращаемое этой функцией.
sunrpc/clnt_raw.c это пропиетарное наследие от уже вымерших мамонтов. по умолчанию не компилируется. тут анализатор занимается археологией — в самом деле, поучительно.
2012-05-10 Andreas Jaeger Make sunrpc code usable again
2011-04-17 Ulrich Drepper Obsolete RPC implementation in libc.
2010-08-19 Ulrich Drepper Once again change RPC copyright notices.
2010-06-28 Ulrich Drepper Revert «Sun agreed to a change of the license for the…
2009-05-21 Ulrich Drepper Sun agreed to a change of the license for the RPC code…
…
1995-02-18 Roland McGrath initial import
кстати, в текущей ревизии в копирайтах значится Oracle.
в коде все четко и однозначно. сей кусок для людей предназначен, а не анализаторов — опенсорс же. ну да, в статье это представлено в духе «скандалы-интриги-расследования», видимо чтобы читать веселее было. :)
ок) вы ведь уже объяснили зачем это было нужно «картам», и почему появился YM. вы классные (мм, история enb vs bem make вообще эпична). ни кто не сомневается, что ради правильной цели, у вашей команды вместе с Яндексом, хватит ресурсов и на то, чтобы переписать пол гитхаба как вам захочется, если вдруг. я серьезно.
тут уже несколько раз объясняли, что нарушение абстракции это таскать лоадер в зависимостях модуля, т.к. система загрузки модулей должна абстрагировать код от этого. нарушение абстракции это смешивание логики загрузки кода, конструирования и разруливания порядка инстанцирования объектов в одну кучу. но, как оказывается, в некоторых случаях из подобных фокусов можно извлечь определенную практическую пользу. за что еще раз вам респект.
а 'promise!anyName', это не два отдельных слова, а «такое-вот-имя-модуля-целиком» — синтаксический компромисс в именовании, благодаря которому модули могут резовлить реализацию разными способами. «tpl!name», «ym!name» и т.п. главное, что результат для клиента не отличим. так что тут как раз все правильно.
вообще. на мой взгляд, основная ценность систем подобного уровня не в наличии какой-либо «клиллер-фичи», а в возможности интеграции как можно большего количества различных решений между собой наименьшей кровью. поэтому, в целом, соглашения рулят.
вы несомненно молодцы, что сумели стандартизировать этот момент внутри Яндекса. CommonJS/AMD решают схожую задачу, но не в масштабах отдельной компании, а для всего мира. это на порядок сложнее, отсюда больше компромиссов. зря вы ставите в один ранг с CommonJS и AMD, противопоставляя YM — это лишь сбивает с толку и провоцирует бесполезный флейм.
вероятность встретить за пределами яндексных инкубаторов, на открытом воздухе, код, завернутый в YM, такая же как увидеть в лесу динозавра. и год тому назад, когда он заопенсорсился, и сейчас. как только я перестал заниматься околояндексной разработкой, в коде не осталось практически ни чего из этого великолепия. потому, что во всем остальном мире — другие соглашения. за пределами Яндекса YM — лишь элегантное решение частной задачи, коих тысячи. как видите есть альтернативы.
CommonJS и AMD это общепринятые вещи — в смысле использования в проектах, рецептов и инструментов для комбинирования с другими технологиями, поддержки, документации. YM как еще один стандарт — не нужен (имхо). в этом смысле, было бы гораздо полезнее, если бы вы делились с сообществом своими революционными идеями, не в виде альтернатив (это лишь все усложняет), а коммитами в общепринятые технологии.
аналогично, MessagingService и NotificationsSerivce (в примере из статьи), можно тестировать отдельно, а для метода SendMessage зафигачить интеграционный тест. однако лирический герой ратует за то, чтобы непременно тестить освещение не зависимо от реализации конкретных компонентов, для чего наваял DI с конструктором и пачкой новых интерфейсов "… не обусловленных ни какой семантикой".
это так же гибко и правильно, как если в квартире каждый светильник включать через вилку-розетку. и теперь весь сыр-бор вокруг подключения потолочной люстры — когда тестировщикам ужас как хочется заместо неё втыкать свои имитаторы, а хозяевам нафиг не нужно что-то вместо неё подключать и вообще портит интерьер. :)
VIM c ctags (пусть wrangler если это erlang) решают задачу в 95% случаев. остальные 95% кода все равно лапками проверять. не понимаю с чем вы не согласны.
я хотел сказать, что в реальных проектах, возможности языка используются на полную катушку — со всяким мета-программированием, и прочей ерундой, которая делает язык именно таким, за что мы его и выбираем, а статический анализ — лишь приятной примочкой (типа на PEP8 чекать). автоматический рефакторинг в каких-то частных случаях тоже возможен, но поменять мегабайт индуистического кода неглядя, как для Java — это фантастика (или безумие).
угу. только при чем тут Java, если статья конкретно про Erlang?
в этом цирке «Станый Метод» может быть запросто результатом чего-то в роде string:concat(X, Y), или того хуже. это совсем другой мир, где от AST толку чуть. распоследние тулзы пытаются даже код выполнять, но у и этого подхода есть принципиальные ограничения.
по-моему зря этот Джо сюда Java прилепил, она совсем из другой оперы, и отсюда холивар весь.
кто-то может привести пример инструментария для языков с _динамической_ типизацией где всякие go to definition и find all references, дают сколь-нибудь существенное отличие в надежности результата, по сравнению с «тупым грепом»?
мне вот не попадались еще. поэтому да, на первый план, так или иначе, выходит удобство редактирования и «vim» — наше всё. остальные трюки приходится делать лапками и внимательно проверять глазками.
Спасибо за интересную драму про менеджера Егора. Я искренне ему сопереживал на протяжении всей статьи, в надежде, что все закончится хорошо. Единственная досада, что почти детективная интрига с отчетами, обозначенная в завязке, осталась так и не раскрытой, а заявленный алгоритм описывается на примере каких-то совершенно иных, не связанных между собой ситуаций.
Поэтому сюжет, в целом, показался каким-то не логичным, и быть может надуманным, даже. С первого взгляда, такая непоследовательность выглядит либо как недоработка сценария (если это литература), либо как притягивание фактов за уши к теории (если речь про науку). Если только оставлять сюжетную интригу не раскрытой это какая-то специальная особенность маркетинговой публицистики. В общем, не понятно, стоит-ли того же ожидать на ваших курсах, или в отличие от статьи, там все четко разложено по полочкам?
очень похоже, что штуки предназначены для дополнительной защиты этих самых сменных аккумуляторов, либо систем их крепления, от всяческого дорожного мусора, воды и грязи, которые им могут вредить и сокращать срок службы. по всей видимости, это недешевые штуки, которые на «заправках» они меняют за так. следовательно, должны быть заинтересованы, чтобы аккумуляторы служили как можно более вечно. вот и предлагают как бесплатный апгрейд всем, а не улучшательный допник для параноиков.
тут видно, что в первом случае (145) присваивается значение, в указатель, пришедший в функцию в качестве параметра. он не может быть NULL по соглашению. в 163 этот указатель передается по ссылке функции DL_CALL_FCT, и в 172 проверяется уже новое значение, возвращаемое этой функцией.
там история коммитов выглядит интереснее, чем сам код:
кстати, в текущей ревизии в копирайтах значится Oracle.
тут уже несколько раз объясняли, что нарушение абстракции это таскать лоадер в зависимостях модуля, т.к. система загрузки модулей должна абстрагировать код от этого. нарушение абстракции это смешивание логики загрузки кода, конструирования и разруливания порядка инстанцирования объектов в одну кучу. но, как оказывается, в некоторых случаях из подобных фокусов можно извлечь определенную практическую пользу. за что еще раз вам респект.
а 'promise!anyName', это не два отдельных слова, а «такое-вот-имя-модуля-целиком» — синтаксический компромисс в именовании, благодаря которому модули могут резовлить реализацию разными способами. «tpl!name», «ym!name» и т.п. главное, что результат для клиента не отличим. так что тут как раз все правильно.
вообще. на мой взгляд, основная ценность систем подобного уровня не в наличии какой-либо «клиллер-фичи», а в возможности интеграции как можно большего количества различных решений между собой наименьшей кровью. поэтому, в целом, соглашения рулят.
вы несомненно молодцы, что сумели стандартизировать этот момент внутри Яндекса. CommonJS/AMD решают схожую задачу, но не в масштабах отдельной компании, а для всего мира. это на порядок сложнее, отсюда больше компромиссов. зря вы ставите в один ранг с CommonJS и AMD, противопоставляя YM — это лишь сбивает с толку и провоцирует бесполезный флейм.
вероятность встретить за пределами яндексных инкубаторов, на открытом воздухе, код, завернутый в YM, такая же как увидеть в лесу динозавра. и год тому назад, когда он заопенсорсился, и сейчас. как только я перестал заниматься околояндексной разработкой, в коде не осталось практически ни чего из этого великолепия. потому, что во всем остальном мире — другие соглашения. за пределами Яндекса YM — лишь элегантное решение частной задачи, коих тысячи. как видите есть альтернативы.
CommonJS и AMD это общепринятые вещи — в смысле использования в проектах, рецептов и инструментов для комбинирования с другими технологиями, поддержки, документации. YM как еще один стандарт — не нужен (имхо). в этом смысле, было бы гораздо полезнее, если бы вы делились с сообществом своими революционными идеями, не в виде альтернатив (это лишь все усложняет), а коммитами в общепринятые технологии.
в этом цирке «Станый Метод» может быть запросто результатом чего-то в роде string:concat(X, Y), или того хуже. это совсем другой мир, где от AST толку чуть. распоследние тулзы пытаются даже код выполнять, но у и этого подхода есть принципиальные ограничения.
кто-то может привести пример инструментария для языков с _динамической_ типизацией где всякие go to definition и find all references, дают сколь-нибудь существенное отличие в надежности результата, по сравнению с «тупым грепом»?
мне вот не попадались еще. поэтому да, на первый план, так или иначе, выходит удобство редактирования и «vim» — наше всё. остальные трюки приходится делать лапками и внимательно проверять глазками.
Поэтому сюжет, в целом, показался каким-то не логичным, и быть может надуманным, даже. С первого взгляда, такая непоследовательность выглядит либо как недоработка сценария (если это литература), либо как притягивание фактов за уши к теории (если речь про науку). Если только оставлять сюжетную интригу не раскрытой это какая-то специальная особенность маркетинговой публицистики. В общем, не понятно, стоит-ли того же ожидать на ваших курсах, или в отличие от статьи, там все четко разложено по полочкам?