Здравствуйте, LF, Вы писали:
_>>>>Решения с помощью LINQ я сразу отмел, потому что это отдельная технология, это не фича языка (без добавления сборок LINQа нет). LF>>>Да ну? _>>Ну да. LF>Linq находиться в System.Core, это часть платформы, а не какая то отдельная технология.
Т.е. если завтра тебе придет задача "добавить номера строк в таблицу", то ты станешь перекраивать все слои приложения, не смотря на то, что задача относится исключительно к UI?
L>Т.е. если завтра тебе придет задача "добавить номера строк в таблицу", то ты станешь перекраивать все слои приложения, не смотря на то, что задача относится исключительно к UI?
Конечно нет, ради такой мелочи не буду.
Здравствуйте, LF, Вы писали:
L>>Т.е. если завтра тебе придет задача "добавить номера строк в таблицу", то ты станешь перекраивать все слои приложения, не смотря на то, что задача относится исключительно к UI? LF>Конечно нет, ради такой мелочи не буду.
Т.е. допустишь "ошибку проуктирования"? Вах, нехорошо.
Здравствуйте, LF, Вы писали:
L>>Т.е. допустишь "ошибку проуктирования"? Вах, нехорошо. LF>да, придется изворачиваться, если аналитики не продумали данное требование.
Или понять, что никакой "ошибкой проектирования" это не является.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, barn_czn, Вы писали:
_>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. WH>Казалось бы при чем тут nemerle?
Здравствуйте, WolfHound, Вы писали:
_>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. WH>Казалось бы при чем тут nemerle?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, WolfHound, Вы писали:
_>>>Собственно предлагаю нововведение: в теле foreach сделать доступной пропертю Index. WH>>Казалось бы при чем тут nemerle?
IT>А я вот проявил большую выдержку
Интересное решение. Конечно, синтаксис усложняется но это мелочи. Необходимость определять индекс элемента принадлежащего какому-то объединению объектов возникает не только в операторах ForEach. Поэтому общее решение необходимо искать в определении объединения объектов. Если сделать доступным свойство Index ДЛЯ ВСЕХ объектов входящих в любые объединения изменится даже стиль программирования. Можете проверить на сортировках. Понятно, для реализации такой идеи необходимо в каждом объекте входящем в объединение либо добавлять область памяти для этого индекса, либо иметь функционал для его вычисления. У себя в языке я делаю это объявляя коллекцию или все что угодно как Indexed. Тогда любой элемент добавляемый в такую коллекцию получает собственное свойство Index.
Здравствуйте, LF, Вы писали:
_>>Перебор ради перебора? Перебор ведь всегда с какой то целью делается. И часто нужен индекс LF>Если в процессе перебора нужен индекс, то надо использовать другие структуры данных и другие методы (for). LF>Если класс отдает IEnumerable значит индекс для работы не требуется, а если все таки требуется — ошибка проектирования. LF>А ошибки не надо сглаживать сомнительными костылями в языке.
Вы ерунду сейчас сказали.
Вот вам типичный пример: надо сделать метод вычисляющий сумму по i от f(x[i], i). И что, какой тип данных вы выберите для входной коллекции x ? По вашей логике тип должен имеплементировать IList (чтобы применить for). А по здравой логике минималистичных требований к входным данным — надо выбрать IEnumerable.
Посмотрите вообще как проектируются разные библитеки, например гриды. Все они принимают в качестве датасорса тип IEnumerable. И проход for-ом впринципе не работает.
Здравствуйте, VladD2, Вы писали:
L>>Зачем совать в язык функционал, который прекрасно реализуется простым методом расширения?
VD>Для удобства?
VD>Или может для скорости?
VD>А может для того и другого?
VD>Я угадал?
Я не понял смысл твоего поста? Ты съязвить что-ли пытался? У тебя не получилось.
Здравствуйте, Lloyd, Вы писали:
L>>>Зачем совать в язык функционал, который прекрасно реализуется простым методом расширения?
VD>>Для удобства?
VD>>Или может для скорости?
VD>>А может для того и другого?
VD>>Я угадал?
L>Я не понял смысл твоего поста? Ты съязвить что-ли пытался? У тебя не получилось.
Ты задал вопрос. Я попытался угадать ответы.
Вообще ежу понятно, что 99 вещей в язык можно смело не вставлять. Тот же foreach можно спокойно заменить на метод ForEach при наличии лямбд. Но таки foreach удобнее. И то что у людей возникает желание не напрягаясь получить индекс при переборе — это нормально. В C# половина фич сделана для удобства, а не из соображений дикой необходимости.
Лично я прикрутил к foreach индекс когда в 256-й раз начал изготовляться с методом IterI (коий в немерле есть почти везде). Очень жаль что в шарпе нет такой фичи как макросы. Иначе индексы в foreach-е были бы уже давно и никто бы не гнал бредятины об ошибках в проектировании и т.п.
Вообще разговоры об ошибках в проектировании — это такая своеобразная лакмусова бумажка говорящая о наличии серьезного батхерта.
Эта тема просто пронизана батхертом, что лично меня очень сильно позабавило.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>Я правильно понимаю, что реализацию индексированной коллекции, которая позволяет эффективные удаления элементов, вы считаете невозможной? Тогда вам предстоит открыть ещё очень много нового.
Ну, ты царь! Я предложил индексированые коллекции, и тут же я в них не верю. Да еще мне их предстоит открыть..
Если криво делать, то нужен.
Если нам не помогут, то мы тоже никого не пощадим.
