Сообщение Re[31]: Аллокации от 09.07.2018 22:47
Изменено 10.07.2018 0:01 vdimas
Re[31]: Аллокации
Здравствуйте, samius, Вы писали:
S>Linq — это технология интеграции запросов в язык. Она привязана к C<T> в спецификации.
Она привязана к IEnumerable/IQueryable и соответствующим методам типов или методов расширений, типа Select, Where и т.д.
S>Linq to Objects — это одна конкретная реализация.
Это единственная реализация, которая существует поверх IEnumerable<>
Переиначить её ты не сможешь не отказавшись от самого Linq. ))
S>Linq to SQL — еще одна.
Не одна, а целый класс их, например, Linq to XML, бо IQueryable требует провайдера для своей работы и принцип его работы отличается от Linq to objects кардинально.
S>Общего между этими реализациями ничего нет кроме того, что они удовлетворяют правилам трансляции запросов.
ИМХО, не идёт никакой речи об "удовлетворении правил", иначе можно было бы использовать другие интерфейсы, отличные от IEnumerable/IEnumerable<T>.
Но их использовать нельзя.
Получается, что правило тут одно — всё прибито гвоздями к двум интерфейсам, которые компилятор "знает в лицо". ))
S>Проведем мысленный эксперимент: уберем правило трансляции запросов — запросы остаются, интеграции в язык больше нет. Что общего между реализациями? Ничего. Осталось выяснить, что же тормозит.
Осталось выяснить, как создать нетормозящие и при этом неконфликтующие собственные реализации IEnumerable<>, типа как тут:
http://www.rsdn.org/forum/dotnet/7191943.1
И сверху них накрутить Linq.
Правильный ответ выглядит как "никак". ))
Из-за причин, описанных в последнем абзаце тут:
http://www.rsdn.org/forum/dotnet/7188517.1
Моментально возникают конфликты:
S>Linq — это технология интеграции запросов в язык. Она привязана к C<T> в спецификации.
Она привязана к IEnumerable/IQueryable и соответствующим методам типов или методов расширений, типа Select, Where и т.д.
S>Linq to Objects — это одна конкретная реализация.
Это единственная реализация, которая существует поверх IEnumerable<>
Переиначить её ты не сможешь не отказавшись от самого Linq. ))
S>Linq to SQL — еще одна.
Не одна, а целый класс их, например, Linq to XML, бо IQueryable требует провайдера для своей работы и принцип его работы отличается от Linq to objects кардинально.
S>Общего между этими реализациями ничего нет кроме того, что они удовлетворяют правилам трансляции запросов.
ИМХО, не идёт никакой речи об "удовлетворении правил", иначе можно было бы использовать другие интерфейсы, отличные от IEnumerable/IEnumerable<T>.
Но их использовать нельзя.
Получается, что правило тут одно — всё прибито гвоздями к двум интерфейсам, которые компилятор "знает в лицо". ))
S>Проведем мысленный эксперимент: уберем правило трансляции запросов — запросы остаются, интеграции в язык больше нет. Что общего между реализациями? Ничего. Осталось выяснить, что же тормозит.
Осталось выяснить, как создать нетормозящие и при этом неконфликтующие собственные реализации IEnumerable<>, типа как тут:
http://www.rsdn.org/forum/dotnet/7191943.1
И сверху них накрутить Linq.
Правильный ответ выглядит как "никак". ))
Из-за причин, описанных в последнем абзаце тут:
http://www.rsdn.org/forum/dotnet/7188517.1
Моментально возникают конфликты:
пример | |
| |
Re[31]: Аллокации
Здравствуйте, samius, Вы писали:
S>Linq — это технология интеграции запросов в язык. Она привязана к C<T> в спецификации.
Она привязана к IEnumerable/IQueryable и соответствующим методам типов или методов расширений, типа Select, Where и т.д.
S>Linq to Objects — это одна конкретная реализация.
Это единственная реализация, которая существует поверх IEnumerable<>
Переиначить её ты не сможешь не отказавшись от самого Linq. ))
S>Linq to SQL — еще одна.
Не одна, а целый класс их, например, Linq to XML, бо IQueryable требует провайдера для своей работы и принцип его работы отличается от Linq to objects кардинально.
S>Общего между этими реализациями ничего нет кроме того, что они удовлетворяют правилам трансляции запросов.
ИМХО, не идёт никакой речи об "удовлетворении правил", иначе можно было бы использовать другие интерфейсы, отличные от IEnumerable/IEnumerable<T>.
Но их использовать нельзя.
Получается, что правило тут одно — всё прибито гвоздями к двум интерфейсам, которые компилятор "знает в лицо". ))
S>Проведем мысленный эксперимент: уберем правило трансляции запросов — запросы остаются, интеграции в язык больше нет. Что общего между реализациями? Ничего. Осталось выяснить, что же тормозит.
Осталось выяснить, как создать нетормозящие и при этом неконфликтующие собственные реализации IEnumerable<>, типа как тут:
http://www.rsdn.org/forum/dotnet/7191943.1
И сверху них накрутить Linq.
Правильный ответ выглядит как "никак". ))
Из-за причин, описанных в последнем абзаце тут:
http://www.rsdn.org/forum/dotnet/7188517.1
Моментально возникают конфликты:
S>Linq — это технология интеграции запросов в язык. Она привязана к C<T> в спецификации.
Она привязана к IEnumerable/IQueryable и соответствующим методам типов или методов расширений, типа Select, Where и т.д.
S>Linq to Objects — это одна конкретная реализация.
Это единственная реализация, которая существует поверх IEnumerable<>
Переиначить её ты не сможешь не отказавшись от самого Linq. ))
S>Linq to SQL — еще одна.
Не одна, а целый класс их, например, Linq to XML, бо IQueryable требует провайдера для своей работы и принцип его работы отличается от Linq to objects кардинально.
S>Общего между этими реализациями ничего нет кроме того, что они удовлетворяют правилам трансляции запросов.
ИМХО, не идёт никакой речи об "удовлетворении правил", иначе можно было бы использовать другие интерфейсы, отличные от IEnumerable/IEnumerable<T>.
Но их использовать нельзя.
Получается, что правило тут одно — всё прибито гвоздями к двум интерфейсам, которые компилятор "знает в лицо". ))
S>Проведем мысленный эксперимент: уберем правило трансляции запросов — запросы остаются, интеграции в язык больше нет. Что общего между реализациями? Ничего. Осталось выяснить, что же тормозит.
Осталось выяснить, как создать нетормозящие и при этом неконфликтующие собственные реализации IEnumerable<>, типа как тут:
http://www.rsdn.org/forum/dotnet/7191943.1
И сверху них накрутить Linq.
Правильный ответ выглядит как "никак". ))
Из-за причин, описанных в последнем абзаце тут:
http://www.rsdn.org/forum/dotnet/7188517.1
Моментально возникают конфликты:
пример | |
| |