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

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

J>Хз, можно ли это красиво сделать без правок в CLR, но фича полезная и логичная была бы.


J>

J>class CollectionItem {}
J>class Collection 
J>{
J>    protected virtual CollectionItem CreateItem() {...}
J>}



J>class MyCollectionItem: CollectionItem {}
J>class MyCollection 
J>{
J>    protected override MyCollectionItem CreateItem() {...}
J>}
J>

J>В Java есть, AFAIR.

А зачем? Что мешает возвращать MyCollectionItem, там где требуется CollectionItem ? Вариантность вообще-то к дженерикам относится. А тут непонятно что.

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

K>спасибо : ) не знал про этот странный нюанс.
K>но все равно есть, что улучшать : )
K>было бы здорово, чтобы вообще без дополнительного вызова.

Этого вызова по факту не существует.

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

G>А зачем? Что мешает возвращать MyCollectionItem, там где требуется CollectionItem ?
Не что не мешает. Точно так же как ничто не мешает в наследнике MyCollection2: MyCollection в CreateItem вернуть CollectionItem. А по идее — компилятор должен мешать.

G>Вариантность вообще-то к дженерикам относится.
Перечитал несколько раз. Слова generics — не нашел. Только абстрактное "operation".

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

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

S>>Можно
S>>

S>>  public string Name {get; set;}
S>>  public Foobar(string name): this() {
S>>    Name = name;
S>>  }
S>>

K>спасибо : ) не знал про этот странный нюанс.
Ничего странного. Если рассахарить и ввести поле, то компилятор точно так же не дает обращаться к сеттеру свойства, пока не будут проиницилизированы все поля. Либо явно инициализируем введенное поле, либо неявно (вызываем конструктор по умолчанию).
K>но все равно есть, что улучшать : )
K>было бы здорово, чтобы вообще без дополнительного вызова.
Уверен что дополнительного вызова нет.

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


M>Можно не вводить, если реализуют паскалевский with.

Паскалевский with скорее зло, чем благо. Особенно когда они вложены друг в друга.
Реально что в паскале удобнее, чем в c#:
1. это явное приведение типов не (Type)exp, а Type(exp)
2. очень не хватает множеств set и операций с ними в приятном синтаксисе, а не вызове методов класса.

Здравствуйте, Аноним, Вы писали:

А>Паскалевский with скорее зло, чем благо. Особенно когда они вложены друг в друга.

Как и в JavaScript, потому что к with нет явной привязки к контексту. В VB.NET, как я понимаю, привязка есть.

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

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

G>>А зачем? Что мешает возвращать MyCollectionItem, там где требуется CollectionItem ?
J>Не что не мешает. Точно так же как ничто не мешает в наследнике MyCollection2: MyCollection в CreateItem вернуть CollectionItem. А по идее — компилятор должен мешать.
Кому должен? Ты же наследование делаешь чтобы обращаться к наследникам через ссылку на базовый класс. Соответственно непонятно зачем в наследнике менять типы, и как сообщить компилятору какой тип правильный.
Вообще есть вероятность нарушения LSP при таком поведении.

G>>Вариантность вообще-то к дженерикам относится.
J>Перечитал несколько раз. Слова generics — не нашел. Только абстрактное "operation".

http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.

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

G>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.

object obj = 1;

вот это уже ковариантность.

object[] = new int[] { 1 };

И это тоже. Дженериков нет, ковариантность есть.

S>

S>object[] = new int[] { 1 };
S>

S>И это тоже.
Тут я немного нагнал, нужны reference типы. Для строк работает, для int-ов — нет.

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

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

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

G>>>А зачем? Что мешает возвращать MyCollectionItem, там где требуется CollectionItem ?
J>>Не что не мешает. Точно так же как ничто не мешает в наследнике MyCollection2: MyCollection в CreateItem вернуть CollectionItem. А по идее — компилятор должен мешать.
G>Кому должен?
программисту.

G>Ты же наследование делаешь чтобы обращаться к наследникам через ссылку на базовый класс. Соответственно непонятно зачем в наследнике менять типы, и как сообщить компилятору какой тип правильный.
G>Вообще есть вероятность нарушения LSP при таком поведении.
"такое поведение" — это поведение MyCollection2? естественно нарушит LSP. И именно этого и поможет избежать предлагаемая фича.


G>>>Вариантность вообще-то к дженерикам относится.
J>>Перечитал несколько раз. Слова generics — не нашел. Только абстрактное "operation".

G>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
а какой реальности идет речь, если вариантность — понятие из абстрактной математики? то что ты в курсе только о вариантности делегатов и интерфейсов не означает, что это понятие нельзя применить к другим "операциям".

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

G>>Ты же наследование делаешь чтобы обращаться к наследникам через ссылку на базовый класс. Соответственно непонятно зачем в наследнике менять типы, и как сообщить компилятору какой тип правильный.
G>>Вообще есть вероятность нарушения LSP при таком поведении.
J>"такое поведение" — это поведение MyCollection2? естественно нарушит LSP. И именно этого и поможет избежать предлагаемая фича.
Как она поможет избежать? Примером кода пожалуйста.


G>>>>Вариантность вообще-то к дженерикам относится.
J>>>Перечитал несколько раз. Слова generics — не нашел. Только абстрактное "operation".

G>>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
J>а какой реальности идет речь, если вариантность — понятие из абстрактной математики? то что ты в курсе только о вариантности делегатов и интерфейсов не означает, что это понятие нельзя применить к другим "операциям".
Ты прочитал то статью? Как относится вариантность к тому что ты пишешь?

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

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

G>>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.

S>

S>object obj = 1;
S>

S>вот это уже ковариантность.
Да ну? А где здесь функтор?

S>

S>object[] = new int[] { 1 };
S>

S>И это тоже. Дженериков нет, ковариантность есть.
Array всегда был недодженериком. И эта ковариантность очень опасна, ведь можно сделать так:

object[] x = new int[] { 1 };
x[0] = new object(); //Ахтунг

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

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

S>>

S>>object obj = 1;
S>>

S>>вот это уже ковариантность.
G>Да ну? А где здесь функтор?

А зачем функтор?

S>>И это тоже. Дженериков нет, ковариантность есть.
G>Array всегда был недодженериком. И эта ковариантность очень опасна, ведь можно сделать так:
G>

G>object[] x = new int[] { 1 };
G>x[0] = new object(); //Ахтунг
G>

Тем не менее, ковариантность массивов — формальная фича C# 1.0

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

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

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

S>>>

S>>>object obj = 1;
S>>>

S>>>вот это уже ковариантность.
G>>Да ну? А где здесь функтор?

S>А зачем функтор?
А что такое вариантность вообще?

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

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

S>>>>вот это уже ковариантность.
G>>>Да ну? А где здесь функтор?

S>>А зачем функтор?
G>А что такое вариантность вообще?
Это смотря где.
А в контексте программирования под ковариантностью и контрвариантностью подразумевают взаимозаеняемость и эквивалентность типов в определенных ситуациях на основе отношений типов (частное/общее).

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

M>Приведение типов неуклюжее. Вместо

double z = (double)IntVar;

можно было б писать

double z := IntVar;

, т.е. := — это "присвоить с приведением типа к lvalue". Словесный понос надо искоренять — пусть паскалисты его тыркают.


Я не понял, почему нельзя так написать?

double z = intVar;

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

AVK>Ты не прав. Я вчера утром про этот топик рассказал Мэдсу, и позже он говорил, что ждет когда я скомпилирую суммарный документ.

Вообще есть шанс, что хоть какие-нибудь наши хотелки реализуют?

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

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

DR>Мне в Шарпе не хватает одной фичи из Немерле: foreach c индексатором, типа:

DR>

foreach (var x from collection with i)

DR>Здесь i номер текущей итерации.
в чем существенная польза? не так часто нужно, а если нужно то можно индексировать самому.
или я не так понял идею?

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

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

G>>>Ты же наследование делаешь чтобы обращаться к наследникам через ссылку на базовый класс. Соответственно непонятно зачем в наследнике менять типы, и как сообщить компилятору какой тип правильный.
G>>>Вообще есть вероятность нарушения LSP при таком поведении.
J>>"такое поведение" — это поведение MyCollection2? естественно нарушит LSP. И именно этого и поможет избежать предлагаемая фича.
G>Как она поможет избежать? Примером кода пожалуйста.

class CollectionItem {}
class Collection
{
protected virtual CollectionItem CreateItem() {...}
}



class MyCollectionItem: CollectionItem {}
class MyCollection: Collection
{
protected override MyCollectionItem CreateItem() {...}
}

class MyCollection2: MyCollection
{
// protected override CollectionItem CreateItem() {...} так ошибка компиляции, так как CollectionItem не является MyCollectionItem, ковариантность нарушится. Раз не компилируется, то LSP не сможем нарушить.
protected override MyCollectionItem CreateItem() {...} // а так вполне можно.

}


G>>>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
J>>а какой реальности идет речь, если вариантность — понятие из абстрактной математики? то что ты в курсе только о вариантности делегатов и интерфейсов не означает, что это понятие нельзя применить к другим "операциям".
G>Ты прочитал то статью? Как относится вариантность к тому что ты пишешь?

ну как, твоя статья описывает частные случаи вариантности, реализованные в C#. Какая вариантность бывает в других языках — можно на вики почитать.

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

GH>в чем существенная польза? не так часто нужно, а если нужно то можно индексировать самому.
GH>или я не так понял идею?

Мне не так уж и редко приходится оборачивать foreach в ручную реализацию for. Вот несколько сценариев:

foreach (var x in myEnum with i)
{
    if (i == 0)
        // ...
    else
        // ...
}

foreach (var x in myEnum with i)
    Console.WriteLine("{0,-2}: {1}", i + 1, x);

foreach (var x in myEnumwith i)
    DoSomething(x, myArray[i]);