В C# 4 вроде появилась ковариантность в каком-то виде... значит ли это, что наконец можно передавать string[] в метод, который требует object[] ?

Здравствуйте, Klatu, Вы писали:

K>В C# 4 вроде появилась ковариантность в каком-то виде... значит ли это, что наконец можно передавать string[] в метод, который требует object[] ?

Это можно было ещё в первом фреймворке.

Здравствуйте, _FRED_, Вы писали:

K>>В C# 4 вроде появилась ковариантность в каком-то виде... значит ли это, что наконец можно передавать string[] в метод, который требует object[] ?

_FR>Это можно было ещё в первом фреймворке.

Вернее, в первом шарпе.

Здравствуйте, _FRED_, Вы писали:

_FR>Это можно было ещё в первом фреймворке.

Ах действительно, для массивов можно, это для интерфейсов коллекций нельзя.
Впрочем, для массивов тоже не всегда льзя
С этим что-нибудь изменилось?

Здравствуйте, Klatu, Вы писали:

K>Ах действительно, для массивов можно, это для интерфейсов коллекций нельзя.
K>Впрочем, для массивов тоже не всегда льзя
K>С этим что-нибудь изменилось?

Для интерфейсов изменилось то, что теперь можно передавать IEnumerable<string> вместо IEnumerable<object>.
Для массивов теперь можно передавать IEnumerable<string>[] вместо IEnumerable<object>[]. Передавать int[] вместо object[] по-прежнему нельзя.

Здравствуйте, nikov, Вы писали:

N>Для интерфейсов изменилось то, что теперь можно передавать IEnumerable<string> вместо IEnumerable<object>.
N>Для массивов теперь можно передавать IEnumerable<string>[] вместо IEnumerable<object>[]. Передавать int[] вместо object[] по-прежнему нельзя.

Эх, как всё печально...

Здравствуйте, Klatu, Вы писали:

K>Эх, как всё печально...

А какое положение дел тебя бы устроило?

Здравствуйте, Klatu, Вы писали:

_FR>>Это можно было ещё в первом фреймворке.

K>Ах действительно, для массивов можно, это для интерфейсов коллекций нельзя.
K>Впрочем, для массивов тоже не всегда льзя
K>С этим что-нибудь изменилось?

Эх, такой ответ накатал, а сообщение удалено Поэтому теперь коротко — продвижек относительно массивов структур ждать и не следует. Ибо

Unfortunately, this particular kind of covariance is broken. It was added to the CLR because Java requires it and the CLR designers wanted to be able to support Java-like languages. We then up and added it to C# because it was in the CLR. This decision was quite controversial at the time and I am not very happy about it, but there’s nothing we can do about it now.

Why is this broken? Because it should always be legal to put a Turtle into an array of Animals. With array covariance in the language and runtime you cannot guarantee that an array of Animals can accept a Turtle because the backing store might actually be an array of Giraffes.

This means that we have turned a bug which could be caught by the compiler into one that can only be caught at runtime. This also means that every time you put an object into an array we have to do a run-time check to ensure that the type works out and throw an exception if it doesn’t. That’s potentially expensive if you’re putting a zillion of these things into the array.

Yuck.

здесь

Здравствуйте, _FRED_, Вы писали:

_FR>Эх, такой ответ накатал, а сообщение удалено Поэтому теперь коротко — продвижек относительно массивов структур ждать и не следует. Ибо

Ну черт с ними, это не так уж критично. Но с интерфейсами коллекций то надо хоть что-то сделать
Пусть бы сделали хотя бы рантайм проверку, как с массивами. Если их так сильно заботит производительность — можно добавить метод AddMany(T)

Здравствуйте, Klatu, Вы писали:

_FR>>Эх, такой ответ накатал, а сообщение удалено Поэтому теперь коротко — продвижек относительно массивов структур ждать и не следует. Ибо

K>Ну черт с ними, это не так уж критично. Но с интерфейсами коллекций то надо хоть что-то сделать
K>Пусть бы сделали хотя бы рантайм проверку, как с массивами. Если их так сильно заботит производительность — можно добавить метод AddMany(T)

Чт о-то не понятно, что нужно делать с интерфейсами коллекций, при чём тут производительность и как с этим связаны AddMany(T) и ковариантность?

AddMany(T) и сейчас уже можно написать для любой коллекции с помощью extension-методов.

Здравствуйте, _FRED_, Вы писали:

_FR>Чт о-то не понятно, что нужно делать с интерфейсами коллекций, при чём тут производительность и как с этим связаны AddMany(T) и ковариантность?

Сделать надо, чтобы метод IList<object> принимал ссылку на IList<SomeConcreteType>
А производительность — это та самая проблема и ее решение рантайм-чеками, про которую ты цитировал чуть выше

Здравствуйте, Klatu, Вы писали:

_FR>>Чт о-то не понятно, что нужно делать с интерфейсами коллекций, при чём тут производительность и как с этим связаны AddMany(T) и ковариантность?

K>Сделать надо, чтобы метод IList<object> принимал…

IList<object> — это не метод. Речь о каком-то конкретном методе этого интерфейса?

K>… принимал ссылку на IList<SomeConcreteType>

Для чего

Чем не подойдёт такое:

public static void AddMany<T1, T2>(this ICollection<T1> source, IEnumerable<T2> items) where T1: class, T2: class, T1 {
  foreach(var item in items) {
    source.Add(item);
  }//for
}

K>А производительность — это та самая проблема и ее решение рантайм-чеками, про которую ты цитировал чуть выше

То, что я цитировал к IList имеет мало отношения. Там чётко говорилось о массивах. И с IList нельзя делать того же, что и с массивом не потгому что так дороги рантайм-проверки, а потому-то компайл-тайм проверка гораздо лучше и именно она имеется в IEnumerable.

Здравствуйте, _FRED_, Вы писали:

K>>В C# 4 вроде появилась ковариантность в каком-то виде... значит ли это, что наконец можно передавать string[] в метод, который требует object[] ?

_FR>Это можно было ещё в первом фреймворке.

И за это надо был с работы выгнать тех ламеров кто допустил ковариантность на изменяемых структурах данных.

Здравствуйте, _FRED_, Вы писали:

_FR>IList<object> — это не метод. Речь о каком-то конкретном методе этого интерфейса?

Речь идет о методе, который принимает этот интерфейс как один из параметров.

Здравствуйте, VladD2, Вы писали:

VD>И за это надо был с работы выгнать тех ламеров кто допустил ковариантность на изменяемых структурах данных.

read-only коллекции не вложили в язык с библиотекой, вот один косяк за другой и тянет

Здравствуйте, _FRED_, Вы писали:

_FR>

_FR>Unfortunately, this particular kind of covariance is broken. It was added to the CLR because Java requires it and the CLR designers wanted to be able to support Java-like languages. We then up and added it to C# because it was in the CLR. This decision was quite controversial at the time and I am not very happy about it, but there’s nothing we can do about it now.

_FR>Why is this broken? Because it should always be legal to put a Turtle into an array of Animals. With array covariance in the language and runtime you cannot guarantee that an array of Animals can accept a Turtle because the backing store might actually be an array of Giraffes.

_FR>This means that we have turned a bug which could be caught by the compiler into one that can only be caught at runtime. This also means that every time you put an object into an array we have to do a run-time check to ensure that the type works out and throw an exception if it doesn’t. That’s potentially expensive if you’re putting a zillion of these things into the array.

_FR>Yuck.

Ага. Только врут, как всегда, немного. Конечно же сделано это не из-за того, что "Java requires it and the CLR designers wanted to be able to support Java-like languages", а потому, что первый фрэймворк был тупым клоном явы. Не задумываясь содрали и системный баг.

Самое смешное, что я практически не видел использования ковариантности для массивов на практике. Но оверхэд от этого мы имеем при любом присвоении ссылки в любой массив!

Здравствуйте, Klatu, Вы писали:

VD>>И за это надо был с работы выгнать тех ламеров кто допустил ковариантность на изменяемых структурах данных.

K>read-only коллекции не вложили в язык с библиотекой, вот один косяк за другой и тянет

А причем тут "read-only коллекции"? С каких пор массивы стали "read-only"?

Да и не использует никто ковариантность массивов. Вот ты даже не знал, что она есть.

Еще раз повторяю — это просто фича содранная с Явы. Причем содранная по глупости. Сейчас мы платим за нее понижением производительности и возможностью сделать ошибки которые до выполнения не будут обнаружены.

Здравствуйте, VladD2, Вы писали:

VD>А причем тут "read-only коллекции"? С каких пор массивы стали "read-only"?

Ни с каких
Нет никаких коллекций read-only в .NET, вообще нету. Только пакостная эмуляция на рантаймовых проверках.

VD>Да и не использует никто ковариантность массивов. Вот ты даже не знал, что она есть.

Знал, просто забыл. Я массивы вообще использую сравнительно редко.
Проблема в том, что хочется написать генерический метод просто и незатейливо — Foo(IList<T> vals)
А вот хрен тебе

Здравствуйте, Klatu, Вы писали:

VD>>И за это надо был с работы выгнать тех ламеров кто допустил ковариантность на изменяемых структурах данных.

K>read-only коллекции не вложили в язык с библиотекой, вот один косяк за другой и тянет

Всё равно не понятно — написали бы что ли пример кода

Здравствуйте, VladD2, Вы писали:

VD>Еще раз повторяю — это просто фича содранная с Явы. Причем содранная по глупости.

Не совсем так. Дизайнеры CLR и C# прекрасно понимали все издержки этого решения в Java. Но была бизнес-цель: облегчить миграцию кода, написанного на Java, на C#. И ради достижения этой цели пришлось, скрепя сердце, поддержать и эту фичу.