ОС
Не поверишь, но конструктор это тоже метод
не поверишь, но он не принимается как аргумент для функции
Size: a a a
2019 November 14
MM
проще сделать статик функцией и кидать в мап аругментом
Это поможет избежать анальных извращений с явным приведением типа при использовании маппинга?
🅵
не поверишь, но он не принимается как аргумент для функции
Я не читай, сразу отвечай.
В ооп конструктор это частный случай метода)
В ооп конструктор это частный случай метода)
MM
Не поверишь, но конструктор это тоже метод
мне всё равно, если честно)
ОС
Я не читай, сразу отвечай.
В ооп конструктор это частный случай метода)
В ооп конструктор это частный случай метода)
я по синтаксису
MM
Я вообще не думал что подожгу так чей то пукан своим сообщением с маппингом))
А вот оно как вышло.
Всё познаётся в сравнении.
Кто то пришёл сюда после js, кто то после kotlin. Кому то вообще легко всё заходит, потому что, как говорил Джейк Салли: "Моя чаша пуста".
Я всего лишь искал ответ на конкретный вопрос.
Естественно я обратился к гуглу с ошибкой, но в выдаче первым делом оказалась не документация по дарту.
Да, я конечно, должен был прочитать всю документацию. Все книги по дарту. Пройти все лабы. Бросить жену и детей, стать евангелистом дарта.
Но я как и все нормальные люди пошёл по пути наименьшего сопротивления. И попытался использовать инструмент, который мне показался интуитивно понятным.
Вполне логично, что если я указываю явно тип переменной List<ScheduledItem> и в эту переменную что то пишу, то даже на этапе компиляции можно понять ТО ли я туда запихиваю или нет
А вот оно как вышло.
Всё познаётся в сравнении.
Кто то пришёл сюда после js, кто то после kotlin. Кому то вообще легко всё заходит, потому что, как говорил Джейк Салли: "Моя чаша пуста".
Я всего лишь искал ответ на конкретный вопрос.
Естественно я обратился к гуглу с ошибкой, но в выдаче первым делом оказалась не документация по дарту.
Да, я конечно, должен был прочитать всю документацию. Все книги по дарту. Пройти все лабы. Бросить жену и детей, стать евангелистом дарта.
Но я как и все нормальные люди пошёл по пути наименьшего сопротивления. И попытался использовать инструмент, который мне показался интуитивно понятным.
Вполне логично, что если я указываю явно тип переменной List<ScheduledItem> и в эту переменную что то пишу, то даже на этапе компиляции можно понять ТО ли я туда запихиваю или нет
MM
Но оказалось всё немного сложнее. В последствии так же было выявлено, что не у одного меня бомбит от этого.
Всем кто помог мне - спасибо.
Всем кто помог мне - спасибо.
J
Вот да, возвращает иттерейбл
В котлине тоже подобные затыки есть, делаешь .map{} на массиве а тебе в итоге возвращается List а не массив
ОС
Maxim Motorniy
Это поможет избежать анальных извращений с явным приведением типа при использовании маппинга?
не в мап все равно нужно указывать тип
MM
В котлине тоже подобные затыки есть, делаешь .map{} на массиве а тебе в итоге возвращается List а не массив
везде есть приколы и недостатки
и в любом языке стремяться их сгладить
и создавая "клоунские ишью" люди надяется изменить язык к лучшему, а не принимают всё как неизбежность
и в любом языке стремяться их сгладить
и создавая "клоунские ишью" люди надяется изменить язык к лучшему, а не принимают всё как неизбежность
MM
Вот недавно встречал такой клоунский ишью с просьбой добавить екстеншн функции в дарт КАК в котлин
MM
внезапно они таки были добавлены
MM
ну в общем)
MM
будем чуточку добрее друг к другу)
SZ
В котлине тоже подобные затыки есть, делаешь .map{} на массиве а тебе в итоге возвращается List а не массив
И получишь коммайл тайм еррор
AO
Называть другие языки и предложения клоунскими, ну такое. Прям возникло желание помогать сообществу и обсуждать что-то дальше
ОС
у меня для анализатора все неявные касты считаются ошибкой и динамик нужно указывать явно
IP
Maxim Motorniy
внезапно они таки были добавлены
это политическое решения гугла, чтобы по итогу сделать дарт максимально удобным для котлин разработчиков
IP
ну или решение дарт тимы