Здравствуйте, VladD2, Вы писали:
VD>Вопрос только нужно ли это хоть кому-то? За все время кроме тебя на это вроде бы никто не замечал. Значит оно на практике никому не нужно. А делать работу ради галочки не хочется. Так что можно счесть это несущественным недостатком и забить на него.
Вообще я не так уж и редко реализую в Шарпе интерфейсы, которые отличаются только аргументами типов. Как раз приведенный пример с IConvertible весьма характерен.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вообще я не так уж и редко реализую в Шарпе интерфейсы, которые отличаются только аргументами типов. Как раз приведенный пример с IConvertible весьма характерен.
В одном типе?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, VladD2, Вы писали:
ВВ>>Вообще я не так уж и редко реализую в Шарпе интерфейсы, которые отличаются только аргументами типов. Как раз приведенный пример с IConvertible весьма характерен. VD>В одном типе?
Да, с интерфейсами такого плана как IEquatable и пр. иногда потребность возникает.
Re[3]: Реализация двух одинаковых интерфейсов в одном типе
Ну т.е. создаю я свой тип, скажем что-то типа Uri. Оно как бы удобнее, чем строка, ибо статический контроль типа и есть гарантия, что будет именно Uri, а не какая-нибудь "[htym". Сам я могу работать с ним как с Uri, но есть и другой код, который хочет IComparable<String> или что-то в этом роде.
Чуть более другой пример — делал, помнится, такой интерфейсик IRule<T>, где T специфицировало правило. Один бизнес-объект мог поддерживать несколько правил. Можно, конечно, то же самое было сделать и по-другому, но с интерфейсами получилось весьма удобна.
Re[5]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Могу завтра посмотреть, если хочешь. Идея-то достаточно простая. Типа:
Да, давай. Это будет интересно. А то что-то я себе даже представить такого не могу. Учитывая, что ошибку эту нашел только Ников, я склонен считать, что фича эта все же больше гипотетическая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, VladD2, Вы писали:
ВВ>>Могу завтра посмотреть, если хочешь. Идея-то достаточно простая. Типа: VD>Да, давай. Это будет интересно. А то что-то я себе даже представить такого не могу. Учитывая, что ошибку эту нашел только Ников, я склонен считать, что фича эта все же больше гипотетическая.
Здравствуйте, VladD2, Вы писали:
ВВ>>IEnumerable<> два раза.
VD>А как foreach понимает какой из них использовать?
Так, как написано в 8.8.4 The foreach statement: ищет публичный метод GetEnumerator без параметров. Если публичного метода нет (все интерфейсы реализованы явно), тогда ошибка — неоднозначность.
Re[8]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, VladD2, Вы писали:
ВВ>>IEnumerable<> два раза. VD>А как foreach понимает какой из них использовать?
Да, так собственно в этом и смысл-то:
var str = new ElaString("Some value");
foreach (var c in str)
Debug.WriteLine(c);
Output:
S
o
m
e
v
a
l
u
e
Foreach использует явный. А мне не нужен foreach Мне по-любому надо кастить. Причем кастить я всегда буду к IEnumerable<RuntimeValue>.
Я ж писал до этого — тут работает принцип один интерфейс "для нас", а другой — "для них". Мне на фиг не нужен этот System.Char, мне нужен RuntimeValue. Тем, кто получит объект из кода — на фиг не нужен RuntimeValue.
Re[9]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Foreach использует явный. А мне не нужен foreach Мне по-любому надо кастить. Причем кастить я всегда буду к IEnumerable<RuntimeValue>. ВВ>Я ж писал до этого — тут работает принцип один интерфейс "для нас", а другой — "для них". Мне на фиг не нужен этот System.Char, мне нужен RuntimeValue. Тем, кто получит объект из кода — на фиг не нужен RuntimeValue.
А не разумнее было бы реализовать дополнительный метод? Тогда и "кастить" не придется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, VladD2, Вы писали:
ВВ>>Foreach использует явный. А мне не нужен foreach Мне по-любому надо кастить. Причем кастить я всегда буду к IEnumerable<RuntimeValue>. ВВ>>Я ж писал до этого — тут работает принцип один интерфейс "для нас", а другой — "для них". Мне на фиг не нужен этот System.Char, мне нужен RuntimeValue. Тем, кто получит объект из кода — на фиг не нужен RuntimeValue. VD>А не разумнее было бы реализовать дополнительный метод? Тогда и "кастить" не придется.
Какой метод? Кастить мне нужно, я же не знаю тип объекта. Альтернатива сделать так:
class ElaObject
{
//Здесь свалка всех методов
}
Но это уже совсем макароны.
Re[11]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Какой метод? Кастить мне нужно, я же не знаю тип объекта. Альтернатива сделать так:
ВВ>class ElaObject ВВ>{ ВВ> //Здесь свалка всех методов ВВ>}
Для простоты понимания...
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
class MyStr : IEnumerable<char>
{
string _str;
public MyStr(string str) { _str = str; }
public IEnumerator<char> GetEnumerator()
{
foreach (var c in _str)
yield return c;
}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
public IEnumerable<string> GetOtherEnumerator()
{
foreach (var c in _str)
yield return"'" + c.ToString() + "'";
}
}
class Program
{
static void Main()
{
var s = new MyStr("test");
foreach (var x in s.GetOtherEnumerator())
Console.WriteLine(x);
}
}
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Реализация двух одинаковых интерфейсов в одном типе
Я повторю еще раз. Мне не известен тип объекта. Я не могу у него вызвать GetOtherEnumerator. Я не знаю — string это, массив или список. Я могу попробовать привести к IEnumerable<>.
Re[13]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я повторю еще раз. Мне не известен тип объекта. Я не могу у него вызвать GetOtherEnumerator. Я не знаю — string это, массив или список. Я могу попробовать привести к IEnumerable<>.
С точки зрения ООП грамотно было бы общие методы работы с объектами разместить в базовом типе. Но ты же ведь ООП не любишь. Видимо по этому и сделал вот так вот.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я повторю еще раз. Мне не известен тип объекта. Я не могу у него вызвать GetOtherEnumerator. Я не знаю — string это, массив или список. Я могу попробовать привести к IEnumerable<>.
А я должен повторить, что место GetOtherEnumerator в базовом классе?
ЗЫ
Я в своем коде необходимость апкаста воспринимаю как баг. Уж в архитектуру точно не стал бы впихивать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, VladD2, Вы писали:
ВВ>>Я повторю еще раз. Мне не известен тип объекта. Я не могу у него вызвать GetOtherEnumerator. Я не знаю — string это, массив или список. Я могу попробовать привести к IEnumerable<>. VD>С точки зрения ООП грамотно было бы общие методы работы с объектами разместить в базовом типе. Но ты же ведь ООП не любишь. Видимо по этому и сделал вот так вот.
IEnumerable<> — это и есть базовый тип.
Re[14]: Реализация двух одинаковых интерфейсов в одном типе
Здравствуйте, VladD2, Вы писали:
ВВ>>Я повторю еще раз. Мне не известен тип объекта. Я не могу у него вызвать GetOtherEnumerator. Я не знаю — string это, массив или список. Я могу попробовать привести к IEnumerable<>. VD>А я должен повторить, что место GetOtherEnumerator в базовом классе?
Сейчас ты мне пытаешься доказать, что если я использую возможность реализовать более одного интерфейса с разными генерик-параметрами, то значит у меня архитектура кривая?
Ага, фичи нет в Немерле, следовательно, она не нужна. Ну на худой конец реализуется макросами.
VD>Я в своем коде необходимость апкаста воспринимаю как баг. Уж в архитектуру точно не стал бы впихивать.
:
