AH
Да, я тоже только-только об этом подумал. Тогда вообще притензий нет. Великолепная вещь
Так работает стоковый query
Size: a a a
2020 June 07
AH
Берет твой CE, реврайтит квотейшн в сиквель по вызовам, в Run запускает этот сиквель и выдаёт енумерабл
AH
Магия.
PD
Берет твой CE, реврайтит квотейшн в сиквель по вызовам, в Run запускает этот сиквель и выдаёт енумерабл
Так откуда Run знает, откуда брать, например, подключение к бд?
AH
Так откуда Run знает, откуда брать, например, подключение к бд?
Я не помню честно говоря
AH
Судя по примерам оно работает только над Iqueryable
PD
Да и секундочку, QueryBuilder вообще не возвращает энумерабл. Он возвращает IQueryable
AH
Ну, это нормально
AH
Да и секундочку, QueryBuilder вообще не возвращает энумерабл. Он возвращает IQueryable
Да, я забыл.
оГ
Не может быть!
RM
Да, я тоже только-только об этом подумал. Тогда вообще притензий нет. Великолепная вещь
Я однажды квотейшены сириализовал так и передавал на другую машину для исполнения.
Забавно и круто получилось
Забавно и круто получилось
СС
Привет всем. Я только не давно стал приглядываться к F#, прочитал несколько статей, но не могу понять одной важной штуки.
У меня сложилось впечатление, что в F# при решении любых задач сама суть решения задвинута в самый конец алгоритма, стоит позади ВСЕХ мелких обобщенных частностей. Чтобы понять, ЧТО делает функция, необходимо смотреть на неё сзади), потому что впереди будет всякий вспомогательный хлам, который не даёт понимания назначения этой функции. Мне кажется, такая "математичность" не полезна при решении любых конкретных проблем, так как не позволяет СПЕРВА разбить большую задачу на подзадачи, решение которых можно описать ПОТОМ. Поэтому не покидает ощущение, что я неправильно понимаю F#. Но чего именно я не понимаю?)
У меня сложилось впечатление, что в F# при решении любых задач сама суть решения задвинута в самый конец алгоритма, стоит позади ВСЕХ мелких обобщенных частностей. Чтобы понять, ЧТО делает функция, необходимо смотреть на неё сзади), потому что впереди будет всякий вспомогательный хлам, который не даёт понимания назначения этой функции. Мне кажется, такая "математичность" не полезна при решении любых конкретных проблем, так как не позволяет СПЕРВА разбить большую задачу на подзадачи, решение которых можно описать ПОТОМ. Поэтому не покидает ощущение, что я неправильно понимаю F#. Но чего именно я не понимаю?)
AH
Привет всем. Я только не давно стал приглядываться к F#, прочитал несколько статей, но не могу понять одной важной штуки.
У меня сложилось впечатление, что в F# при решении любых задач сама суть решения задвинута в самый конец алгоритма, стоит позади ВСЕХ мелких обобщенных частностей. Чтобы понять, ЧТО делает функция, необходимо смотреть на неё сзади), потому что впереди будет всякий вспомогательный хлам, который не даёт понимания назначения этой функции. Мне кажется, такая "математичность" не полезна при решении любых конкретных проблем, так как не позволяет СПЕРВА разбить большую задачу на подзадачи, решение которых можно описать ПОТОМ. Поэтому не покидает ощущение, что я неправильно понимаю F#. Но чего именно я не понимаю?)
У меня сложилось впечатление, что в F# при решении любых задач сама суть решения задвинута в самый конец алгоритма, стоит позади ВСЕХ мелких обобщенных частностей. Чтобы понять, ЧТО делает функция, необходимо смотреть на неё сзади), потому что впереди будет всякий вспомогательный хлам, который не даёт понимания назначения этой функции. Мне кажется, такая "математичность" не полезна при решении любых конкретных проблем, так как не позволяет СПЕРВА разбить большую задачу на подзадачи, решение которых можно описать ПОТОМ. Поэтому не покидает ощущение, что я неправильно понимаю F#. Но чего именно я не понимаю?)
Это порядок компиляции. Сначала модели, потом логика, потом инфраструктура, потом клей (ентрипоинт)
AH
Так на любом языке пишут. Если хотят читаемый код!
СС
в c# я привык к методам в несколько строк. например, в главном методе я пишу вызовов трёх других методов, которые я потом опишу НИЖЕ (можно даже и в теле главного метода), так как не в них суть, а в тех самых трёх вызовах - именно они описывают решение задачи. Такой код весьма неплохо читается. Глядя на главный метод я СРАЗУ вижу решение, а не вынужден выискивать его в самом конце.
((
Разница лишь в том что выше или ниже?
СС
конечно. это же разница в том что важнее: мелкие детали или суть решения.
AH
в c# я привык к методам в несколько строк. например, в главном методе я пишу вызовов трёх других методов, которые я потом опишу НИЖЕ (можно даже и в теле главного метода), так как не в них суть, а в тех самых трёх вызовах - именно они описывают решение задачи. Такой код весьма неплохо читается. Глядя на главный метод я СРАЗУ вижу решение, а не вынужден выискивать его в самом конце.
Но это вопрос привычки. Почти любая кодобаза на сишарпе - спагетти с зацикленными ссылками, что делает её гораздо сложнее для понимания.
В фшарпе ты такого не увидишь.
В фшарпе ты такого не увидишь.
Н
конечно. это же разница в том что важнее: мелкие детали или суть решения.
А если от методов перейти к классам - например, основной + вспомогательные, каждый класс в своем файле, отсортированы по имени файла, как найти где мелкие детали, а где суть?)
AH
конечно. это же разница в том что важнее: мелкие детали или суть решения.
Фшарп всегда позволяет говнокодить как в сишарпе с зацикленными ссылками на типы и методы