Не магия. В статье простая реализация REPR паттерна с явной регистрацией (которую, имхо, можно сделать изящнее). Этот паттерн можно сделать и контроллерами (правда это не будет полный эквивалент, ведь там используются атрибуты)
немалые удобства
И немалые неудобства, ведь точка в вакууме неудобна. Ну для навигации по проекту они структурно лежат по папкам. Но что делать, если мы хотим навесить что-то дополнительно на пару точек из группы? Ну можно в каждом закопипастить, а потом просто забыть про это. Или замудрить какой-то костыль, который объединит эти пару точек, но это уже и будет магия.
А ведь можно сделать просто и красиво сведя регистрацию в единое место. Если очень хочется, то можно и этот класс разбить (и разложить по тем же папкам) - все равно это будет явная схема, где видно "кто куда и с чем" и возможностью реконфигурации не трогая сами точки.
Тут с автором еще можно поспорить с его "делаем в HandleAsync всю работу", но это уже оффтоп.
Мошенник инициирует вызов с кодом на ваш телефон (банально "забыл пароль", "регистрация") и ему ваш код может даже не быть интересен. Просто при получении вами этого кода на фоне кто-то говорит "код подошел/мы его взломали, быстрее бери кредит", чтобы вы это услышали.
И вот у вас смс с кодом и чьи то слова что "код подошел". Вы ПАНИКУЕТЕ и дальше вам звонит "поддержка" с "вас взломали" или смс с "просьбой позвонить" и далее предлагаются действия по вашему "спасению". Человек в панике уже особо не думает - на это и рассчитано.
В данной схеме немного модифицировано - у вас выпрашивается код левого сервиса, а потом "пугающая фраза на фоне" и тревожная смс от "госуслуг". Но принцип тот же - "пугающая фраза"+"смс от госуслуг" должна вызвать панику - и вам предложат "помощь".
Не знаю си, но уверен что навязываемых проверок в си нет. Верим "массив не будет пуст и можно смело брать элемент" - и можно и не проверять. Rust же заставит обработать вероятную ситуацию, тем самым добавив лишние if.
Тут 2 стула. Либо "проверять тут нечего, ситуация не возникнет - и потом в рантайме получаем ой", либо "делаем доп проверки на каждый чих, но в реале они никогда не сработают и будут зря кушать такты".
Судя по количеству ошибок в сишном коде вариант "мамой клянусь тут ошибок нет" работает не очень.
Никому не нравится, но нужно быть реалистами — заменять не на что. А чтобы заменить… Ну тут сильно здорово нужно подумать и времени это займет нереально.
создать абсолютно новую архитектуру процессора, который не умеет в спекулятивное выполнение, но при этом не уступает по скорости.
Отладить эту новую архитектуру. Ну чтобы снова потом не начинать все с самого начала по гарантии из-за ошибок проектирования новой архитектуры.
Построить производственную линию. Причем несколько — под разные сокеты (материнские платы ведь менять нельзя)
Выпустить большое количество процессоров и доставить их потребителю
Например, они активно используются в jetpack compose в Modifier. В зависимости от текущего скоупа у Modifier доступны те или иные методы расширения. Если у нас BoxScope, то нам доступны дополнительно Modifier.aling() и Modifier.matchParentSize(), где они имеют смысл. И не путаются под ногами в других местах.
Также возможность элегантно расширить контрол, в котором авторы не додумали сделать нужное. Без этого в jetpack compose пришлось бы изворачиваться как в swiftUI (хотя там тоже неплохо, но не так гибко).
Ну а Flow<> своими методами как иначе расширять?!
Конечно гибкость вида "подключили библиотеку и у нас появились дополнительные методы" обладает обратной стороной "скопировал код с so и все горит красным, не пойму что импортировать и где искать".
Нет никакой желтизны. В заголовке речь идет о 12гб версии, которая имела не только меньше памяти, а вот ту самую начинку, что сейчас как 4070ти подают. Можете даже спеки сравнить.
match greeting:
case "":
print('Hello my friend')
case _:
print(f'Hello {greeting}')
в случае с wildcard хоть работает ожидаемо. А в случае с case name — переменная name может существовать выше, а позже быть переименована и case name начинает работать как wildcard с именем? Стрельба в ногу какая-то.
И все равно непонятно причем тут захват. name это переменная, которая существует до match greeting и ее видно в print(f'Hello {name}'), что ожидаемо, ведь match это просто переписанная иначе цепочка if. Так что куда захватывается?
Принимается. Как средство, что позволит откатить по горячим следам. Мне этого не всегда достаточно, но это уже мои личные проблемы и потому я избегаю гит.
вот я об этом выше и говорил, а мне начали доказывать что гит хуже)))
Ну вы даете. Товарищ явно написал, что его переход на git был обоснован не личными качествами git, а потому что гитхаб.
Перемотайте в начала ветки и посмотрите с чего начался наш спор )))
Да так. Небольшой оффтоп. Просто вы необходимость чтения документации в плюсы к причинам популярности гит записали.
На этом предлагаю закруглиться. Почему? Вместо ответа я лучше скопипастю цитату с того же хабра
Не хвататься за оголенные провода несложно.
Понять, почему на обычном рабочем месте изоляция на проводах отсутствует, гораздо сложнее.
Еще сложнее понять тех, кто продает все это как достоинства инструмента.
Вы действительно считаете, что тулз, для работы с которым нужно читать тонны документации, спрашивать коллег или на форумах и при всем при этом все равно иметь урезанные возможности (пресловутое «нам это не нужно») — это хороший тулз?
Это объективное мнение или субъективное
Первое конечно. Продуманный инструмент всегда проще в освоении, чем тот, где нужно тщательно читать много документации. Как по вашему, насколько интуитивен отсоединенный комит? Насколько интуитивно то, что ваши комиты считают мусором?
Концепт подхода гита к веткам отличается от привычного. Имеет право на жизнь, почему ж нет. Но в остальном косяки вызывают недоумение.
Исходя из ваших слов вы не проводили опытное сравнение с альтернативами. Вы выбрали гит, потому что он «на слуху» или «более популярен». А популярность гиту обеспечил авторитет автора и гитхаб. Так что «начал только в прошлом году» не является аргументом.
Но что рандомное или убогое средство
Если сравнивать гит с другими по принципу «давать программисту как можно больше, а мешать как можно меньше», то гит выглядит как любительская поделка. Но ко всему можно привыкнуть. Любой инструмент можно освоить и не стрелять себе в ногу. Вот и гит там же. И то что альтернативы проще (в освоении, а не в фичах), удобнее и безопаснее — роли уже не играет, ведь «уже освоился и привык, зачем мне альтернатива»
Вот только хорошим и удобным оказался не git, а GitHub, что и определило выбор. И выбирали не гит, а GitHub. А далее и вовсе не выбирали, ибо считать выбором «везде требуют гит, потому выбираем гит» просто наивно.
Угадывание происходит также при rebase/merge. И если не угадал, то есть шанс, что он молча вольет левые изменения не туда. Спасает git только то, что у такой ситуации малая вероятность (нужно чтобы файлы были похожи и место вливания похожи).
Слухи про неизменность истории в меркуриал очень давно устарели.
Для переписывания истории там не один инструмент (rebase, histedit, mq, evolve), но, в отличие от git (а может и вообще всех остальных) позволяет делать это безопасно (evolve). Более того, существуют даже официально переписываемые публично ветки (topic). Попробуйте переписать публичную ветку в git, когда вы в ней не один. А в меркуриал это не приносит проблем.
Не магия. В статье простая реализация REPR паттерна с явной регистрацией (которую, имхо, можно сделать изящнее). Этот паттерн можно сделать и контроллерами (правда это не будет полный эквивалент, ведь там используются атрибуты)
И немалые неудобства, ведь точка в вакууме неудобна. Ну для навигации по проекту они структурно лежат по папкам. Но что делать, если мы хотим навесить что-то дополнительно на пару точек из группы? Ну можно в каждом закопипастить, а потом просто забыть про это. Или замудрить какой-то костыль, который объединит эти пару точек, но это уже и будет магия.
А ведь можно сделать просто и красиво сведя регистрацию в единое место. Если очень хочется, то можно и этот класс разбить (и разложить по тем же папкам) - все равно это будет явная схема, где видно "кто куда и с чем" и возможностью реконфигурации не трогая сами точки.
Тут с автором еще можно поспорить с его "делаем в HandleAsync всю работу", но это уже оффтоп.
Никто ничего не перехватывает.
Мошенник инициирует вызов с кодом на ваш телефон (банально "забыл пароль", "регистрация") и ему ваш код может даже не быть интересен. Просто при получении вами этого кода на фоне кто-то говорит "код подошел/мы его взломали, быстрее бери кредит", чтобы вы это услышали.
И вот у вас смс с кодом и чьи то слова что "код подошел". Вы ПАНИКУЕТЕ и дальше вам звонит "поддержка" с "вас взломали" или смс с "просьбой позвонить" и далее предлагаются действия по вашему "спасению". Человек в панике уже особо не думает - на это и рассчитано.
В данной схеме немного модифицировано - у вас выпрашивается код левого сервиса, а потом "пугающая фраза на фоне" и тревожная смс от "госуслуг". Но принцип тот же - "пугающая фраза"+"смс от госуслуг" должна вызвать панику - и вам предложат "помощь".
Не знаю си, но уверен что навязываемых проверок в си нет. Верим "массив не будет пуст и можно смело брать элемент" - и можно и не проверять. Rust же заставит обработать вероятную ситуацию, тем самым добавив лишние if.
Тут 2 стула. Либо "проверять тут нечего, ситуация не возникнет - и потом в рантайме получаем ой", либо "делаем доп проверки на каждый чих, но в реале они никогда не сработают и будут зря кушать такты".
Судя по количеству ошибок в сишном коде вариант "мамой клянусь тут ошибок нет" работает не очень.
В rust же все эти многочисленные unwrap/expect/? разворачиваются в дополнительные проверки, которые повышают безопасность за счет производительности.
Например, они активно используются в jetpack compose в Modifier. В зависимости от текущего скоупа у Modifier доступны те или иные методы расширения. Если у нас BoxScope, то нам доступны дополнительно Modifier.aling() и Modifier.matchParentSize(), где они имеют смысл. И не путаются под ногами в других местах.
Также возможность элегантно расширить контрол, в котором авторы не додумали сделать нужное. Без этого в jetpack compose пришлось бы изворачиваться как в swiftUI (хотя там тоже неплохо, но не так гибко).
Ну а Flow<> своими методами как иначе расширять?!
Конечно гибкость вида "подключили библиотеку и у нас появились дополнительные методы" обладает обратной стороной "скопировал код с so и все горит красным, не пойму что импортировать и где искать".
Нет никакой желтизны. В заголовке речь идет о 12гб версии, которая имела не только меньше памяти, а вот ту самую начинку, что сейчас как 4070ти подают. Можете даже спеки сравнить.
в случае с wildcard хоть работает ожидаемо. А в случае с case name — переменная name может существовать выше, а позже быть переименована и case name начинает работать как wildcard с именем? Стрельба в ногу какая-то.
Перемотайте в начала ветки и посмотрите с чего начался наш спор )))
На этом предлагаю закруглиться. Почему? Вместо ответа я лучше скопипастю цитату с того же хабра
Остальное можно списать на «будь внимательнее», но «делай бэкапы» я за решение не считаю
Первое конечно. Продуманный инструмент всегда проще в освоении, чем тот, где нужно тщательно читать много документации. Как по вашему, насколько интуитивен отсоединенный комит? Насколько интуитивно то, что ваши комиты считают мусором?
Концепт подхода гита к веткам отличается от привычного. Имеет право на жизнь, почему ж нет. Но в остальном косяки вызывают недоумение.
Если сравнивать гит с другими по принципу «давать программисту как можно больше, а мешать как можно меньше», то гит выглядит как любительская поделка. Но ко всему можно привыкнуть. Любой инструмент можно освоить и не стрелять себе в ногу. Вот и гит там же. И то что альтернативы проще (в освоении, а не в фичах), удобнее и безопаснее — роли уже не играет, ведь «уже освоился и привык, зачем мне альтернатива»
Вот только хорошим и удобным оказался не git, а GitHub, что и определило выбор. И выбирали не гит, а GitHub. А далее и вовсе не выбирали, ибо считать выбором «везде требуют гит, потому выбираем гит» просто наивно.
Угадывание происходит также при rebase/merge. И если не угадал, то есть шанс, что он молча вольет левые изменения не туда. Спасает git только то, что у такой ситуации малая вероятность (нужно чтобы файлы были похожи и место вливания похожи).
Для переписывания истории там не один инструмент (rebase, histedit, mq, evolve), но, в отличие от git (а может и вообще всех остальных) позволяет делать это безопасно (evolve). Более того, существуют даже официально переписываемые публично ветки (topic). Попробуйте переписать публичную ветку в git, когда вы в ней не один. А в меркуриал это не приносит проблем.