А то тут их кто-то будет читать.
Кстати, иногда я туда заглядывал, но качество статей на Мегамозге было просто ужасным, в большинстве своём. Арифметические ошибки в статистике, неправильные выводы из неправильных фактов. Бррр.
Чего лично я не понял: а на кой чёрт Мегамозг смержили с Хабрахабром, а не с Гиктаймс (между делом сбросив то-о-чём-нельзя-говорить третий раз)? Какой всё это имеет отношению к программированию?
Имхо, переменные, попадающие в функцию, надо проверять всегда.
Может быть вы и не задумывали использование функции в каких-либо условиях, но ваш напарник может об этом не знать при написании кода. Даже если и есть документация на проект, он её мог не читать. Или вы сами, в конце концов, можете забыть про ограничения конкретной функции. Или это может произойти из-за бага.
Кстати, скажу слово в защиту макросов: правильное применение макросов позволяет свести к нулю ошибки копипаста и значительно сократить количество кода.
И всё. Вы больше никогда не забудете изменить значение переменной.
Так же есть вещи, которые нельзя вынести в методы, вроде агрегации va_list. Так же неплохо макросы подходят для отладки: например, единственный #define MEASURE_ELAPSED_TIME(code) <...> экономит десятки строк кода на измерении быстродействия.
Я более чем уверен, что в своём приложении такое провернуть можно, главное убедить компилятор дать это сделать. В конце концов у нас есть указатель на интересующий нас адрес и мы можем в него писать.
Но внутренние структуры всё равно придётся перенести по новому адресу. Если я ничего не путаю, они таки константного размера. Другой вопрос — как к этому отнесётся arc. Да и не стал бы я такое в продакшн выкладывать, а тем более — в популярную библиотеку
Как альтернативный вариант — можно засвизлить методы существующего делегата. В общем, если нужны будут безумные идеи — обращайтесь. Их есть у меня :)
Общий API — это мёртвый номер. Найдутся и те, кто про негу просто не будет знать, и те, кто найдут в нём фатальный недостаток, и те, кто просто забьёт.
Имхо, нужно достаточно хорошо мимикрировить под старый делегат, чтобы другие библиотеки думали, что они по прежнему общаются со своим собственным объектом. NSProxy и всё такое. Но тут основная проблема — == по адресу.
Интересно, можно ли малой кровью передвинуть объект в памяти и поставить на его место свой прокси? :)
И туда и туда, баг, на самом деле, отправлять надо. Просто сущность проблемы такова, что её можно обойти, если в программе используется не более одного sdk с этим багом.
Делегат, кстати, уже сейчас кешируется — записывается как associated object. Думаю, проблему решит установка делегата в случае, если у нас он не кеширован.
По поводу пролетать мимо — нет:
2 возможных случая очерёдности установки делегатов (после правки):
— BlockKit -> Rx: Сначала устанавливается делегат блоккита, захватывая оригинальный и подставляя себя. Потом — устанавливается делегат Rx, захватывая делегат блоккита. Вызов, упс, баг в блокките, зацикливание
— Rx -> BlockKit: Сначала устанавливается делегат Rx, захватывая оригинальный и подставляя себя. Потом — устанавливается делегат блоккита, захватывая делегат Rx. Вызов: Rx -> BlockKit -> original, всё отработало штатно.
Естественно, правку надо вносить в обе библиотеки, чтобы всё работало нормально.
P.S.: Все рассуждения построены с игнорированием того факта, что библиотека BlockKit написана на Obj-C и врядли они когда-нибудь встретятся вместе. Впрочем, неявные зависимости и всё такое… В общем, всё может быть.
P.S.: Но я упускаю возможность повторной установки делегата программистом. В общем — надо ещё что-то делать с setDelegate.
Покопался в исходниках — создание DelegateProxy происходит лениво. НО он переустанавливается при каждой манипуляции с RX.
В общем, багрепорт: если к проекту, реализующая свой собственный DelegateProxy (пример из мира Swift'а не приведу, из ObjC — BlockKit) — делегаты имеют серьёзный шанс зациклиться друг на друга, потеряв делегат оригинальный и уйдя в бесконечные перевызовы друг друга.
Если коротко — DelegateProxy считает, что он владеет объектом эксклюзивно, хотя это может быть не так.
Электрические двигатели квадракоптеров могут работать на скорости, превышающей штатную.
Собственно, если посмотрите в нормальном магазине характеристики двигателей — вы уведите 2 цифры: максимальный потребляемый ток и максимально допустимый кратковременный ток (~10 секунд, после чего двигатель умирает от перегрева)
На счёт 1 двигателя mm3 погорячился, а вот системы, позволяющие посадить квадракоптер с одним неисправным двигателем действительно существуют.
Как работают DelegateProxy? Они создаются и подписываются на все объекты подряд сразу после создания этих объектов или только когда это действительно необходимо?
Хочется оценить количество граблей в плане совместимости с другими библиотеками.
Пожалуй, всё-таки вступлюсь за МТС: если их «склонили к сотрудничеству» о обязали молчать — они будут молчать, какие бы сайты не создавались и сколько бы абонентов от них не уходило. Более того, в этой ситуации находятся вообще все Российские операторы.
Кстати, а почему статья в Разработке?
Кстати, иногда я туда заглядывал, но качество статей на Мегамозге было просто ужасным, в большинстве своём. Арифметические ошибки в статистике, неправильные выводы из неправильных фактов. Бррр.
Может быть вы и не задумывали использование функции в каких-либо условиях, но ваш напарник может об этом не знать при написании кода. Даже если и есть документация на проект, он её мог не читать. Или вы сами, в конце концов, можете забыть про ограничения конкретной функции. Или это может произойти из-за бага.
Мы не в идеальном мире живём, в конце концов.
Простейший пример (код на ObjC):
#define __T_STRINGIFY(x) #x
#define DEFINE_CONSTANT_KEY(kConstantKey) static NSString * const kConstantKey = @__T_STRINGIFY(kConstantKey)
DEFINE_CONSTANT_KEY(kLanguagesSelectionKey);
И всё. Вы больше никогда не забудете изменить значение переменной.
Так же есть вещи, которые нельзя вынести в методы, вроде агрегации va_list. Так же неплохо макросы подходят для отладки: например, единственный #define MEASURE_ELAPSED_TIME(code) <...> экономит десятки строк кода на измерении быстродействия.
Но внутренние структуры всё равно придётся перенести по новому адресу. Если я ничего не путаю, они таки константного размера. Другой вопрос — как к этому отнесётся arc. Да и не стал бы я такое в продакшн выкладывать, а тем более — в популярную библиотеку
Как альтернативный вариант — можно засвизлить методы существующего делегата. В общем, если нужны будут безумные идеи — обращайтесь. Их есть у меня :)
Имхо, нужно достаточно хорошо мимикрировить под старый делегат, чтобы другие библиотеки думали, что они по прежнему общаются со своим собственным объектом. NSProxy и всё такое. Но тут основная проблема — == по адресу.
Интересно, можно ли малой кровью передвинуть объект в памяти и поставить на его место свой прокси? :)
Делегат, кстати, уже сейчас кешируется — записывается как associated object. Думаю, проблему решит установка делегата в случае, если у нас он не кеширован.
По поводу пролетать мимо — нет:
2 возможных случая очерёдности установки делегатов (после правки):
— BlockKit -> Rx: Сначала устанавливается делегат блоккита, захватывая оригинальный и подставляя себя. Потом — устанавливается делегат Rx, захватывая делегат блоккита. Вызов, упс, баг в блокките, зацикливание
— Rx -> BlockKit: Сначала устанавливается делегат Rx, захватывая оригинальный и подставляя себя. Потом — устанавливается делегат блоккита, захватывая делегат Rx. Вызов: Rx -> BlockKit -> original, всё отработало штатно.
Естественно, правку надо вносить в обе библиотеки, чтобы всё работало нормально.
P.S.: Все рассуждения построены с игнорированием того факта, что библиотека BlockKit написана на Obj-C и врядли они когда-нибудь встретятся вместе. Впрочем, неявные зависимости и всё такое… В общем, всё может быть.
P.S.: Но я упускаю возможность повторной установки делегата программистом. В общем — надо ещё что-то делать с setDelegate.
Пардон. Не перечитал коммент.
В общем, багрепорт: если к проекту, реализующая свой собственный DelegateProxy (пример из мира Swift'а не приведу, из ObjC — BlockKit) — делегаты имеют серьёзный шанс зациклиться друг на друга, потеряв делегат оригинальный и уйдя в бесконечные перевызовы друг друга.
Если коротко — DelegateProxy считает, что он владеет объектом эксклюзивно, хотя это может быть не так.
Собственно, если посмотрите в нормальном магазине характеристики двигателей — вы уведите 2 цифры: максимальный потребляемый ток и максимально допустимый кратковременный ток (~10 секунд, после чего двигатель умирает от перегрева)
На счёт 1 двигателя mm3 погорячился, а вот системы, позволяющие посадить квадракоптер с одним неисправным двигателем действительно существуют.
Хочется оценить количество граблей в плане совместимости с другими библиотеками.
Оффтопик: Раньше Вивальди показывал серым всё, кроме доменного имени или это мои персональные галлюцинации?