Здравствуйте, barn_czn, Вы писали:
_>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. Казалось бы при чем тут nemerle?
_>Всем хороша конструкция foreach (.net). _>Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции. _>Поэтому приходится вводить индексную переменную и инкрементировать ее:
_>
_>int i = 0;
_>foreach (object o in collection)
_>{
_>//any
_>i++;
_>}
_>
_>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. _>Тогда код превратится
_>
_>foreach (object o in collection)
_>{
_>//any with o.Index
_>}
_>
А чем же не подходит старый-добрый for
for (int iIndex = 0; iIndex < collection.Count; iIndex++)
{
object o = collection[iIndex];
}
Здравствуйте, LF, Вы писали:
L>>Т.е. допустишь "ошибку проуктирования"? Вах, нехорошо. LF>да, придется изворачиваться, если аналитики не продумали данное требование.
Или понять, что никакой "ошибкой проектирования" это не является.
Здравствуйте, Lloyd, Вы писали:
L>>>Зачем совать в язык функционал, который прекрасно реализуется простым методом расширения?
VD>>Для удобства?
VD>>Или может для скорости?
VD>>А может для того и другого?
VD>>Я угадал?
L>Я не понял смысл твоего поста? Ты съязвить что-ли пытался? У тебя не получилось.
Ты задал вопрос. Я попытался угадать ответы.
Вообще ежу понятно, что 99 вещей в язык можно смело не вставлять. Тот же foreach можно спокойно заменить на метод ForEach при наличии лямбд. Но таки foreach удобнее. И то что у людей возникает желание не напрягаясь получить индекс при переборе — это нормально. В C# половина фич сделана для удобства, а не из соображений дикой необходимости.
Лично я прикрутил к foreach индекс когда в 256-й раз начал изготовляться с методом IterI (коий в немерле есть почти везде). Очень жаль что в шарпе нет такой фичи как макросы. Иначе индексы в foreach-е были бы уже давно и никто бы не гнал бредятины об ошибках в проектировании и т.п.
Вообще разговоры об ошибках в проектировании — это такая своеобразная лакмусова бумажка говорящая о наличии серьезного батхерта.
Эта тема просто пронизана батхертом, что лично меня очень сильно позабавило.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
_>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. WH>Казалось бы при чем тут nemerle?
Здравствуйте, Aen Sidhe, Вы писали:
AS>Как быть с коллекциями, к которым понятие "индекс" не применимо? Как быть с коллекциями, которые не гарантируют порядок членов? В конце концов, как быть с бесконечными последовательностями?
Индекс может быть нужен не для индексации, а например, для того чтобы вывести его на экран или в ХТМЛ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, barn_czn, Вы писали:
_>Здравствуйте, minorlogic, Вы писали:
M>>Здравствуйте, barn_czn, Вы писали: M>>... _>>>Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции. M>>...
M>>Скорее всего тут foreach используется неуместно.
_>Это почему? Вам надо например пробежатся по коллекции и выбрать с 5го по 10й элемент. _>И как вы это сделаете с IEnumerable?
[c#]
foreach (var i in collection.Skip(5).Take(10))
...
[c#]
Здравствуйте, barn_czn, Вы писали:
_>>>Это почему? Вам надо например пробежатся по коллекции и выбрать с 5го по 10й элемент. _>>>И как вы это сделаете с IEnumerable?
AS>>[c#] AS>>foreach (var i in collection.Skip(5).Take(10)) AS>> ... AS>>[c#]
_>Э ребят так не честно, я предлагаю фичу на уровне языка, а вы мне решение с применением либы (LINQ). Я конечно вкурсе этого метода.
Здравствуйте, MasterZiv, Вы писали:
MZ>barn_czn wrote:
>> Собственно предлагаю нововведение: в теле foreach сделать доступной >> пропертю Index.
MZ>Лучше было бы сразу всю функциональность loop-а или (ещё лучше) iterate-тa MZ>из common lisp-а реализовать. Там абсолютно полный охват всех возможных MZ>случаев итераций.
Здравствуйте, WolfHound, Вы писали:
_>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. WH>Казалось бы при чем тут nemerle?
Здравствуйте, barn_czn, Вы писали:
_>Но LINQ тут не причем, я уже ответил в одной ветке, что не надо путать синтаксис языка с решениями уровня сборок. _>И вообще foreach совместно с LINQ смотрятся как то несуразно. LINQ в некоторм смысле позиционировался как раз для ухода от foreach, и если я принимаю решение использовать LINK то foreach мне почти не понадобится.
Оба раза мимо.
1. Не надо пихать что попало на уровень языка. Предложенный вами синтаксис абсолютно неочевиден, не проверен на элементарные юз-кейзы (вложенные foreach, наличие свойства Index у o) и противоречит общему стилю шарпа: если и вводить, то что-то вроде indexof(o). Почему введён не будет — по ссылкам из моего поста выше.
Наконец полезный выхлоп — нулевой, а с учётом необходимости проектирования, реализации, тестирования, документирования и обучения (тут же по второму кругу — уже для поддержки IDE и кучей написанных extension'ов) — так вообще отрицательный.
2. foreach — способ перечисления последовательностей. Linq — способ формирования последовательностей. Как одно избавляет от другого —
Всем хороша конструкция foreach (.net).
Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции.
Поэтому приходится вводить индексную переменную и инкрементировать ее:
int i = 0;
foreach (object o in collection)
{
//any
i++;
}
Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index.
Тогда код превратится
foreach (object o in collection)
{
//any with o.Index
}
За сслыки спасибо, почитаю.
Но LINQ тут не причем, я уже ответил в одной ветке, что не надо путать синтаксис языка с решениями уровня сборок.
И вообще foreach совместно с LINQ смотрятся как то несуразно. LINQ в некоторм смысле позиционировался как раз для ухода от foreach, и если я принимаю решение использовать LINK то foreach мне почти не понадобится.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Aen Sidhe, Вы писали:
VD>>>Индекс может быть нужен не для индексации, а например, для того чтобы вывести его на экран или в ХТМЛ. AS>>Вот уж куда-куда, а в html индекс не нужен.
IT>А на экране нужен?
_>Перебор ради перебора? Перебор ведь всегда с какой то целью делается. И часто нужен индекс
Если в процессе перебора нужен индекс, то надо использовать другие структуры данных и другие методы (for).
Если класс отдает IEnumerable значит индекс для работы не требуется, а если все таки требуется — ошибка проектирования.
А ошибки не надо сглаживать сомнительными костылями в языке.
_>>>Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет). LF>>Да ну? _>Ну да.
Linq находиться в System.Core, это часть платформы, а не какая то отдельная технология.
Здравствуйте, LF, Вы писали:
L>>Т.е. если завтра тебе придет задача "добавить номера строк в таблицу", то ты станешь перекраивать все слои приложения, не смотря на то, что задача относится исключительно к UI? LF>Конечно нет, ради такой мелочи не буду.
Т.е. допустишь "ошибку проуктирования"? Вах, нехорошо.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, WolfHound, Вы писали:
_>>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. WH>>Казалось бы при чем тут nemerle?
IT>А я вот проявил большую выдержку
Интересное решение. Конечно, синтаксис усложняется но это мелочи. Необходимость определять индекс элемента принадлежащего какому-то объединению объектов возникает не только в операторах ForEach. Поэтому общее решение необходимо искать в определении объединения объектов. Если сделать доступным свойство Index ДЛЯ ВСЕХ объектов входящих в любые объединения изменится даже стиль программирования. Можете проверить на сортировках. Понятно, для реализации такой идеи необходимо в каждом объекте входящем в объединение либо добавлять область памяти для этого индекса, либо иметь функционал для его вычисления. У себя в языке я делаю это объявляя коллекцию или все что угодно как Indexed. Тогда любой элемент добавляемый в такую коллекцию получает собственное свойство Index.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, barn_czn, Вы писали:
_>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. _>>Тогда код превратится
AS>Как быть с коллекциями, к которым понятие "индекс" не применимо? Как быть с коллекциями, которые не гарантируют порядок членов? В конце концов, как быть с бесконечными последовательностями?
Читаем внимательно заголовок — Нововведение в _foreach_.
Поэтому речь идет о коллекциях в контексте _foreach_, и если IEnumerable ведет себя каждый раз по разному — то это его проблема, введение индексной переменной все равно этого не решит. Я лиш предложил расширение синтаксиса foreach ради сокращения кол-ва кода.
_>Всем хороша конструкция foreach (.net). _>Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции.
Я думаю не так часто чтобы это стоило таких изменений в языке.
public static class Extensions
{
public sealed class Indexed<T>
{
private Indexed(T item, int index)
{
this.Item = item;
this.Index = index;
}
public T Item { get; private set; }
public int Index { get; private set; }
}
public static IEnumerable<Indexed<T>> Indexed<T>(this IEnumerable<T> seq)
{
return seq.Select( (v,i) => new Indexed<T>(v,i) );
}
public static IEnumerable<T> RemoveIndex<T>(this IEnumerable<Indexed<T>> seq)
{
return seq.Select( x => x.Item );
}
}
Здравствуйте, barn_czn, Вы писали:
_>Здравствуйте, minorlogic, Вы писали:
M>>Скорее всего тут foreach используется неуместно.
_>Это почему? Вам надо например пробежатся по коллекции и выбрать с 5го по 10й элемент. _>И как вы это сделаете с IEnumerable?
Потому что IEnumerable не предполагает обращения по индексу. Для выборок из колекции эелементов по индексу вероятно имеет смысл воспользоваться другим интерфейсом , другой коллекцией.
Здравствуйте, barn_czn, Вы писали:
_>Я и не надеюсь что сделают. В других языках вот подумали и сделали сразу (см. выше ветки, коллеги подсказывают).
lua и D мягко говоря не мейнстрим. Соответственно, требования к самому языку и добавляемым фичам слегка разнятся.
Кстати, есть тонны языков с расширяемым синтаксисом, для .Net — как минимум немерль. Вперёд
_>Противоречий никаких не вижу. Конфликты разрешить можно также как имена переменных разрешаются.
class A { public int Index { get;set; } }
// ...foreach (A o in collection)
{
//any with o.Index
}
Здравствуйте, LF, Вы писали:
_>>Ну тогда по вашей логике можно остановится. .NET 4 впринципе не нужен был уже. Да и 3.0 и 3.5 тоже, зачем вообще по вашему синтаксический сахар делают ? LF>Сахар сахару рознь.
Понимаете, возможность обратится внутри foreach к номеру перечисляемого объекта — это не просто синтакс. сахар. Это почти подсказка нерадивым программерам о том что все множества имеют много общего с множествами натуральных чисел. В частности это обображение любой коллекции на множество натуральных чисел.
Никто пока не задал вопрос о том — какой тип данных будет иметь эта проертя Index ?
Вот это действительно ставит в тупик. Но говорят что в D просто объявляют нужного типа переменную. Но тогда действительно фича примет уже не тот фундаментальный смысл.
_>Но мы то обсуждаем случай когда необходимо перебрать и в процессе перебора использовать индекс.
То что вам необходимо в переборе использовать индекс это ваша проблема, а не перебора.
Оператор перебора должен только перебирать.
_>Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет).
Да ну?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Как быть с коллекциями, к которым понятие "индекс" не применимо? Как быть с коллекциями, которые не гарантируют порядок членов? В конце концов, как быть с бесконечными последовательностями?
VD>Индекс может быть нужен не для индексации, а например, для того чтобы вывести его на экран или в ХТМЛ.
Вот уж куда-куда, а в html индекс не нужен. А так — отобрази явно на то, что тебе надо и выводи.
L>Т.е. если завтра тебе придет задача "добавить номера строк в таблицу", то ты станешь перекраивать все слои приложения, не смотря на то, что задача относится исключительно к UI?
Конечно нет, ради такой мелочи не буду.
Здравствуйте, batu, Вы писали:
B>Ну, ты царь! Я предложил индексированые коллекции, и тут же я в них не верю. Да еще мне их предстоит открыть..
Вы предложили не индексированные коллекции, а реализацию, которая хранит индекс каждого элемента в самом элементе. После чего пояснили, что в них удаление запрещено. И что ваш пользователь должен выбирать — или индексирование, или удаления.
Я вам поясняю, что бывают другие, не столь откровенно неудачные, реализации того же функционала. То есть можно построить коллекцию, которая умеет возвращать индекс для произвольного элемента, вставлять новый элемент в произвольное место, и удалять элемент из произвольного места. И все эти операции с приемлемой производительностью.
Постарайтесь следить за нитью дискуссии. У меня исчерпывается терпение повторять всё по два раза.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, barn_czn, Вы писали:
_>>Всем хороша конструкция foreach (.net). _>>Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции. _>>Поэтому приходится вводить индексную переменную и инкрементировать ее:
_>>
_>>int i = 0;
_>>foreach (object o in collection)
_>>{
_>>//any
_>>i++;
_>>}
_>>
_>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. _>>Тогда код превратится
_>>
_>>foreach (object o in collection)
_>>{
_>>//any with o.Index
_>>}
_>>
AG>А чем же не подходит старый-добрый for
AG>for (int iIndex = 0; iIndex < collection.Count; iIndex++) AG>{ AG> object o = collection[iIndex]; AG>}
Не хочу пускатся в дискуссию чем foreach лучше for, если вы про это.
А индексация collection[iIndex] например в принципе невозможна для IEnumerable (не путайте с IList).
Поэтому for вы не сможете применить для произвольного IEnumerable. Другой путь — получить IEnumerator и пройтись waile. Опять таки с индексной переменной. Но это еще хуже.
_>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. _>Тогда код превратится
Как быть с коллекциями, к которым понятие "индекс" не применимо? Как быть с коллекциями, которые не гарантируют порядок членов? В конце концов, как быть с бесконечными последовательностями?
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, barn_czn, Вы писали: M>... _>>Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции. M>...
M>Скорее всего тут foreach используется неуместно.
Это почему? Вам надо например пробежатся по коллекции и выбрать с 5го по 10й элемент.
И как вы это сделаете с IEnumerable?
В MS SQL например до недавних пор пейджинг было трудно сделать по той же причине — там не было выражения ROW_NUMBER.
Здравствуйте, barn_czn, Вы писали:
_>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Здравствуйте, barn_czn, Вы писали:
_>>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. _>>>Тогда код превратится
AS>>Как быть с коллекциями, к которым понятие "индекс" не применимо? Как быть с коллекциями, которые не гарантируют порядок членов? В конце концов, как быть с бесконечными последовательностями?
_>Читаем внимательно заголовок — Нововведение в _foreach_.
Читал вообще-то.
_>Поэтому речь идет о коллекциях в контексте _foreach_, и если IEnumerable ведет себя каждый раз по разному — то это его проблема, введение индексной переменной все равно этого не решит. Я лиш предложил расширение синтаксиса foreach ради сокращения кол-ва кода.
У меня нет индексных переменных в foreach, а foreach много. Может я что не так делаю?
Я выше привёл несколько примеров, где оно будет совершенно лишним.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, barn_czn, Вы писали:
_>>Здравствуйте, minorlogic, Вы писали:
M>>>Здравствуйте, barn_czn, Вы писали: M>>>... _>>>>Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции. M>>>...
M>>>Скорее всего тут foreach используется неуместно.
_>>Это почему? Вам надо например пробежатся по коллекции и выбрать с 5го по 10й элемент. _>>И как вы это сделаете с IEnumerable?
AS>[c#] AS>foreach (var i in collection.Skip(5).Take(6)) // конечно же, да не суть. AS> ... AS>[c#]
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, barn_czn, Вы писали:
_>>Всем хороша конструкция foreach (.net). _>>Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции. G>Я думаю не так часто чтобы это стоило таких изменений в языке.
G>
G>public static class Extensions
G>{
G> public sealed class Indexed<T>
G> {
G> private Indexed(T item, int index)
G> {
G> this.Item = item;
G> this.Index = index;
G> }
G> public T Item { get; private set; }
G> public int Index { get; private set; }
G> }
G> public static IEnumerable<Indexed<T>> Indexed<T>(this IEnumerable<T> seq)
G> {
G> return seq.Select( (v,i) => new Indexed<T>(v,i) );
G> }
G> public static IEnumerable<T> RemoveIndex<T>(this IEnumerable<Indexed<T>> seq)
G> {
G> return seq.Select( x => x.Item );
G> }
G>}
G>
G>Как использовать думаю разберешься.
Спасибо не надо, я лучше переменную буду создавать )
К тому же ваша отвертка работает только на IEnumerable<>, просто IEnumerable не прокатит (LINQ не работает). Если не ошибаюсь.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, barn_czn, Вы писали:
_>>Здравствуйте, minorlogic, Вы писали:
M>>>Здравствуйте, barn_czn, Вы писали: M>>>... _>>>>Но часто надо при пробегании по коллекции обращатся к индексу объекта в коллекции. M>>>...
M>>>Скорее всего тут foreach используется неуместно.
_>>Это почему? Вам надо например пробежатся по коллекции и выбрать с 5го по 10й элемент. _>>И как вы это сделаете с IEnumerable?
AS>[c#] AS>foreach (var i in collection.Skip(5).Take(10)) AS> ... AS>[c#]
Э ребят так не честно, я предлагаю фичу на уровне языка, а вы мне решение с применением либы (LINQ). Я конечно вкурсе этого метода.
_>Э ребят так не честно, я предлагаю фичу на уровне языка, а вы мне решение с применением либы (LINQ). Я конечно вкурсе этого метода.
Если либа дает решение, зачем что то решать на уровне языка?
Здравствуйте, barn_czn, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, barn_czn, Вы писали:
G>>Как использовать думаю разберешься.
_>Спасибо не надо, я лучше переменную буду создавать )
Угу. Лучше копипастить везде переменную и код, который её меняет и следит за нет.
_>К тому же ваша отвертка работает только на IEnumerable<>, просто IEnumerable не прокатит (LINQ не работает). Если не ошибаюсь.
Всё работает.
static void Main(string[] args)
{
var c = (IEnumerable) new List<int> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
foreach (var i in c.Cast<object>().Skip(5).Take(5))
Console.WriteLine(i);
Console.ReadKey();
}
Здравствуйте, barn_czn, Вы писали:
_>Спасибо не надо, я лучше переменную буду создавать )
Удачи.
_>К тому же ваша отвертка работает только на IEnumerable<>, просто IEnumerable не прокатит (LINQ не работает). Если не ошибаюсь.
Да, используй Cast или OfType.
barn_czn wrote:
> Собственно предлагаю нововведение: в теле foreach сделать доступной > пропертю Index.
Лучше было бы сразу всю функциональность loop-а или (ещё лучше) iterate-тa
из common lisp-а реализовать. Там абсолютно полный охват всех возможных
случаев итераций.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, barn_czn, Вы писали:
_>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, barn_czn, Вы писали:
G>>>Как использовать думаю разберешься.
_>>Спасибо не надо, я лучше переменную буду создавать )
AS>Угу. Лучше копипастить везде переменную и код, который её меняет и следит за нет.
_>>К тому же ваша отвертка работает только на IEnumerable<>, просто IEnumerable не прокатит (LINQ не работает). Если не ошибаюсь.
AS>Всё работает. AS>
AS> static void Main(string[] args)
AS> {
AS> var c = (IEnumerable) new List<int> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
AS> foreach (var i in c.Cast<object>().Skip(5).Take(5))
AS> Console.WriteLine(i);
AS> Console.ReadKey();
AS> }
AS>
Конечно, приведение к IEnumerable типа который имелементирует IEnumerable<> работать будет, куда оно денется. Попробуйте на чистом
IEnumerable, не генерик. Я точно знаю что LINQ не умеет работать с негенерик IEnumerable. А foreach работает.
Здравствуйте, LF, Вы писали:
_>>Э ребят так не честно, я предлагаю фичу на уровне языка, а вы мне решение с применением либы (LINQ). Я конечно вкурсе этого метода. LF>Если либа дает решение, зачем что то решать на уровне языка?
Ну тогда по вашей логике можно остановится. .NET 4 впринципе не нужен был уже. Да и 3.0 и 3.5 тоже, зачем вообще по вашему синтаксический сахар делают ?
Здравствуйте, barn_czn, Вы писали:
_>Конечно, приведение к IEnumerable типа который имелементирует IEnumerable<> работать будет, куда оно денется. Попробуйте на чистом _>IEnumerable, не генерик. Я точно знаю что LINQ не умеет работать с негенерик IEnumerable. А foreach работает.
var lst = new ArrayList { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
foreach (object i in lst.Cast<object>().Skip(5).Take(5))
Console.WriteLine(i);
_>Ну тогда по вашей логике можно остановится. .NET 4 впринципе не нужен был уже. Да и 3.0 и 3.5 тоже, зачем вообще по вашему синтаксический сахар делают ?
Сахар сахару рознь.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, barn_czn, Вы писали:
_>>Но LINQ тут не причем, я уже ответил в одной ветке, что не надо путать синтаксис языка с решениями уровня сборок. _>>И вообще foreach совместно с LINQ смотрятся как то несуразно. LINQ в некоторм смысле позиционировался как раз для ухода от foreach, и если я принимаю решение использовать LINK то foreach мне почти не понадобится.
S>Оба раза мимо.
S>1. Не надо пихать что попало на уровень языка. Предложенный вами синтаксис абсолютно неочевиден, не проверен на элементарные юз-кейзы (вложенные foreach, наличие свойства Index у o) и противоречит общему стилю шарпа: если и вводить, то что-то вроде indexof(o). Почему введён не будет — по ссылкам из моего поста выше.
S>Наконец полезный выхлоп — нулевой, а с учётом необходимости проектирования, реализации, тестирования, документирования и обучения (тут же по второму кругу — уже для поддержки IDE и кучей написанных extension'ов) — так вообще отрицательный.
S>2. foreach — способ перечисления последовательностей. Linq — способ формирования последовательностей. Как одно избавляет от другого —
Я и не надеюсь что сделают. В других языках вот подумали и сделали сразу (см. выше ветки, коллеги подсказывают).
Противоречий никаких не вижу. Конфликты разрешить можно также как имена переменных разрешаются.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, barn_czn, Вы писали:
_>>Но LINQ тут не причем, я уже ответил в одной ветке, что не надо путать синтаксис языка с решениями уровня сборок.
L>Зачем совать в язык функционал, который прекрасно реализуется простым методом расширения?
Здравствуйте, barn_czn, Вы писали:
L>>Зачем совать в язык функционал, который прекрасно реализуется простым методом расширения?
_>Покажите как, LINQ низя юзать.
Здравствуйте, barn_czn, Вы писали:
_>Здравствуйте, Aen Sidhe, Вы писали:
_>Конечно, приведение к IEnumerable типа который имелементирует IEnumerable<> работать будет, куда оно денется. Попробуйте на чистом _>IEnumerable, не генерик. Я точно знаю что LINQ не умеет работать с негенерик IEnumerable. А foreach работает.
Всё работает. Может вы всё-таки почитаете документацию?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections;
namespace linq.non.generic
{
class A : IEnumerable
{
#region IEnumerable Members
public IEnumerator GetEnumerator()
{
for (int i = 1; i <= 10; i++)
yield return i;
}
#endregion
}
class Program
{
static void Main(string[] args)
{
var c = new A();
foreach (var i in c.Cast<object>().Skip(5).Take(5))
Console.WriteLine(i);
Console.ReadKey();
}
}
}
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, barn_czn, Вы писали:
_>>Конечно, приведение к IEnumerable типа который имелементирует IEnumerable<> работать будет, куда оно денется. Попробуйте на чистом _>>IEnumerable, не генерик. Я точно знаю что LINQ не умеет работать с негенерик IEnumerable. А foreach работает.
L>
L>var lst = new ArrayList { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
L>foreach (object i in lst.Cast<object>().Skip(5).Take(5))
L> Console.WriteLine(i);
L>
Cast это сила.
Вы понимаете что речь идет не о мощи LINQ ?
Здравствуйте, barn_czn, Вы писали:
_>>>Конечно, приведение к IEnumerable типа который имелементирует IEnumerable<> работать будет, куда оно денется. Попробуйте на чистом _>>>IEnumerable, не генерик. Я точно знаю что LINQ не умеет работать с негенерик IEnumerable. А foreach работает.
L>>
L>>var lst = new ArrayList { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
L>>foreach (object i in lst.Cast<object>().Skip(5).Take(5))
L>> Console.WriteLine(i);
L>>
_> _>Cast это сила. _>Вы понимаете что речь идет не о мощи LINQ ?
А о чем? Cast, Skip, Take — все это часть того, что называют Linq.
Здравствуйте, barn_czn, Вы писали:
LF>>Сахар сахару рознь.
_>Понимаете, возможность обратится внутри foreach к номеру перечисляемого объекта — это не просто синтакс. сахар. Это почти подсказка нерадивым программерам о том что все множества имеют много общего с множествами натуральных чисел. В частности это обображение любой коллекции на множество натуральных чисел.
Здравствуйте, barn_czn, Вы писали:
_>Здравствуйте, LF, Вы писали:
_>>>Ну тогда по вашей логике можно остановится. .NET 4 впринципе не нужен был уже. Да и 3.0 и 3.5 тоже, зачем вообще по вашему синтаксический сахар делают ? LF>>Сахар сахару рознь.
_>Понимаете, возможность обратится внутри foreach к номеру перечисляемого объекта — это не просто синтакс. сахар. Это почти подсказка нерадивым программерам о том что все множества имеют много общего с множествами натуральных чисел. В частности это обображение любой коллекции на множество натуральных чисел.
Для отображения есть специальные методы. Отобрази, потом перебирай.
_>Никто пока не задал вопрос о том — какой тип данных будет иметь эта проертя Index ? Вот это действительно ставит в тупик. Но говорят что в D просто объявляют нужного типа переменную. Но тогда действительно фича примет уже не тот фундаментальный смысл.
_>Понимаете, возможность обратится внутри foreach к номеру перечисляемого объекта — это не просто синтакс. сахар. Это почти подсказка нерадивым программерам о том что все множества имеют много общего с множествами натуральных чисел. В частности это обображение любой коллекции на множество натуральных чисел.
Отображение на множество не имеет ничего общего с перебором. Мухи отдельно, котлеты отдельно.
Здравствуйте, LF, Вы писали:
_>>Понимаете, возможность обратится внутри foreach к номеру перечисляемого объекта — это не просто синтакс. сахар. Это почти подсказка нерадивым программерам о том что все множества имеют много общего с множествами натуральных чисел. В частности это обображение любой коллекции на множество натуральных чисел. LF>Отображение на множество не имеет ничего общего с перебором. Мухи отдельно, котлеты отдельно.
Неправда. Порядок перебора как раз и определяется тем как вы отобразили ваше множество на множество натуральных чисел. Можно конечно считать и наоборот что отображение зависит от перебора. Но мы то обсуждаем случай когда необходимо перебрать и в процессе перебора использовать индекс. Я же сразу привел проблему а потом решение которое мне нравилось бы.
Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет).
Здравствуйте, barn_czn, Вы писали:
_>Здравствуйте, LF, Вы писали:
_>>>Понимаете, возможность обратится внутри foreach к номеру перечисляемого объекта — это не просто синтакс. сахар. Это почти подсказка нерадивым программерам о том что все множества имеют много общего с множествами натуральных чисел. В частности это обображение любой коллекции на множество натуральных чисел. LF>>Отображение на множество не имеет ничего общего с перебором. Мухи отдельно, котлеты отдельно.
_>Неправда. Порядок перебора как раз и определяется тем как вы отобразили ваше множество на множество натуральных чисел. Можно конечно считать и наоборот что отображение зависит от перебора. Но мы то обсуждаем случай когда необходимо перебрать и в процессе перебора использовать индекс. Я же сразу привел проблему а потом решение которое мне нравилось бы. _>Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет).
Здравствуйте, barn_czn, Вы писали:
_>Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет).
Тебе же уже показали, что ты ошибаешься. Получение индекса вполне реализуется в рамках 2.0
Здравствуйте, MasterZiv, Вы писали:
MZ>Лучше было бы сразу всю функциональность loop-а или (ещё лучше) iterate-тa MZ>из common lisp-а реализовать. Там абсолютно полный охват всех возможных MZ>случаев итераций.
Сложновато. Даже матерые лиспари не все его семантику полностью знают. А уж учить это все...
Лучше уж разбить на несколько конструкций, как в более современных языках сделано.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Aen Sidhe, Вы писали:
VD>>Индекс может быть нужен не для индексации, а например, для того чтобы вывести его на экран или в ХТМЛ. AS>Вот уж куда-куда, а в html индекс не нужен.
А на экране нужен?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, barn_czn, Вы писали:
_>>Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет).
L>Тебе же уже показали, что ты ошибаешься. Получение индекса вполне реализуется в рамках 2.0
Ну видимо не показали.
Получение индекса впринципе конечно реализуется, я ведь сам и показал как в самом начале.
Здравствуйте, LF, Вы писали:
_>>Но мы то обсуждаем случай когда необходимо перебрать и в процессе перебора использовать индекс. LF>То что вам необходимо в переборе использовать индекс это ваша проблема, а не перебора. LF>Оператор перебора должен только перебирать.
Перебор ради перебора? Перебор ведь всегда с какой то целью делается. И часто нужен индекс
_>>Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет). LF>Да ну?
Здравствуйте, barn_czn, Вы писали:
L>>Тебе же уже показали, что ты ошибаешься. Получение индекса вполне реализуется в рамках 2.0
_>Ну видимо не показали.
Посмотри пример gandjustas-а. Теолько не смущайся наличием там Select, его можно вполне переписать и без него, с yield return.
Здравствуйте, LF, Вы писали:
_>>>>Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет). LF>>>Да ну? _>>Ну да. LF>Linq находиться в System.Core, это часть платформы, а не какая то отдельная технология.
Т.е. если завтра тебе придет задача "добавить номера строк в таблицу", то ты станешь перекраивать все слои приложения, не смотря на то, что задача относится исключительно к UI?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, barn_czn, Вы писали:
_>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. WH>Казалось бы при чем тут nemerle?
Здравствуйте, LF, Вы писали:
_>>Перебор ради перебора? Перебор ведь всегда с какой то целью делается. И часто нужен индекс LF>Если в процессе перебора нужен индекс, то надо использовать другие структуры данных и другие методы (for). LF>Если класс отдает IEnumerable значит индекс для работы не требуется, а если все таки требуется — ошибка проектирования. LF>А ошибки не надо сглаживать сомнительными костылями в языке.
Вы ерунду сейчас сказали.
Вот вам типичный пример: надо сделать метод вычисляющий сумму по i от f(x[i], i). И что, какой тип данных вы выберите для входной коллекции x ? По вашей логике тип должен имеплементировать IList (чтобы применить for). А по здравой логике минималистичных требований к входным данным — надо выбрать IEnumerable.
Посмотрите вообще как проектируются разные библитеки, например гриды. Все они принимают в качестве датасорса тип IEnumerable. И проход for-ом впринципе не работает.
Здравствуйте, VladD2, Вы писали:
L>>Зачем совать в язык функционал, который прекрасно реализуется простым методом расширения?
VD>Для удобства?
VD>Или может для скорости?
VD>А может для того и другого?
VD>Я угадал?
Я не понял смысл твоего поста? Ты съязвить что-ли пытался? У тебя не получилось.
Здравствуйте, batu, Вы писали: B>Интересное решение. Конечно, синтаксис усложняется но это мелочи. Необходимость определять индекс элемента принадлежащего какому-то объединению объектов возникает не только в операторах ForEach. Поэтому общее решение необходимо искать в определении объединения объектов. Если сделать доступным свойство Index ДЛЯ ВСЕХ объектов входящих в любые объединения изменится даже стиль программирования. Можете проверить на сортировках. Понятно, для реализации такой идеи необходимо в каждом объекте входящем в объединение либо добавлять область памяти для этого индекса, либо иметь функционал для его вычисления. У себя в языке я делаю это объявляя коллекцию или все что угодно как Indexed. Тогда любой элемент добавляемый в такую коллекцию получает собственное свойство Index.
Особенно здорово это должно работать для изменяемых коллекций. Стоит сделать Remove(0) и можно идти заваривать кофе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, batu, Вы писали: B>>Интересное решение. Конечно, синтаксис усложняется но это мелочи. Необходимость определять индекс элемента принадлежащего какому-то объединению объектов возникает не только в операторах ForEach. Поэтому общее решение необходимо искать в определении объединения объектов. Если сделать доступным свойство Index ДЛЯ ВСЕХ объектов входящих в любые объединения изменится даже стиль программирования. Можете проверить на сортировках. Понятно, для реализации такой идеи необходимо в каждом объекте входящем в объединение либо добавлять область памяти для этого индекса, либо иметь функционал для его вычисления. У себя в языке я делаю это объявляя коллекцию или все что угодно как Indexed. Тогда любой элемент добавляемый в такую коллекцию получает собственное свойство Index. S>Особенно здорово это должно работать для изменяемых коллекций. Стоит сделать Remove(0) и можно идти заваривать кофе.
Кофе получится, а Remove для Indexed-коллекций нет.
Здравствуйте, batu, Вы писали:
S>>Особенно здорово это должно работать для изменяемых коллекций. Стоит сделать Remove(0) и можно идти заваривать кофе. B>Кофе получится, а Remove для Indexed-коллекций нет.
Ну вот видите как здорово — у всех есть, а у вас нету. Получается, что решение одной проблемы (умение определять индекс по элементу) приводит к другой проблеме (невозможность удалять элементы из коллекции).
В каком-то частном случае это может и сработать, но претендовать на общее решение это никак не может.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, batu, Вы писали:
S>>>Особенно здорово это должно работать для изменяемых коллекций. Стоит сделать Remove(0) и можно идти заваривать кофе. B>>Кофе получится, а Remove для Indexed-коллекций нет. S>Ну вот видите как здорово — у всех есть, а у вас нету. Получается, что решение одной проблемы (умение определять индекс по элементу) приводит к другой проблеме (невозможность удалять элементы из коллекции). S>В каком-то частном случае это может и сработать, но претендовать на общее решение это никак не может.
Так выбор в руках пользователя. Что ему важнее в конкретном случае. Да и проблем быть не должно. Если коллекция предполагает удаление, то поиск элемента по любому усложняется.
Здравствуйте, batu, Вы писали: B>Так выбор в руках пользователя. Что ему важнее в конкретном случае. Да и проблем быть не должно. Если коллекция предполагает удаление, то поиск элемента по любому усложняется.
Я правильно понимаю, что реализацию индексированной коллекции, которая позволяет эффективные удаления элементов, вы считаете невозможной? Тогда вам предстоит открыть ещё очень много нового.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, batu, Вы писали: B>>Так выбор в руках пользователя. Что ему важнее в конкретном случае. Да и проблем быть не должно. Если коллекция предполагает удаление, то поиск элемента по любому усложняется. S>Я правильно понимаю, что реализацию индексированной коллекции, которая позволяет эффективные удаления элементов, вы считаете невозможной? Тогда вам предстоит открыть ещё очень много нового.
Ну, ты царь! Я предложил индексированые коллекции, и тут же я в них не верю. Да еще мне их предстоит открыть..
Здравствуйте, Sinclair, Вы писали:
S>Вы предложили не индексированные коллекции, а реализацию, которая хранит индекс каждого элемента в самом элементе. После чего пояснили, что в них удаление запрещено. И что ваш пользователь должен выбирать — или индексирование, или удаления. S>Я вам поясняю, что бывают другие, не столь откровенно неудачные, реализации того же функционала. То есть можно построить коллекцию, которая умеет возвращать индекс для произвольного элемента, вставлять новый элемент в произвольное место, и удалять элемент из произвольного места. И все эти операции с приемлемой производительностью. S>Постарайтесь следить за нитью дискуссии. У меня исчерпывается терпение повторять всё по два раза.
Ну, есть разные. Зачем повторяешься? Вроде я не возражал что есть другие. А если говоришь что есть лучше, чем я предложил, отошли к первоисточнику, если в лом рассказать. Имею право сомневаться.
Здравствуйте, LF, Вы писали:
_>>Э ребят так не честно, я предлагаю фичу на уровне языка, а вы мне решение с применением либы (LINQ). Я конечно вкурсе этого метода. LF>Если либа дает решение, зачем что то решать на уровне языка?
Совершенно верно! Именно поэтому foreach в Nemerle — это макрос: