На самом деле, ещё непонятно, кто кого и чем заменил.
Swift унаследовал термин протокол от Objective-C. Если верить Википедии, в Objective-C протоколы были добавлены в компании NeXT, которая просуществовала с 1985 по 1996 год (потом была куплена Apple). А первая версия Java вышла только в том самом 1996, опять же, если верить википедии.
Выходит, протоколы появились раньше чем интерфейсы и это инженерам Sun Microsystems зачем-то понадобилось заменить термин.
Другое дело, что Java захватила мир, а Objective-C так и остался нишевым. Но тут уж ничего не поделать.
Если мигрирует существующий проект, может пригодится xcdiff. Он позволяет сравнить имеющийся проект со сгенерированным, чтобы убедиться, что при миграции ничего не потерялось.
О, спасибо, с сотней дверей, действительно, понятней.
Особенно, в сочетании с:
В этой формулировке легко показать, что если игрок выбирает случайную дверь, то не важно, каким образом выбирается дверь, за которой находится автомобиль.
Получается, что если мы подчиним выбор дверей строгим правилам, то ситуация не поменяется, потому что случайность в этом процессе — замешивание приза.
Если же мы будем менять местами 2 двери, а третья будет оставаться проигрышной всегда, то и вероятность автоматически выравнивается до ½. Несмотря та то, что с точки зрения выбирающего ничего не поменялось.
Ситуация: я стою перед выбором из трёх вариантов. Один из вариантов выигрышный. Я выбираю наугад и выигрываю с вероятностью ⅓ или проигрываю с вероятностью ⅔. Выяснять мы это, конечно, не будем.
Вместо проверки, мне показывают заведомо проигрышный вариант.
Новая ситуация: я остаюсь перед выбором из двух вариантов. Один из вариантов выигрышный. Я выбираю наугад и, "очевидно", выигрываю с вероятностью ½ или проигрываю с той же вероятностью.
Я знаю, что это не так. Об этом говорят несколько источников и мой, с позволения сказать, численный эксперимент.
Формально, да так, возможно, и есть. Я лично слышал про "any", а не про "one", но спорить не возьмусь.
Пояснение, мягко говоря, шуточное, однако, в предложении с "один" речь, как будто бы, об совершенно определённом, но неизвестном собеседнику персонаже; в предложении с "какой-то" речь идёт о никому не известном персонаже, личность которого мало кого интересует.
Объект класса Random, проинициализированный конкретным значением seed, будет всегда воспроизводить одинаковую последовательность псевдослучайных чисел.
Это позволяет, например, написать стабильные тесты на функцию использующую этот самый объект.
Отчасти это опять из-за русского языка, где большинство слов произносится так, как пишется
Строго говоря, это не совсем так. У нас тоже есть чередование безударных гласных, оглушение и озвончение согласных, смягчение согласных некоторыми гласными, и, напоследок, "что".
Со смягчением согласных ещё и коллизии бывают, когда сам согласный — мягкий. Привет "чу-щу".
UPD: Но если произнести слово так, как оно пишется, то, скорее всего, будешь понят, в отличии от.
Как мне кажется, для пода было бы правильнее не добавлять методы прямо к типам из UIKit, а воспользоваться дополнительной структурой для организации пространства имён. В качестве примеров могу привести Reactive из RxCocoa и AlamofireExtension.
В отличии от target-action, delegate всегда один, в один момент времени. Два разных замыкания не могут обрабатывать одно и то же событие. А подход к настройке абсолютно одинаковый. Возможно стоит явно выразить этот нюанс в API.
То есть, каждый Item создаёт свой Random? Тогда в этом и проблема. Можно создать Random на уровень выше и передавать в конструкторы брони и оружия. Тогда все предметы создаваемые подряд будут использовать один и тот же объект Random, и проблема решится.
В моём понимании это не «работа ради работы», а «работа ради качества». Мы же применяем code review чтобы найти потенциальные проблемы, а при большом объёме изменений эта техника становится малоэффективной.
Собственно, любая техника контроля качества, которая подразумевает участие человека, теряет эффективность по мере роста этого самого объёма.
Не все переделки кода можно разбить на мелкие и удобные для чтения части.
А вот с этим спорить не возьмусь, наверняка найдутся примеры. Миграция чего-нибудь со сломанной обратной совместимостью, может быть, ещё что-то.
Однако, если ревьюеры достаточно непреклонны и нещадно разворачивают смешанные изменения, разбивать их очень быстро надоедает. Вырабатывается внутренняя дисциплина, если хотите.
Пример. Сидишь, правишь файлы, а тут, о ужас, стиль кодирования годичной давности залежался. Откладываешь все свои изменения, правишь стиль и отправляешь на ревью. Потом, накладываешь те изменения поверх исправленного стиля и продолжаешь.
И волки сыты, и овцы целы.
В качестве бонуса, не приходится заниматься одновременно несколькими вещами. В центре внимания всегда одна небольшая задача.
Мой личный опыт свидетельствует, что смена подхода происходит, буквально, после нескольких повторений.
Боюсь, вам не удастся угадать все случаи, когда одно и то же английское слово переводится по разному в зависимости от контекста. К тому же, использование развёрнутого ключа, в моём понимании, уже стремится к тем самым идентификаторам, от которых хотел избавиться автор.
Переводы частей отдельно, возможно, и являются причиной проблем с переводчиками. Языки не всегда подчиняются законам, которые кажутся логичными. Законченный текст должен переводится целиком без всяких склеек.
Получается, что Void будет работать только на тупиковых экранах, с которых никуда вообще нельзя попасть и которые не зависят от входных данных сами. Под такое описание подойдёт, разве что, Terms and Conditions или что-то в таком духе.
ППКС
На самом деле, ещё непонятно, кто кого и чем заменил.
Swift унаследовал термин протокол от Objective-C. Если верить Википедии, в Objective-C протоколы были добавлены в компании NeXT, которая просуществовала с 1985 по 1996 год (потом была куплена Apple). А первая версия Java вышла только в том самом 1996, опять же, если верить википедии.
Выходит, протоколы появились раньше чем интерфейсы и это инженерам Sun Microsystems зачем-то понадобилось заменить термин.
Другое дело, что Java захватила мир, а Objective-C так и остался нишевым. Но тут уж ничего не поделать.
Если мигрирует существующий проект, может пригодится xcdiff. Он позволяет сравнить имеющийся проект со сгенерированным, чтобы убедиться, что при миграции ничего не потерялось.
О, спасибо, с сотней дверей, действительно, понятней.
Особенно, в сочетании с:
Получается, что если мы подчиним выбор дверей строгим правилам, то ситуация не поменяется, потому что случайность в этом процессе — замешивание приза.
Если же мы будем менять местами 2 двери, а третья будет оставаться проигрышной всегда, то и вероятность автоматически выравнивается до ½. Несмотря та то, что с точки зрения выбирающего ничего не поменялось.
Попробую.
Ситуация: я стою перед выбором из трёх вариантов. Один из вариантов выигрышный. Я выбираю наугад и выигрываю с вероятностью ⅓ или проигрываю с вероятностью ⅔. Выяснять мы это, конечно, не будем.
Вместо проверки, мне показывают заведомо проигрышный вариант.
Новая ситуация: я остаюсь перед выбором из двух вариантов. Один из вариантов выигрышный. Я выбираю наугад и, "очевидно", выигрываю с вероятностью ½ или проигрываю с той же вероятностью.
Я знаю, что это не так. Об этом говорят несколько источников и мой, с позволения сказать, численный эксперимент.
К сожалению, где моя ошибка я понять не могу.
Но разве смена или не смена выбора не является отдельным экспериментом?
Первый эксперимент — выбор из трёх дверей. Он ничем не заканчивается, так как измерение так и не было выполнено.
После незавершённого первого эксперимента проводится второй — выбор из двух дверей.
Укажите на ошибку в рассуждениях, пожалуйста.
Формально, да так, возможно, и есть. Я лично слышал про "any", а не про "one", но спорить не возьмусь.
Пояснение, мягко говоря, шуточное, однако, в предложении с "один" речь, как будто бы, об совершенно определённом, но неизвестном собеседнику персонаже; в предложении с "какой-то" речь идёт о никому не известном персонаже, личность которого мало кого интересует.
Как мне кажется, логика сохранена.
Объект класса
Random, проинициализированный конкретным значениемseed, будет всегда воспроизводить одинаковую последовательность псевдослучайных чисел.Это позволяет, например, написать стабильные тесты на функцию использующую этот самый объект.
A — это, скорее, "какой-то", чем "один". Один — the.
Вариант без артикля, внезапно, смешной:
Хотя, всё это — так себе рассуждения, такой грамматической конструкции в русском языке, всё равно, нет.
Строго говоря, это не совсем так. У нас тоже есть чередование безударных гласных, оглушение и озвончение согласных, смягчение согласных некоторыми гласными, и, напоследок, "что".
Со смягчением согласных ещё и коллизии бывают, когда сам согласный — мягкий. Привет "чу-щу".
UPD: Но если произнести слово так, как оно пишется, то, скорее всего, будешь понят, в отличии от.
Ну как же, это passive voice и present perfect одновременно.
А вот для present perfect и active voice в русском языке нет настолько прямолинейного соответствия.
Тем не менее, именно такая аналогия помогла лично мне понять смысл этой грамматической конструкции.
Выглядит интересно.
Есть пара комментариев:
Reactiveиз RxCocoa иAlamofireExtension.То есть, каждый Item создаёт свой Random? Тогда в этом и проблема. Можно создать Random на уровень выше и передавать в конструкторы брони и оружия. Тогда все предметы создаваемые подряд будут использовать один и тот же объект Random, и проблема решится.
Не вебом единым.
«Убойная стрижка» (The Legend of Barney Thomson)
Фильм, конечно, про парикмахера и, даже, комедия, но чёрная.
В моём понимании это не «работа ради работы», а «работа ради качества». Мы же применяем code review чтобы найти потенциальные проблемы, а при большом объёме изменений эта техника становится малоэффективной.
Собственно, любая техника контроля качества, которая подразумевает участие человека, теряет эффективность по мере роста этого самого объёма.
А вот с этим спорить не возьмусь, наверняка найдутся примеры. Миграция чего-нибудь со сломанной обратной совместимостью, может быть, ещё что-то.
К сожалению, с инструментами в этом деле туго.
Однако, если ревьюеры достаточно непреклонны и нещадно разворачивают смешанные изменения, разбивать их очень быстро надоедает. Вырабатывается внутренняя дисциплина, если хотите.
Пример. Сидишь, правишь файлы, а тут, о ужас, стиль кодирования годичной давности залежался. Откладываешь все свои изменения, правишь стиль и отправляешь на ревью. Потом, накладываешь те изменения поверх исправленного стиля и продолжаешь.
И волки сыты, и овцы целы.
В качестве бонуса, не приходится заниматься одновременно несколькими вещами. В центре внимания всегда одна небольшая задача.
Мой личный опыт свидетельствует, что смена подхода происходит, буквально, после нескольких повторений.
В качестве альтернативы
ifможно посмотреть на functools.singledispatch.Получается, что
Voidбудет работать только на тупиковых экранах, с которых никуда вообще нельзя попасть и которые не зависят от входных данных сами. Под такое описание подойдёт, разве что, Terms and Conditions или что-то в таком духе.