Комментарии 31
На сколько удобно на Dart + Flutter писать полноценные сайты?
По поводу второго: писать удобно, но это все ещё не production ready решение.
1) Про WASM можно почитать тут https://github.com/dart-lang/sdk/issues/32894
Long story short: over the last 3 months we have hosted an intern who worked on targeting WASM+GC. He got some preliminary results: managed to implement enough of a backend working to translate a simple merge-sort benchmark. Unfortunately internship time has just run out. We are interested in driving this further, but right now we have no concrete plans, things are in discussion.
2) Сайты — пока Flutter for Web сыроват конечно. Можно послушать последний выпуск Flutter Dev подкаста, мы как раз об этом говорили https://soundcloud.com/flutterdevpodcast/20-flutter-for-web
На самом деле можно, просто игнорируя или заглушив ошибки там, где вы пока не готовы мигрировать
А есть какой-то пример, как это сделать практически? Я пытался перевести проект на null-safety, однако с флагом эксперимента проект падал на библиотеках, а без него — уже dart ругался на новые синтаксические конструкции. Если такая возможность есть, то хотелось бы уже начать ее использовать, постепенно переводя зависимости на ns.
Вот тут описаны шаги, можно посмотреть https://github.com/dart-lang/sdk/tree/master/pkg/nnbd_migration
И вот тут ещё ответ толковый https://stackoverflow.com/questions/62148950/how-to-migrate-dart-code-to-non-nullable-nnbd
Настоящее null-safety это когда ключевого слова null вообще нет в языке. А вопросики и лишние правила по сборке это костыли, которые только усложняют, а не упрощают.
ИМХО вопросики-это не костыли а нормальный способ, едиснтвенное что по-хоршему по умолчанию тип должен быть not-nullable(как тут и сделано), в отличии от других языков где в угоду обратной совместимости сделали наоборот.
Ну тут да, один неправильный дизайн накладывается на другой неправильный дизайн. В БД тоже не должно быть null, по идее. Ну тут только чего, заменять null на нулевове значение соответствующего типа, как делатся со строковыми типами, кстати.
мне кажется, что поскольку системы программирования так или иначе относятся к моделированию объектов реального мира, то null и всё с ним связанное просто неизбежно — а есть ли такой человек? может быть и нет. а есть ли заказ? его тоже может не быть. зачем мне maybe или новый объект если мне всёравно придётся обрабатывать варианты действий для да и нет. это просто огород городить, мы что будем спорить с реальностью в плане того что что-то должно быть но его нет? это часть систем, и мне кажется лучше получить ошибку nre и правильно обработать её, чем иметь какую-то странную логику с новым несуществующим объектом от базы данных когда мне просто нужно знать есть там что-то или нет. а не-nullable простыми типами можно легко пользоваться для построения цепочек вычислений проверяемых компилятором, потому что компилятор не может и не должен проверять бизнес-логику с которой связана ошибка nre. откуда ему знать, что делать если в базе нет записи которая там должна быть? создать новую, остановить систему, послать емэйл с оповещением, это же часть процессов которые компилятор не может контролировать
В объектах реального мира null-а то как раз и не существует. Допустим, вы рассказываете кому-то про человека или заказ. И вам просто необходимо будет сослаться на конкретного человека, конкретный заказ (например, заказ #123) или группу (коллекцию) людей/заказов, например, вчерашние заказы, или не оплаченные заказы. Иначе вас просто не поймут. У вас не получится рассказать о никаком заказе, хоть какие-то свойства да должны быть.
Тоже самое и в системах программирования, по крайней мере в высокоуровневых, которые оперируют объектами, а не указателями на область памяти. Либо существует ссылка на конкретный объект, либо ни объекта ни ссылки не существует. Но нет варианта когда существует ссылка в никуда.
NPE ошибку получить не проще, потому что ошибка NPE она очень техническая, она относится к тоу как процессор исполняет инструкции, и меньше относится к бизнес-логике. Одно дело NPE, другое дело ошибка "Поля abc не существует", вторая более приближена к бизнес логике и проще понять что не так и где исправлять.
Ни в том ни в другом случае естественно компилятор не может проверять бизнес-логику. Вы для этого программу и пишете.
пожалуйста:
пользователь должен был ввести слово, но ввёл пустую строку — это ""
не удалось показать пользователю ввод — это null. явно разные ситуации
дай мне из базы пользователя с I'd 1234 — нет такого пользователя (null) — тут даже не знаю что придумать… пользователь есть, но зовут его никак? как это иначе выразить без null?
мне это очень помогает в работе, не знаю может я что-то не понимаю, но мне кажется странным эти танцы вокруг null
Мне тоже кажутся странными все эти танцы вокруг null. По-моему нет null -> нет танцев и все хорошо.
не удалось показать пользователю ввод — это null. явно разные ситуации
Вы хотите показать пользователю null? Да он офигеет
нет такого пользователя (null) — тут даже не знаю что придумать…
Исключение, или Optional. Но не null.
-изменить законодательство всех стран-участников
-изменить все шаблоны документов во всех этих странах
-изменить формат обмена данными между всеми странами ТС
-ну и всем адаптировать ПО
Ненадо ничего менять, как раз по закону-то null-а не существует. Число существует, прочерк существует, null — нет. Null это уже придумали старые программисты на С++ с закостенелым мышлением, и притащили его в протоколы обмена и в код на нормальном языке программирования. Испортили-то опять все программисты, законодатели не в курсе что такое null
дай мне из базы пользователя с I'd 1234 — нет такого пользователя (null) — тут даже не знаю что придумать…
Это же абсолютно типичная ситуация, и решение тоже стандартное, ничего придумывать не надо. Метод в духе get_by_id возвращает не "пользователя", а "пользователя или ошибку". В ошибке уже конкретизируется, что пошло не так: id не зарегистрирован/нет прав на операцию/etc.
Думаю что Maybe<T>
В языках с автоматическим управлением памятью, таких как Dart, такое невозможно, там нет контроля за удалением объектов. Единственный вариант, когда ссылка X может быть null если в программе прямо написано X = null. Слово null в самом языке это проблема nullability, а не вопросики.
Никто не спорит, что в С/С++ null нужен, там есть и указатели и адресная арифметика. Но это не значит что эту концепцию надо тащить в другие языки, в которых другие концепции управления памятью. В языках типа Dart, объектно-ориентированных, не может быть null даже по смыслу. Как это, ссылка есть а объекта нет? Это нонсенс. Если нет объекта значит не должно быть переменных в которых вроде должна быть ссылка на этот объект, его же нет. Ссылка не может быть null, это против концепции ссылки на объект. Указатель на область память, к которому можно прибавить или отнять что-то — может, а ссылка на объект — нет
а как тогда строить алгоритмы, мы же не знаем что там будет? вот пример — обращаетесь к серверу, он может вернуть что-то а может ничего не вернуть. а вы же пишете программу до её выполнения, поэтому пишите как надо работать с ответом сервера. а потом оказывается что он ничего не вернул. что делать?
ну как, допустим есть JsonObject, у него есть метод has(name) который возвращает true если у объекта есть такое поле и false если нет. А если поля нет, но его значение пытаются получить то будет выброшено исключение.
Строить алгоритмы, предполагая, что никто никогда не возвращает null наоборот проще, потому что ненадо дополнительных проверок на null, собственно.
а мне это кажется гораздо более сложным, потому что что-то проверять всёравно придётся, потому что с этими данными надо же что-то делать дальше, а не просто получили и всё. но тут усложняется всё гораздо — вместо стандартной проверки на null придётся изучать принципы работы каждого объекта, чтобы проверить что у него там пошло не так. поэтому мне кажется это здорово что есть null, всегда можно вернуть что-то или ничего, вместо -1 например, что гораздо менее очевидно и более подвержено ошибкам. ошибки nre очень легко ловить и исправлять, и на этапе внедрения от 99% из них можно избавиться без труда, а вот когда какой-то алгоритм начнёт выдавать раз в 10 лет неправильные цифры потому что умножил что-то на -1 пару раз вместо ошибки, вот это будет багбаунти
Релиз Dart 2.10: на шаг ближе к null-safety