Я понимаю, что живая речь неточна, но что же имел ввиду Павел Новиков, когда говорил про бесконечное несчетное множество объектов?
Это он меня подводил к тому, что хэш на самом деле не уникальный идентификатор, и у меня у двух разных объектов может быть одинаковый хэш. Но я затупил, и не воспользовался подсказкой
Можно — вот мобикс поудобнее. Но если хочешь персистентно, тогда придётся как-то имплементить флакс, со всеми этими именами экшнов. У них же ещё какой кеейс есть — они передают экшны по сети.
А вот персистентность нужна для дешевого перемещения между состояниями. Оправданно ли это — нет, для подавляющего большинства приложений. Но это мое мнение, и я не фронтендер, так что хз
Штука в том, что в WPF мы не играем в иммутабельность, и работа с состоянием у нас происходит или в модели, или в сервисах. И в отличие от контекста веб приложения на десктопах нет одной важной проблемы — нам не нужно расшаривать состояние между двумя вкладками одного ии того же приложения. Поэтому мы просто говорим — вот это мы храним в оперативке, а вот это вот мы храним на диске. Т.е. у нас такой проблемы просто нет
Ну фичи то они так и так от нас получат. А вот приводить код в порядок — если разработчики не будут это продавливать, бизнес никогда об этом не попросит
И, что примечательно, вы оба сидите в комментариях к моей статье. Хотя я со своей стороны сделал все, что бы было понятно — это моя статья, такая же, как и все мои, проходи мимо, и читай то что тебе нравится — но нет.
Ну, человека который и так ищет что-то по F# мне ничему учить не надо. Учитывая, что я плюс минус знаю всех из русского F# комьюнити. А так, мои статьи и идеи кому то заходят, пусть заодно посмотрят на технологию. которая зашла мне
Ну, когда люди начнут читать статьи про F# с таким же рвением, как статьи про мои личные проблемы, с удовольствием буду писать про него. А так, какя-никакая популяризация ЯПа — и то хлеб
Принципы работы ГЦ не нужны, только когда ты о них не знаешь. Если не думаешь о таких вещах — просаживаешь перфоманс, потребление памяти и создаешь лики — а потом прожираешь бюджет проекта на изначально неверные попытки что-то пофиксить.
Я это к тому, что нужно быть где-то по середине между человеком, который живет продуктом и человеком. которому интересен ГЦ. А крайности — не работают
Тут вот какой поинт — кастить к эни можно, только если точно знаешь, что значение валидное. Потому что если ты не знаешь — а функция защищена типом — внутри неё скорее всего не будет рантайм проверок, и скормив ей эни ты создашь баг.
Порезать то всегда можно, вопрос, насколько это целесообразно. Если мы например изменили кодстайл, и теперь во всех файлах надо заменить _field на field — я бы это на кусочки дробить не стал. Резать надо не количеством файлов, и даже не количеством работы — а контекстом задачи. У меня есть убежденность, что любой пулл реквест должен отдавать рабочее, и в каком то смысле законченное решение.
Это он меня подводил к тому, что хэш на самом деле не уникальный идентификатор, и у меня у двух разных объектов может быть одинаковый хэш. Но я затупил, и не воспользовался подсказкой
А вот персистентность нужна для дешевого перемещения между состояниями. Оправданно ли это — нет, для подавляющего большинства приложений. Но это мое мнение, и я не фронтендер, так что хз
Это ж хорошо. Зачем работать с людьми, которые так мыслят?
Я это к тому, что нужно быть где-то по середине между человеком, который живет продуктом и человеком. которому интересен ГЦ. А крайности — не работают