Re: Чего не хватает в C#?
От: xvost Германия http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата: 08.12.05 07:19
Оценка: 66 (7) +5 -1
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Извините, если уже было. Просто наболело. Если есть чем поделиться — присоединяйтесь!


Лично мне очень не хватает маленького синтаксического сахара — еще одного уровня вложенности. Т.е. хочется чтобы можно было объявлять методы и поля внутри пропертей с видимостью "private", и чтобы к ним никто не имел доступа извне проперти.

Наиболее частый юзкейс:


public int P
{
  private int field;
  get{return field;}
  set {field = value;}
}


Цель — чтобы никто не мог даже изнутри класса достучатся до поля минуя сеттер/геттер проперти
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Re[3]: Чего не хватает в C#?
От: jorj  
Дата: 08.12.05 12:08
Оценка: -10 :)
Здравствуйте, Кирилл Осенков, Вы писали:
...
КО>Или пойти ещё дальше — ввести новое условно-ключевое слово (например, inner):
...

А можно еще дальше пойти — реализовать в Application метод DoAllWhatYouWant();
В методе main делается вызов Application.DoAllWhatYouWant(); и все приложение написано.
Компилятор за вас сгенерит весь код.
Re[2]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 09.12.05 10:05
Оценка: +1 :))) :))) :))) :)
Здравствуйте, dimchick, Вы писали:

D>Дмитро Ніконов (Microsoft)

D>Сьогодні розробники використовують одну мову програмування для написання вихідного коду програми, і зовсім іншу мову, наприклад SQL, для доступу до даних із СУБД. А якщо створити одну мову, що зможе достукатися й до даних об'єкта і до даних із СУБД, і до даних у форматі XML? Нове розширення до Visual Studio за назвою LINQ (Language Integrated Query) дозволяє писати запити до даних будь-якого формату й звертатися до об'єктів .NET, даних із XML і баз даних однаковим способом. У доповіді будуть продемонстровані можливості LINQ у новій версії Visual Studio, а також буде розказано про плани Microsoft у даній області.

Ничерта не понял, но очень интересно
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[6]: Чего не хватает в C#?
От: Аноним  
Дата: 09.12.05 11:34
Оценка: +1 -9
Мне не приходило в голову выгрузить 100тыс юзеров со всеми атрибутами из базы, чтобы потом часть атрибутов в том же произвольном порядке запихнуть в массив. Ради бога, замените string[] на грязное ругательство, побалуйтесь мумпсоподобным синтаксисом, удовлетворитесь любым другим способом, но без тормозов и с обратной совместимостью
Re[6]: Чего не хватает в C#?
От: jorj  
Дата: 08.12.05 14:01
Оценка: 3 (1) -8
Здравствуйте, ie, Вы писали:

...
ie>Примеры можно приводить и приводить. Но заставят ли они Вас думать по другому, если для того, чтобы посмотреть в сторону 2.0 Вам нужна задача нерешаемая в 1.1

Нет не решаемых задач, есть кривые руки...
Re[5]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 08.12.05 13:47
Оценка: 28 (6) +2
Здравствуйте, <Аноним>, Вы писали:

ie>>Да вот не получается как-то. После того как попишешь на 2.0 с месяцок, на 1.1 почему-то не тянет.


А>Я по сабжу понял, у вас проблемно со всеми версиями? Давайте с примерами и иллюстрациями. Типа, писал-писал, под 1.1 и вот оно встало... Потом взял 2.0 — встало в другом месте...


Хмм... Даже не знаю что Вам на такое ответить. Может быть я просто человек такой, но для меня писать код и писать код с удовольствием немного не эквивалентные вещи.
Многое из 1.1 мне мешало получать это самое удовольствие.
В 1.1 мне очень мешало отсутствие дженериков:
— Вместо того, чтобы писать:
  List<User> users = new List<User>();
  ...
  User usr = users[index];
  users[index] = usr;

приходилось создавать типизированные коллекции.
— Для того, чтобы создать событие с некоторой сигнатурой приходилось создавать не только наследника EventArgs, но и ненужный в 2.0 делегат:
  public event EventHandler<MyEventArgs> MyEvent;

Это очень простые примеры и они уже говорят о многом.

Частичные (partial) классы. Даже не думал, что эта на мой первый взгляд абсолютно ненужная вещь, сможет мне сэкономить столько времени. Была библиотека, которая генерилась ASN1c (могу ошибаться в названии) кодогенератором и классы которой приходилось расширять своим функционалом. Перегенерация кода могла производиться 3-4 раза на неделе и добавление слова partial в декларацию класса — это максимум чем я платил после очередной итерации.

Итераторы. А приходилось Вам встречаться с задачей: Есть список пользователей, нужен список имен пользователей. Мне — не раз.
Что я делал в 1.1:
    public string[] UserNames
    {
            get
            {
                    int count = _users.Count;
                    string[] names = new string[count];
                    for (int i = 0; i < count; i++)
                    {
                            names[i] = ((User)_users[i]).Name;
                    }
                    return names;
            }
    }

в 2.0:
    public IEnumerator<string> UserNames
    {
            get
            {
                    foreach (User u in _users)
                            yield return u.Name;
            }
    }

буду делать в 3.0:
    public IEnumerator<string> UserNames
    {
            get
            {
                    return _users.Select(u=>u.Name);
            }
    }


Примеры можно приводить и приводить. Но заставят ли они Вас думать по другому, если для того, чтобы посмотреть в сторону 2.0 Вам нужна задача нерешаемая в 1.1
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[3]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.12.05 11:04
Оценка: 28 (4) +2
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Здравствуйте, xvost, Вы писали:


X>>Лично мне очень не хватает маленького синтаксического сахара — еще одного уровня вложенности. Т.е. хочется чтобы можно было объявлять методы и поля внутри пропертей с видимостью "private", и чтобы к ним никто не имел доступа извне проперти.

КО>А кстати неплохая идея! Инкапсуляция revisited. Только что понял, что мне тоже не нравится, что поле-носитель свойства как бы отдельно. Вплоть до мелочей, что XML-комментарий к свойству или атрибуты отделяют переменную от свойства. А так было бы всё хорошо сгруппировано.
КО>Конечно, возможность использовать внешние поля (как сейчас) тоже нужно оставить.

КО>Или пойти ещё дальше — ввести новое условно-ключевое слово (например, inner):

КО>
КО>public int Number
КО>{
КО>  get {return inner;}
КО>    set {inner = value;}
КО>}
КО>

КО>Чтобы: если внутри свойства упоминается слово inner, компилятор бы автоматически генерировал private поле нужного типа. Если не упоминается — тогда ничего и не генерировать.
Кстати, интересная мысль. Вот для евентов же дефолтные поля генерятся вместе с кодом add и remove!
Если ввести что-то типа ключевого слова inner, то можно как раз делать разные забавные штуки:
1. Проперть с дефолтной реализацией:
public int Number {};

эквивалентное следующему:
public int Number
{
   get 
     { return inner; } 
     set
     { inner = value; }
}


2. Возможность настраивать поведение евентов без нужды вводить переменную:
public event EventHandler SettingsChanged
{
  add 
  {
      inner+= value;
        value(this); // notify subscriber immediately
    }
    remove
    { 
      inner-= value;
    }
}

3. Уменьшение вероятности ошибки при копировании свойств через буфер.
Я понимаю, что Настоящие Пацаны всегда набирают код руками, но те, кто пользуется клипбордом рискуют нарваться на
public string FirstName
{
    get {    return _firstName; }
    set {    _firstName = value;    }
}

public string LastName
{
    get    {    return _lastName;    }
    set { _firstName = value; }
}
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 09.12.05 13:11
Оценка: +6
Здравствуйте, <Аноним>, Вы писали:

ie>>Код который я привел был написан исключительно для примера. Тебе знакомо такое понятие — пример. Если не нравится пример с юзерами, замени User на DirectoryInfo.


А>Ааа... Так надо сразу было написать, что это, типа, книжка такая есть.


Какая книжка??? Ты бредишь!

А>Ты для примера года три побарабань по клаве, оттестируй, сдай, зайди за новой версией, перепиши, оттестируй, сдай...


Я не понимаю цели твоих постов. Я поддерживаю систему написаную на 1.1, которая существует уже много лет. Пишу к ней новые модули на 1.1. Действительно, переносить на 2.0 не рискуем. Тока не вижу причин начинать новые проекты на 1.1.

Все пора прекращать эту глупую дискуссию.. Не знаю что ты мне пытаешься доказать, но адекватности в твоих рассуждениях я не заметил.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[3]: Чего не хватает в C#?
От: Andrbig  
Дата: 08.12.05 12:50
Оценка: :))) :))
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Чтобы: если внутри свойства упоминается слово inner, компилятор бы автоматически генерировал private поле нужного типа.


С автогенерируемым названием, т.е. меняющимся от компиляции к компиляции — чтоб отбить любителей рефлекшена.
Re[2]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 19.12.05 10:50
Оценка: +5
Здравствуйте, dotter, Вы писали:

D>Иногда, когда отлаживаешся, нужно отключить блок try — catch, чтобы программа вывалилась на ошибку в правильном месте.

Чтобы VS 2005 вываливалась на first-chance exception, т.е. там, где оно собственно бросается, достаточно пойти в Debug -> Exceptions (Ctrl+Alt+E) и там всё настроить. Инструментировать код в данном случае вообще не нужно (если я правильно понял исходный постинг).
Re[7]: Чего не хватает в C#?
От: Mab Россия http://shade.msu.ru/~mab
Дата: 24.12.05 11:16
Оценка: 67 (2) +2
Здравствуйте, adontz, Вы писали:

A>Всегда можно сравнить побитово.

Побитовое представление объекта в .NET -- вещь не постоянная из-за компактификации кучи. Так что его использовать в принципе нельзя.
Кроме того, ты не учитываешь, что побитовое равенство нас почти никогда не интересует. Интересует семантическое равенство, которое начинает отличаться от побитового уже когда в составе сравниваемых объектов появляются ссылки.

A>А в STL все используют оператор < и предикат less. На самом же деле вместо того чтобы сортировать объекты ты предлагаешь брать хеши объектов и сортировать уже их.

Очень странная идея. Зачем сортировать хеши?

A>Более того, что обозначает хеш? Он ничего не обозначает! Если значения возвращённые GetHashCode() двух объектов равны, то возможно, равны и сами объекты.

Именно поэтому в тех случаях, где хочется сравнивать объекты на равенство, нужно перегружать еще и object.Equals.

A>К тому же чтобы получить хеш сложного типа надо испотльзовать все его значимые поля, а чтобы сравнить, скорее всего первые несколько. Например чтобы получить хеш строки надо обработать все её символы, а чтобы сравнить две строки, возможно только первый.

При грамотной реализации время вычисления хеша, во-первых, невелико, а во-вторых, может быть сведено к O(1), если хеш кешировать в объекте. Для линейного порядка никакое кеширование в принципе не применимо.

A>Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net

Это не верно. Есть принципально два способа огранизации коллекций, поддерживающих быстрый поиск. Первый -- использование отношения линейного порядка и, соответственно, деревьев поиска. Это решение реализовано в STL. Время поиска при таком подходе -- гарантированно логарифмическое.

Второй способ -- хеширование. Здесь есть более гибкий tradeoff между объемом занимаемой памяти и временем поиска (напомню, что матожидание времени поиска в хештаблице составляет O(-\log(1-\alpha)), где \alpha -- коэффициент заполнения; таким образом, если мы можем позволить себе, скажем, двукратный оверхед по памяти, то матожидание будет O(1)). Это решение используется в .NET, Java, а также некоторых нестандартных расширениях STL (hash_map).

Важно понимать, что эти два способа существенно различны по своей природе, у каждого свои плюсы и недостатки. Плюсы у хешей: 1) хеш коррелирует лишь с понятием равенства объектов и не обязывает вводить линейный порядок; 2) хеш -- свойство одного объекта, а не пары, так что может быть кеширован; 3) хештаблица в типичных usecases быстрее, чем дерево поиска.
Re[2]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 08.12.05 11:37
Оценка: 9 (1) +2 -1
Здравствуйте, xvost, Вы писали:

X>Лично мне очень не хватает маленького синтаксического сахара — еще одного уровня вложенности. Т.е. хочется чтобы можно было объявлять методы и поля внутри пропертей с видимостью "private", и чтобы к ним никто не имел доступа извне проперти.

А кстати неплохая идея! Инкапсуляция revisited. Только что понял, что мне тоже не нравится, что поле-носитель свойства как бы отдельно. Вплоть до мелочей, что XML-комментарий к свойству или атрибуты отделяют переменную от свойства. А так было бы всё хорошо сгруппировано.
Конечно, возможность использовать внешние поля (как сейчас) тоже нужно оставить.

Или пойти ещё дальше — ввести новое условно-ключевое слово (например, inner):
public int Number
{
  get {return inner;}
    set {inner = value;}
}

Чтобы: если внутри свойства упоминается слово inner, компилятор бы автоматически генерировал private поле нужного типа. Если не упоминается — тогда ничего и не генерировать.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[3]: Чего не хватает в C#?
От: Шахтер Интернет  
Дата: 23.12.05 19:31
Оценка: :))) :)
Здравствуйте, Gaperton, Вы писали:

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


ie>>Здравствуйте, Кирилл Осенков, Вы писали:


ie>>Еще хотелось бы что-то вроде:


ie>>
ie>>if (num in [1, 2, 3])
ie>>{
ie>>    ...
ie>>}
ie>>if (obj in<MyObjComparer> [obj1, obj2, obj3])
ie>>{
ie>>    ...
ie>>}
ie>>


G>Как то скромненько. Хотеть, так уж так хотеть как следует, чтоб не вредно было:


G>
G>if( num in fib = 1:1:[ a+b | (a,b) in zip(fib, tail(fib)) ] )
G>{
G>...
G>}
G>


G>Короче, закрый один глаз и загадай желание


Долой синтаксический оверхед!

if( num in <1,1,(_1+_2,)*> )
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 20:49
Оценка: 44 (3)
Понимаю, что большинство из описанных ниже улучшений вряд ли появятся в Шарпе, но уж если мечтать, то по полной программе.

Все дальнейшие расуждения делаются отталкиваясь от C# 3.0. Если это не так оговорюсь отдельно.

1. Введение в язык понятия функциональный тип. Отличия от делегата следующие. Может ссылатьсч только одну функцию/метод. Тип определяется сочетанием списка формальных параметров с типом возвращаемых значений, а не именем (как это происходит с делегатом). Это позволит автоматически приводить любую функцию к такому типу если она подходит по параметрам. Для такого типа должен быть реализовано атоматический вывод типов. Так код вроде:
var f = (a, b) => a * b;

должен порождать переменную f тип которой является функциональным типом о котором шла речь.
Понятное дело, что функциональные типы должны быть совместимыми с соответсвтующими делегатами.
2. (Ко/контр)вариантность где только это можно. То есть для всего что работает со ссылочными типами начиная от методов, свойств индексеров и кончая интерфейсами и колекциями.
3. Замена приведений типов с С-стиля на функциональный стиль. Например, вместо:
A a = (A)b;

будет писаться:
A a = A(b);

4. Устранение оператора "as" и введение конструкции "var if" выглядящей следующим образом:
var if (b = a as B)
{
    b.A_Method();
}

или
var if (b = a as B)
    b.A_Method();

смысл таков. Если "a" в данной точке приводится к типу "B", то в рамках блока идущего за закрывающей скобокй в будет интерпретироваться как "a" привденная к типу "B". Если приведение невозможно, то управление не должно передаваться внутрь вложенного блока.
Как развитие оператора можно добавить к нему конструкцию "else":
var if (b = a as B)
    b.A_Method();
else var if (c = a as С)
    c.A_Method();
else 
    throw new MyException(...);

5. Ввести у объектов идентификатор типа чтобы были возможно использовать их в switch:
switch (someObj.TypeId)
{
    case typeof(A).TypeId: ... break;
    case typeof(C).TypeId: ... break;
    case typeof(D).TypeId: ... break;
    case typeof(E).TypeId: ... break;
}

6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".
7. Позволить описывать анонимные типы и повзолить автоматическое приведение между анонимными типами содержащими одинаковый набор полей, а так же между обычными типами и анонимными типами если они обладают одинаковой структурой.
8. Добавление реализации (миксины, трэтсы).
interface ITest
{
    int Method1();
    string Property1 { get; }
}

class Test<T> : T
    where T : ITest
{
    public void Method2()
    {
        int i = Method1();
        Console.WriteLine(i);
    }
    
    public override Property1 { get { return 123; }}
}

abstract class TestImplementor1 : ITest
{
    public int Method1()
    {
        string s = Property1;
        return int.Parse(s);
    }
    
    abstract string Property1 { get; }
}

abstract class TestImplementor2 : ITest
{
    public int Method1()
    {
        string s = Property1;
        return int.Parse(s) * 100;
    }
    
    abstract string Property1 { get; }
}

class Program
{
    static void Main()
    {
        var test1 = new Test<TestImplementor1>();
        test1.Method2();

        var test2 = new Test<TestImplementor2>();
        test2.Method2();
    }
}

Этот код должен выводить на консоль:
123
12300

9. Добавить возможность давать кострэйны на делегаты и статические методы/свойства.
10. Ввести в язык некие синтаксические макросы позволяющие заниматься метапрограммированием и переписать весь синтаксический сахар них. Так из языка должны уйти: foreach, итераторы, switch для строк (да и новый switch для объектов), using () и т.п. Вместо этого должна появиться стандартная мета-библиотека в которой должны присутствовать реализации для всех вышеперечисленных сладостей. Определение мета-макросов дожно быть максимально декларативным чтобы допускать рефакторинг кода созданного на их основе.
metamacro "using" CodeEmitFunc
{
    "using" "(" LocalVarDecl ")"
        Block
}

Stattments CodeEmitFunc(Scope scope)
{
    // Читаем код макроса из scope, генерируем на его основе
  // окончательный код и возвращаем его из метода.
}

11. Декларативные свойства:

int Property1 var { get; set; } // свойство со скрытой переменной
// объявление своства доступного только на чтение и приватной переменной 
// _field2 используемой для хранения значения свойства.
int Property2 var _field2 { get; }

12. Вложенные области видиости в типах:
class A
{
    { // задает локальную область видимости
        public int SomePublicFunc()
        {
            return ScopedPrivateFunc();
        }
        
        // Функция видна только в рамках данной области видиомости.
        private int ScopedPrivateFunc()
        {
            return PrivateFunc(); // ОК! Это "глобальная" private-функция.
        }
    }

    private int PrivateFunc()
    {
        return 123;
    }

    public int SomeAnotherPublicFunc()
    {
         // Ошибка! Функции из локальных областей не видны за их пределами!
        return ScopedPrivateFunc();
    }
}

Это решение позволит локализовывать реализации разных сложных методов улучшая инкапсуляцию. Хорошая замена вложенным методам и вложенным типам.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 07.12.05 16:33
Оценка: 26 (3)
Ковариантности:
http://blogs.msdn.com/cyrusn/archive/2004/12/08/278661.aspx
http://blogs.msdn.com/cyrusn/archive/2004/06/18/159671.aspx
Голосовать здесь

Более красивого решения с IEnumerator и IEnumerator<T>:
http://blogs.msdn.com/cyrusn/archive/2005/03/23/401173.aspx

where T : enum
http://blogs.msdn.com/cyrusn/archive/2005/03/23/400844.aspx

а также

mix-ins
делегатов, указывающих на свойства (property delegates)
и т.д.

Извините, если уже было. Просто наболело. Если есть чем поделиться — присоединяйтесь!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>

09.12.05 16:25: Перенесено модератором из '.NET' — TK
Re[4]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 13.12.05 02:17
Оценка: 1 (1) +2
Здравствуйте, VladD2, Вы писали:

VD>Зачем? Проблема (A)b в том, что это ужасный синтаксис и кривизна при парсинге.


проблема в том, что это абсолютно разные операции. Одна из них требует проверки RTTI в рантайме, другая нет. И смысл у них совершенно разный.

VD>
VD>((C)((A)b).Prop1).Prop2
VD>// или
VD>C(A(b).Prop1).Prop2
VD>


Этот синтаксис еще хуже, потому что с одного взгляда нельзя отличить приведение типов от вызова функции. Лучше уж тогда писать что-то вроде cast<type>(A). Заодно и отобьет желание приводить типы без необходимости.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[2]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 08.12.05 11:30
Оценка: +3
Здравствуйте, ie, Вы писали:

ie>Тогда и where T : delegate, до кучи.

+1

ie>Насколько я понимаю, то речь идет о версиях 2.0 и ниже. Лабораторка третей версии не рассматривается.

Почему нет? Вполне рассматривается!

ie> А то у меня есть на этот счет много пожеланий от нормальных кортежей, до венесения select в начало в Query expressions.

Да, кортежи было бы круто.

А по поводу select-а, кажется они на это пошли, чтобы можно было показать IntelliSense.
Если бы select стоял в начале, они бы не смогли предугадать, что я там собираюсь выбирать, т.к. не знали бы ещё откуда (from-то идёт ниже и ещё не напечатан!)

Мне лично кажется from-where-select более разумным, чем select-from-where, ведь когда мы обращаемся к методам объекта, сначала идёт объект, а затем метод (поэтому и можно после нажатия на точку показать список методов объекта!).
Другое дело мы уже к SQL привыкли...
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[7]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 22.12.05 03:10
Оценка: +3
Здравствуйте, AndrewVK, Вы писали:

AVK>Но создаст другую — непрозрачность кода. И я не уверен которая из этих проблем лучше. Возможно, если просто изменить ключевые слова как нибудь так:

AVK>
AVK>object x = ...;
AVK>object y = ...;
AVK>cast (SomeClass scx from x)
AVK>cast (SomeClass scy from y)
AVK>{
AVK>    scx.SomeClassMethod();
AVK>    scy.SomeClassMethod();
AVK>}
AVK>

AVK>, то будет лучше. Вобщем этот вопрос надо обдумывать.

Всё что надо сделать — это разрешить объявлять переменные в if. Тогда уж я как-нибудь и сам справлюсь:

if ((MyType myType = myParameter as MyType) != null)
{
    myType.BlahBlahBlah();
}

Причём объявлять переменные уже можно внутри using, у foreach синтаксис тоже близкий, так что разногласий с линией партии не будет.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 22.12.05 17:33
Оценка: +3
Здравствуйте, AndrewVK, Вы писали:

AVK>В том чтобы невозможно было написать код вроде:


С этим уже поздняк метаться. Backward compatibility никто отменять не будет.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.12.05 17:44
Оценка: +3
Здравствуйте, adontz, Вы писали:

A>Это вопрос реализации. Если ввести typeid аналогичный плюсовому с релизацией типа typeid(A) == typeof(A).AssemblyQualifiedName то всё будет ОК. Значения строк известны на момент компиляции, будет

A>
A>switch (typeid(someObj))
A>{
A>    case typeid(A): ... break;
A>    case typeid(C): ... break;
A>    case typeid(D): ... break;
A>    case typeid(E): ... break;
A>}
A>

A>Коротко и понятно. А насчёт неэффективности это ты не прав — будет обычный switch по строкам.

Если говорить о языке, то так куда как логичнее (ИМХО):
switch (someObj.GetType())
{
    case typeof (A): ... break;
    case typeof (C): ... break;
    case typeof (D): ... break;
    case typeof (E): ... break;
}


Ну а внутри так же, как сейчас со строками.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[7]: Чего не хватает в C#?
От: Belsen  
Дата: 21.12.05 22:45
Оценка: 12 (1) +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Но создаст другую — непрозрачность кода. И я не уверен которая из этих проблем лучше. Возможно, если просто изменить ключевые слова как нибудь так:

AVK>
AVK>object x = ...;
AVK>object y = ...;
AVK>cast (SomeClass scx from x)
AVK>cast (SomeClass scy from y)
AVK>{
AVK>    scx.SomeClassMethod();
AVK>    scy.SomeClassMethod();
AVK>}
AVK>

AVK>, то будет лучше. Вобщем этот вопрос надо обдумывать.
С другой стороны, а обязательна ли новая переменная?
В случаях, когда кастится не выражение, а локальная переменная или параметр, что мешает дать им просто более строгий compile-time тип внутри cast'а?
object pack = ....
ifcast (pack to IEnumerable)
{
   foreach (object item in pack)
   {
       ifcast (item to IEquippable)
       {
           Player.Equip(item);
           ifcast (item to Armour)
               Player.Defence += item.Defence;
           ....
       }
       else
       ifcast (item to IEatable)
       {
           Player.TryEat(item)
           ....
       }
       ....
   }
}


В принципе, ценой умеренного синтаксического оверхеда с Linq (и семантического, на одно указание типа — без него) можно нечто подобное сотворить:
object pack = ....
foreach (var itempack in pack.IfCast<IEnumerable>())
{
   foreach (object item in itempack)
   {
       foreach (var equipment in item.IfCast<IEquippable>())
       {
           Player.TryEquip(equipment);
           foreach (var armor in item.IfCast<Armour>())
               Player.Defence += armor.Defence;
           ....
       }
       else
       foreach (var food in item.IfCast<IEatable>())
       {
           Player.TryEat(food);
           ....
       }
       ....
   }
}

где IfCast не более, чем:
public static IEnumerable<T> IfCast<T>(this object o)
{
    if (o is T)
        yield return (T) o;
}
I might be wrong...
Re: Чего не хватает в C#?
От: dimchick Украина  
Дата: 09.12.05 08:43
Оценка: 4 (1) -1
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Ковариантности:

КО>http://blogs.msdn.com/cyrusn/archive/2004/12/08/278661.aspx
КО>http://blogs.msdn.com/cyrusn/archive/2004/06/18/159671.aspx
КО>Голосовать здесь

КО>Более красивого решения с IEnumerator и IEnumerator<T>:

КО>http://blogs.msdn.com/cyrusn/archive/2005/03/23/401173.aspx

КО>where T : enum

КО>http://blogs.msdn.com/cyrusn/archive/2005/03/23/400844.aspx

КО>а также


КО>mix-ins

КО>делегатов, указывающих на свойства (property delegates)
КО>и т.д.

КО>Извините, если уже было. Просто наболело. Если есть чем поделиться — присоединяйтесь!


Сорри что не всем будет понятно, но тому кому надо — поймут

Проект Linq (C# 3.0, VB 10.0) — майбутнє мов програмування

Дмитро Ніконов (Microsoft)
Сьогодні розробники використовують одну мову програмування для написання вихідного коду програми, і зовсім іншу мову, наприклад SQL, для доступу до даних із СУБД. А якщо створити одну мову, що зможе достукатися й до даних об'єкта і до даних із СУБД, і до даних у форматі XML? Нове розширення до Visual Studio за назвою LINQ (Language Integrated Query) дозволяє писати запити до даних будь-якого формату й звертатися до об'єктів .NET, даних із XML і баз даних однаковим способом. У доповіді будуть продемонстровані можливості LINQ у новій версії Visual Studio, а також буде розказано про плани Microsoft у даній області.
Re[4]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.12.05 22:44
Оценка: 3 (1) +1
Здравствуйте, vdimas, Вы писали:

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


VD>>А использовать using религия не позволяет? Глядишь и не так страшно было бы:

VD>>
VD>>IEnumerator IEnumerable.GetEnumerator() { return GetEnumerator(); }
VD>>



V>Речь не об этом, а о том, что тип IEnumerator<Widget> совместим снизу вверх с IEnumerator, и мой метод IEnumerator<Widget> GetEnumerator() должен "покрывать" оба метода из этих интерфейсов. Не покрывает!!!


Это ты говоришь о контрвариантности. Ее Шарп к сожалению не поддерживает (ну, почти... для делегатов она все же поддерживается). В прочем не так уж часто она требуется.

V>Т.е. нафига мне вообще второй раз писать GetEnumerator()?


Это конечно прискорбно, но не думаю, что это хоть как-то может реально осложнить жизнь. Все же переходник пишется за пару секунд. Особенно в студии.

V>Мы тут получаем лишний уровень делегирования на ровном месте,


Ну, это форменное притягивание за уши "жаренных фактов". Вызов может быть заинлайнен, да и стоимость его на фоне создания итератора и его работы нивелируется.

V>не говоря уже о том, что это просто раздражает.


Сдается мне, что у тебя сначало выработолось раздражение, а потом ты уже начал подбирать для него основания. Иначе бы ты был просто в бешенстве от несуразностей и глупостей имеющихся в плюсах.

V>А ведь это блин коллекции, и своих коллекций тонны...


Да? И можно огласить список или хотя бы объяснить откуда у тебя берутся тонны коллекций?

V>Какие-то ненужные строки в выделеном... В С++ мне достаточно было бы указать имплементацию только 3-х реально реализованных методов. Но даже написав такой early base все тоже не панацея, т.к. в наследниках надо писать override.


Ну, почти убедил. Вот только одна загвоздка. В нашей С++-библиотеке код связанный с коллекциями занимал процентов 60, а то и более. А вот используя дотнет процент получается мизерным. Что я делаю не так?

V>В общем-то вся бодяга из-за двух моментов:

V>1. .Net не понимает имплементацию интерфейса сигнатурами с "совместимыми" возвращаемыми типами.

Як заумно сказал то. Ну, наврено от этого все беды на земле.

V>2. при порождении абстрактного класса от интерфейса требуется явно указать все методы из интерфейса как abtract (если не имплементируем их). Можно подумать, что компилятор сам не в состоянии "дописать" абстрактные методы.


Может спецификацию почитать? C# не делает методы интефейсов виртуальными. Вот если ты напишешь abstract или virtual, то сделает. Но только к интерфейсам это уже отношения иметь не будет. Ну, а реализовать интерфейс можно за пару секунд. Вставл на его имени в списке наследования, нажал Alt+Shift+F10, выбрал тип реализации (публичный или скрытый). Все. Интерфейс готов. Остается только решить вписать ли в методы код, сделать ли их абстрактыми или оставить как есть.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Чего не хватает в C#?
От: WolfHound  
Дата: 30.12.05 12:36
Оценка: 3 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>Незнаю. Пока что мне кажется, что использовать для этого просто if не лучшая идея. Хотя может это догмы...

ИМХО догмы. Я в С++ постоянно это использую и никаких проблем.

Кстати я тут подумал...
condition null(object o)
{
    return o == null;
}
condition same object(object o1, object o2)
{
    return object.ReferenceEquals(o1, o2);
}

далие в коде
while not null (string line = file.ReadLine())
{
    ...
}
if same object (object obj1 = GetObj1(), object obj2 = GetObj2())
{
}

not это опициональная часть условия.

Думаю идея ясна.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.05 11:26
Оценка: 2 (1) +1
Здравствуйте, Real 3L0, Вы писали:

R3>Правильно перевёл?


Ну примерно. Основная идея следующая — обычно, когда свойство используется, подсознательно предполагается, что это операция относительно дешевая, поэтому, если на самом деле она дорогая, то могут быть проблемы с производительностью. Для избежания подобного дорогие алгоритмы рекомендуется оформлять ввиде методов. См. к примеру GetSchemaTable().
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[11]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.12.05 04:38
Оценка: 2 (1) +1
A>Это не одна и та же операция. new A(b) это deep copy, а A(b) скорее всего сохранит связь между объектами a и b.
Рома, это так только потому, что ты так придумал. Я тоже могу привести примеры, когда new A() вовсе не порождает никакого нового объекта, и вот в таком коде обе переменные доступаются до одного и того же инстанса:
A a = new A();
A b = new A();

Так что не нужно придумывать семантики там, где ее нету.
Когда Страуструп вводил перегрузку операторов в плюсы, некоторые люди тоже кричали, что нельзя делать умножение матриц вот так: a = b*c+d. Потому что, видите ли, программисты на C могут думать, что это скомпилится в одну инструкцию на ассемблере, в отличие от
InitMatrix(&temp, 3, 3);
Multiply(b, c, &temp);
InitMatrix(&a, 3, 3);
Add(temp, d, &a);


Ты теперь пытаешься отличать глубину копирования, основываясь на наличии слова new.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 11:15
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>Ну, а теперь внимательно погляди на код и объясни какая разница будет между "new A(b)" и "A(b)"? Что то, что это выполняет одну и ту же операцию.


Это не одна и та же операция. new A(b) это deep copy, а A(b) скорее всего сохранит связь между объектами a и b. Если тебе почему-либо всё ещё не понятно, то вот другой пример — тут уже разница есть и она огромная.
class B
{
    private int _data;
    
    public B(int data)
    {
        _data = data;
    }
    
    public int Data
    {
        get { return _data; }
        set { _data = value; }
    }
}

class A
{
    private B _data = new B(0);

    public A(int data)
    {
        _data.Data = data;
    }

    public A(B b)
    {
        _data = new B(b.Data);
    }

    public A(B b, bool deep)
    {
        if (deep)
        {
            _data = new B(b.Data);
        }
        else
        {
            _data = b;
        }
    }

    public int Data
    {
        get { return _data.Data; }
        set { _data.Data = value; }
    }
    
    public static A ConvertFrom(B b)
    {
        return new A(b, false);
    }
}

class Program
{
    static void Main(string[] args)
    {
        B b = new B(3);
        A a1 = new A(b);
        // Должно быть A a2 = A(b)
        A a2 = A.ConvertFrom(b);
        
        Console.Write(b.Data);
        a1.Data = 6;
        Console.Write(b.Data);
        a2.Data = 6;
        Console.Write(b.Data);
    }
}

И не надо говорить, что это пример надуманный. Преобразование типа это не создание нового объекта. Это просто another view for the same content. Типичнейший пример — приведение к типу интерфейса не создаёт нового объекта.

Влад, это грабли хотя бы потому что есть альтернативное мнение.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 08.12.05 12:11
Оценка: +2
Здравствуйте, <Аноним>, Вы писали:

А>Мне бы хотелось видеть C# образца FW1.1 еще лет пять-десять... Ну, чтобы там сидел специальный человек, затыкал свои дырки, присылал мне упдейты в виде сервиспаков, чтобы это называлось FW1.1... А у вас что не получается?..


Да вот не получается как-то. После того как попишешь на 2.0 с месяцок, на 1.1 почему-то не тянет.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re: Чего не хватает в C#?
От: oxid  
Дата: 09.12.05 13:25
Оценка: +2
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Извините, если уже было. Просто наболело. Если есть чем поделиться — присоединяйтесь!


Было бы неплохо видеть в C# константные методы, и передачу в функции константныx переменных:


void FnName( const string text, const MyObj obj )
{...}

int FnName2(string text) const
{...}
Трудно быть богом(с) A.C. и Б.С.
Re: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 10.12.05 04:49
Оценка: +2
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Извините, если уже было. Просто наболело. Если есть чем поделиться — присоединяйтесь!


Давай пример как ты хочешь видеть миксины и я тебе предложу решение на RFD/BLToolkit

По существу вопроса.

Мне на сегодняшний день по большому счёту не хватает одной простой вещи — возможности запустить свои шаловливые ручки в кишочки компилятора, а точнее — вмешаться в процесс генерации кода.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 11.12.05 08:59
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>А использовать using религия не позволяет? Глядишь и не так страшно было бы:

VD>
VD>IEnumerator IEnumerable.GetEnumerator() { return GetEnumerator(); }
VD>



Речь не об этом, а о том, что тип IEnumerator<Widget> совместим снизу вверх с IEnumerator, и мой метод IEnumerator<Widget> GetEnumerator() должен "покрывать" оба метода из этих интерфейсов. Не покрывает!!!

Т.е. нафига мне вообще второй раз писать GetEnumerator()?
В C++ в таких случаях не надо (см пример выше).

Мы тут получаем лишний уровень делегирования на ровном месте, не говоря уже о том, что это просто раздражает.

А ведь это блин коллекции, и своих коллекций тонны... И вот пишем такую хрень для всего этого (для тех коллекций, которые далеки от List<T> по внутреннему устройству) :
public abstract class CollectionPreBase<T> : ICollection<T> {

       public abstract IEnumerator<T> GetEnumerator();
       public abstract int Count { get; }
       public abstract void Add(T item);
       public abstract void Clear();
       public abstract bool Remove(T item);
     
        public virtual bool Contains(T item) {
            foreach (T t in this)
                if (object.Equals(t, item))
                    return true;

            return false;
        }

        IEnumerator IEnumerable.GetEnumerator() {
            return GetEnumerator();
        }

        public virtual void CopyTo(T[] array, int arrayIndex) {
            if (Count + arrayIndex > array.Length)
                throw new ArgumentException("Can not copy values to array", "arrayIndex");

            foreach (T item in this)
                array[arrayIndex++] = item;
        }

        public abstract bool IsReadOnly { get; }
    }

    public abstract class NonEditableCollectionBase<T> : CollectionPreBase<T> {
        public override bool IsReadOnly { get { return false; } }

        public override void Add(T item) {
            throw new InvalidOperationException("Can not Add on read-only collection");
        }

        public override void Clear() {
            throw new InvalidOperationException("Can not Clear on read-only collection");
        }

        public override bool Remove(T item) {
            throw new InvalidOperationException("Can not Remove from read-only collection");
        }
    }

    public abstract class EditableCollectionBase<T> : CollectionPreBase<T> {
        public override bool IsReadOnly { get { return true; } }
    }


    public class WidgetCollection : EditableCollectionBase<Widget> {
...



Какие-то ненужные строки в выделеном... В С++ мне достаточно было бы указать имплементацию только 3-х реально реализованных методов. Но даже написав такой early base все тоже не панацея, т.к. в наследниках надо писать override.

В общем-то вся бодяга из-за двух моментов:
1. .Net не понимает имплементацию интерфейса сигнатурами с "совместимыми" возвращаемыми типами.
2. при порождении абстрактного класса от интерфейса требуется явно указать все методы из интерфейса как abtract (если не имплементируем их). Можно подумать, что компилятор сам не в состоянии "дописать" абстрактные методы.
Re[3]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.05 20:36
Оценка: +2
Здравствуйте, Дарней, Вы писали:

Д>а еще лучше, сделать разный синтаксис для (Button)control и (int)myLong


Зачем? Проблема (A)b в том, что это ужасный синтаксис и кривизна при парсинге.

((C)((A)b).Prop1).Prop2
// или
C(A(b).Prop1).Prop2


А вот что приводить вэлью-типы или ссылочные мне по фигу.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.12.05 07:32
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:

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


S>>Это с чего это прежним? Как компилятор отличит "случайно" не указанный Length в твоем абстрактном классе от намеренного, как требование перекрыть его в наследнике? Я вот что-то не понимаю.


V>Ok, согласен. Да, компилятор C++ точно так же говорит мне при попытке создать экземпляр абстрактного класса, что его нет. Я не помню проблем с этим. Действительно, если метода нет, то надо сделать так, чтобы он был

V>А где сделать — решать тебе. И в чем толк повторения этих методов в абстрактном классе. Если я добавлю еще один метод в абстрактный класс для требований реализации изменений интерфейса, как ты привел пример, то мне точно так же компилятор даст по рукам во всех наследниках. Т.е. в чем бенефиты?
В том, что ты это делаешь намеренно. Ты ведь не обязан делать его абстрактным — может, тебе будет вполне достаточно


S>>Все консистентно. Неясно, зачем тебе декларировать абстрактные методы в базовом классе, если тебе так хочется использовать невиртуальные методы в его потомках.

V>Компилятор требует.
Компилятор ничего не требует. Хочешь делать невиртуальную реализацию метода интерфейса — делай.
V>Дык, посмотри в код. Пяток методов для реализации коллекции с 0-ля я уже сэкономил.
Где? Они ж абстрактные! Т.е. ты обязан перекрыть их в классах-наследниках! Ничего ты не сэкономил — наследников точно так же можно наследовать и от object. Сдается мне, что ты не совсем верно применяешь связку абстрактный класс/интерфейс.
Вот что я имею в виду:
public abstract class CollectionPreBase<T> 
{
  public abstract IEnumerable<T> GetEnumerator();
    public virtual bool Contains(T item)
    {
        foreach (T t in this)
            if (object.Equals(t, item))
                return true;

        return false;
    }

    IEnumerator IEnumerable.GetEnumerator() {
            return GetEnumerator();
    }

    public virtual void CopyTo(T[] array, int arrayIndex)
    {
        if (Count + arrayIndex > array.Length)
            throw new ArgumentException("Can not copy values to array", "arrayIndex");

        foreach (T item in this)
            array[arrayIndex++] = item;
    }


public abstract class NonEditableCollectionBase<T> : CollectionPreBase<T> 
{
    public bool IsReadOnly { get { return true; } }

    public void Add(T item) 
    {
        throw new InvalidOperationException("Can not Add on read-only collection");
    }

    public void Clear() 
    {
        throw new InvalidOperationException("Can not Clear on read-only collection");
    }

    public bool Remove(T item)
    {
        throw new InvalidOperationException("Can not Remove from read-only collection");
    }
}

public abstract class EditableCollectionBase<T> : CollectionPreBase<T> 
{
    public bool IsReadOnly { get { return true; } }
}


public class WidgetCollection : EditableCollectionBase<Widget>, ICollection<Widget>
{
...

Как видишь, а) никаких лишних абстрактных методов б) никакой насильственной виртуальности в) ничего лишнего в конкретных классах-потомках.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.12.05 11:17
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Понимаш ли, С++-ники точно так же аргументируют наличие обилия граблей в С++.


Главное — не надо ударяться в крайности. Я сторонник золотой середины, т.е. вполне допускаю варианты, когда вероятность ошибки незначительна, а набирать и читать проще.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[2]: Руки прочь от as!
От: Воронков Василий Россия  
Дата: 21.12.05 23:12
Оценка: :))
Субж
Re[4]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка: :))
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Уже есть в подобном виде в C++:

ПК>
ПК>if (B* b = dynamic_cast<B*>(a))
   b->>A_Method();
ПК>


А что плюсы позволяют объявлять переменые внутри скобок if-а?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 10:59
Оценка: :))
Здравствуйте, VladD2, Вы писали:

VD>Глупости не говори. Это как раз сравнение на больше меньеш невозможно для обень большого количества классов.


Всегда можно сравнить побитово.

VD>Например, сравни на больше меньше те же типы (System.Type). А вот как раз сравение на эквивалентность и хэш-код можно создать для любого объекта если он имеет состояние (а другие в свитче и не нужны). Именно по этому любой объект имеет вирутальные функции:

VD>
VD>bool Equals(object obj);
VD>
и:
VD>int GetHashCode();
VD>


А в STL все используют оператор < и предикат less. На самом же деле вместо того чтобы сортировать объекты ты предлагаешь брать хеши объектов и сортировать уже их. ИМХО не самое эффективное решение, учитывая что хеш может считаться совершенно по-разному.

Более того, что обозначает хеш? Он ничего не обозначает! Если значения возвращённые GetHashCode() двух объектов равны, то возможно, равны и сами объекты. К тому же чтобы получить хеш сложного типа надо испотльзовать все его значимые поля, а чтобы сравнить, скорее всего первые несколько. Например чтобы получить хеш строки надо обработать все её символы, а чтобы сравнить две строки, возможно только первый.

Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 27.12.05 12:37
Оценка: +2
Здравствуйте, GlebZ, Вы писали:

IT>>Вот ещё бы чего хотелось. Впрочем, это не C#, а сам фреймворк. Причём сделать это можно за пару минут. Рехтуем класс Activator.

GZ>И так не быстро. Если бы такие вещи поддерживались JIT'ом через new — было бы круто. А через Activator — можно написать и свой wrapper.

Это всё можно закешировать. А вариант на дженериках вообще летать будет и ничем от new не отличаться. Но дело даже не в этом. Activator используют все, в том числе сам фреймворк, а твой рапер только ты.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.12.05 03:17
Оценка: 24 (1)
Здравствуйте, vdimas, Вы писали:

V>ВСЕ!!! ПОНЯЛ ЧТО ТЫ ИМЕЛ В ВИДУ!!! (дважды не мог врубиться о чем ты, применительно к моему случаю)



V>и побежал проверять на компиляторе, но увы, чудес не бывает:

V>

V>error CS0540: 'Widgets.CollectionPreBase<T>.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable'

Да, поторопился я. Конечно же, нам потребуется декларировать реализацию IEnumerable. И приводиться к IEnumerable<T> явно:
public abstract class CollectionPreBase<T> : IEnumerable
{
    public virtual bool Contains(T item)
    {
            foreach (T t in (IEnumerable<T>)this)
                    if (object.Equals(t, item))
                            return true;

            return false;
    }

    IEnumerator IEnumerable.GetEnumerator() {
                    return ((IEnumerable<T>)this)GetEnumerator();
    }

    public virtual void CopyTo(T[] array, int arrayIndex)
    {
            if (Count + arrayIndex > array.Length)
                    throw new ArgumentException("Can not copy values to array", "arrayIndex");

            foreach (T item in (IEnumerable<T>)this)
                    array[arrayIndex++] = item;
    }
}



V>(а про подобное применение интерфейсов я и сам когда-то кому-то разъяснял здесь на форуме .Net 1-2 года назад, найти ту мессагу нереально)
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 10.12.05 17:13
Оценка: 8 (1)
Здравствуйте, _FRED_, Вы писали:

IT>>Мне на сегодняшний день по большому счёту не хватает одной простой вещи — возможности запустить свои шаловливые ручки в кишочки компилятора, а точнее — вмешаться в процесс генерации кода.


_FR>Для каких целей? Может я тоже помечтаю об этом


Если коротко, то для реюзания паттернов.

Если в примерах, то можно взять опять тот же RFD и BLToolkit. Например, EditableObject выглядит примерно так:

public abstract class Person : EditableObject
{
    public abstract int      ID        { get; }
    public abstract string   FirstName { get; set; }
    public abstract string   LastName  { get; set; }
    public abstract DateTime Birthday  { get; set; }
}

В результате мы имеем автоматическую генерацию свойств. Но не просто генерацию, а генерацию такой имплементации свойств, которая поддерживает редактирование объекта, т.е. методы AcceptChanges, RejectChanges и IsDirty флаг. Таким образом 4 приведённые выше безобидные строчки превращаются вот в такую гору кода:

public class PersonGen : Person, IEditable, IMapGenerated
{
    public PersonGen()
    {
    }

    public PersonGen(MapInitializingData data)
    {
    }

    private EditableValue<int> _ID = new EditableValue<int>();
    public  override      int   ID
    {
        get { return _ID.Value; }
        set
        {
            _ID.Value = value;
            PropertyChanged(_ID_MapPropertyInfo);
        }
    }

    private EditableValue<string> _FirstName = new EditableValue<string>("");
    public  override      string   FirstName
    {
        get { return _FirstName.Value; }
        set
        {
            _FirstName.Value = value;
            PropertyChanged(_FirstName_MapPropertyInfo);
        }
    }

    private EditableValue<string> _LastName = new EditableValue<string>("");
    public  override      string   LastName
    {
        get { return _LastName.Value; }
        set
        {
            _LastName.Value = value;
            PropertyChanged(_LastName_MapPropertyInfo);
        }
    }

    private EditableValue<DateTime> _Birthday = new EditableValue<DateTime>();
    public  override      DateTime   Birthday
    {
        get { return _Birthday.Value; }
        set
        {
            _Birthday.Value = value;
            PropertyChanged(_Birthday_MapPropertyInfo);
        }
    }

    object[] IMapGenerated.GetCreatedMembers()
    {
        return new object[] { this._ID, this._FirstName, this._LastName, this._Birthday } ;
    }

    void IEditable.AcceptChanges()
    {
        _ID.       AcceptChanges();
        _FirstName.AcceptChanges();
        _LastName. AcceptChanges();
        _Birthday. AcceptChanges();
    }

    void IEditable.RejectChanges()
    {
        _ID.       RejectChanges();
        _FirstName.RejectChanges();
        _LastName. RejectChanges();
        _Birthday. RejectChanges();
    }

    bool IEditable.IsDirty
    {
        get
        {
            return _ID.IsDirty || _FirstName.IsDirty || _LastName.IsDirty || _Birthday.IsDirty;
        }
    }

    bool IEditable.IsDirtyMember(string memberName, MapPropertyInfo pi, ref bool isDirty)
    {
        return
            _ID.       IsDirtyMember(memberName, _ID_MapPropertyInfo,        ref isDirty) ||
            _FirstName.IsDirtyMember(memberName, _FirstName_MapPropertyInfo, ref isDirty) ||
            _LastName. IsDirtyMember(memberName, _LastName_MapPropertyInfo,  ref isDirty) ||
            _Birthday. IsDirtyMember(memberName, _Birthday_MapPropertyInfo,  ref isDirty);
    }


    private static MapPropertyInfo _Birthday_MapPropertyInfo;
    private static MapPropertyInfo _FirstName_MapPropertyInfo;
    private static MapPropertyInfo _LastName_MapPropertyInfo;
    private static MapPropertyInfo _ID_MapPropertyInfo;

    static PersonGen()
    {
        _ID_MapPropertyInfo        = new MapPropertyInfo(typeof(Person).GetProperty("ID"));
        _FirstName_MapPropertyInfo = new MapPropertyInfo(typeof(Person).GetProperty("FirstName"));
        _LastName_MapPropertyInfo  = new MapPropertyInfo(typeof(Person).GetProperty("LastName"));
        _Birthday_MapPropertyInfo  = new MapPropertyInfo(typeof(Person).GetProperty("Birthday"));
    }

    private static MapDescriptor _MapDescriptor;
    private static MapDescriptor  MapDescriptor
    {
        get
        {
            if (_MapDescriptor == null)
                _MapDescriptor = MapDescriptor.GetDescriptor(typeof(Person));

            return _MapDescriptor;
        }
    }
}

В качестве ещё одного примера можно взять DataAccess из RFD.Toys. Например, у нас есть такой метод:

public class EmployeeDataAccessor : DataAccessorBase
{
  public List<Employee> SelectByName(string name)
  {
    using (DbManager db = GetDbManager())
    {
      return db
        .SetSpCommand(GetSpName(typeof(Employee), "SelectByName"),
          .db.Parameter("@name", name))
        .ExecuteList<Employee>();
    }
  }
}

Не трудно заметить, что вся необходимая информация для генерации тела метода у нас уже присутствует в сигнатуре самого метода. Тип возвращаемого значения нам может сказать о том какой из Execute методов необходимо вызывать и какой тип объекта использовать для маппинга. Имя метода вполне можно использовать как имя действия (action), по которому в соответствии с определёнными соглашениями будет построено имя сохранённой процедуры. Параметры метода однозначно определяют типы и имена параметров сохранённой процедуры. Т.е. нам вполне достаточно следующего описания метода:

public abstract class EmployeeDataAccessor : DataAccessorBase
{
  public abstract List<Employee> SelectByName(string name);
}

Всё. Остальное работа для генератора.

И всё это уже есть сейчас и успешно применяется и экономит кучу времени как при написании кода, так и при его отладке и сопровождении. Но за всё это счастье приходится платить неудобством отладки, абстрактными классами и сложностью написания таких расширений. В принципе, цена небольшая, но есть вещи, которые я не могу сделать в принципе в рантайм. Возмём к примеру всеми нами любимый паттерн синглетон. Я бы хотел видеть его в таком виде:

[Singleton]
public class MySingleton
{
}

Всё, здесь я свободен, т.к. генератору тут не за что зацепиться. Нужен виртуальный метод или свойство. Но если бы у меня была возможность расширять компилятор, то такую вещь я бы сделал как два байта. А к ней бы и всевозможные миксины, эмуляцию множественного наследования и кучу других вещей. AOP со своими примитивными аспектами стоял бы в сторонке и нервно покуривал.

Из того что понадобились бы ещё от компилятора для поддержки этого дела — усиление применения AttributeUsage и сахарок типа memberof(...). Никаких значительных изменений в синтаксис языка вводить не надо. Вся нужная информация берётся из метаданных и великолепно управляется атрибутами (обрати внимание, в примере с классом Person вся информация для генератора берётся из базового класса EditableObject).

_FR>Мало что ли RSharp'а и XCSharp'а?


Чувак, который написал XC# слишком рано захотел денег. Это было ошибкой. Ему надо было подождать хотя бы ещё пару лет, подсадить на это дело как можно больше девелоперов, а уже потом пытаться на этом заработать.
R# до сих пор не вышел из ворот лаборатории.

Да и вообще, довольно трудно проталкивать подобные решения, если они не от MS. От MS народ хавает всё, включая их глючные апп. блоки. Что-то со стороны идёт со скрипом. Это касается всякого рода библиотек, за языки я вообще молчу.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.12.05 06:31
Оценка: 8 (1)
Здравствуйте, vdimas, Вы писали:

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


V>>>Речь не об этом, а о том, что тип IEnumerator<Widget> совместим снизу вверх с IEnumerator, и мой метод IEnumerator<Widget> GetEnumerator() должен "покрывать" оба метода из этих интерфейсов. Не покрывает!!!


VD>>Это ты говоришь о контрвариантности. Ее Шарп к сожалению не поддерживает (ну, почти... для делегатов она все же поддерживается).


V>Хорошо хоть это, спасибо за инфу. (Проверю этот момент и на сигнатурах параметров методов)


VD>>В прочем не так уж часто она требуется.


V>Абсолютно согласен, если она требуется, то что-то не так в доме Облоньских в плане дизайна.

V>Может быть, кто-то нагнал пурги и сделал так:
V>
V>public interface IEnumerable<T> : IEnumerable {
V>    IEnumerator<T> GetEnumerator();
V>}
V>


V>Хотя надо было вот так:

V>
V>public interface IEnumerable : IEnumerable<object> {}
V>

Увы, так не получится. Дело в том, что не все языки поддерживают дженерики.
V>причем, я хорошо понимаю причины, по которым так не сделали — чтобы иметь возможность пройтись по коллекции "чего угодно" в своих компонентных моделях и дизайнерах.
Нет. Для того, чтобы пользователи недженерикоподдерживающих языков могли пользоваться библиотеками с дженерик-поддержкой.
Для них IEnumerable<object> не существует. Ок, мы для них унаследовали не-дженерик версию интерфейса.
Но все равно не удается принудительно заставить разработчика коллекции предоставить доступ к IEnumerable. В данном варианте мы не можем отнаследовать IEnumerable<T> от IEnumerable.
Единственный вариант, который бы прокатил — это поддержка контравариантности в реализациях интерфейсов. Но я подозреваю, что она чревата еще большим количеством неочевидных моментов.

Я уже привык к тому, что я могу делать специфичные версии методов, называя их так же. А в явных реализациях интерфейса просто делегировать вызов:

public FileResource this[string name] 
{
  get 
    {
      ...
    }
}

IResource IResourceFolder.this[string name] { get { return this[name]; } };

V>Насколько часто такая задача стоит в run-time в реальных приложениях, где мы оперируем со своей известной системой типов?
Кстати, есть еще много мест в стандартной библиотеке, где дженерики бы отлично смотрелись. Например,
T[] MemberInfo.GetCustomAttributes<T>(bool inherit) where T : Attribute

вместо
object[] MemberInfo.GetCustomAttributes(Type t, bool inherit);

Увы — явно не хотелось загрязнять System.Reflection дженериками.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.05 12:18
Оценка: 8 (1)
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Я если честно не понял. Какие события? Можешь поподробнее?


Антон указал на то, что автоматическое создание полей в компиляторе C# уже есьть, а именно в случае событий поле делегата явно можно не указывать, компилятор сгенерирует его самостоятельно. И предложил аналогичный синтаксис для свойств. На что я заметил, что в случае свойств, в отличие от событий, крайне важно указать список поддерживаемых операций.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[8]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.05 18:53
Оценка: 1 (1)
Здравствуйте, vdimas, Вы писали:

V>Что-то не сообразил в чем подвох. value-типы же не наследуются. Если ты про реализацию ими интерфейсов, то можно было бы генерить thunk-переходник при компиляции.


Я про то, что (ко/контр)вариантность для вэлью-типов не проходит. Хотя иногда кажется логичным, что метод:
long F();

совместим с методом
int F();

так как int приводится к long.

V>>>Я смотрел на дизасемблированный код в отладчике без дебаг-информации и с включенной оптимизацией, и я нигде не видел инлайна при вызове даже собственных виртуальных методов, если у объекта есть наследжники. Если сам увидишь хоть раз подобное — покажи нам, ok?


VD>>Очень смешно. Ладно. Прочтем ликбез по банальному вопросу в стопервый раз.


V>Это все известно, у меня прекрасно инлайнятся методы объектов. Речь шла о вызове объектом собственного виртуального метода.


А где ты увидил виртуальный метод? Фигово ты читал ликбез.
Нет тут ничего виртуального. Вот если бы ты привел бы this к ссылке на интерфейс, то о виртальности можно было бы поговорить.

"IEnumerator<int> GetEnumerator()" не является винтуальным методом. В дотнете реализация интерфейса и виртуальность метода не одно и то же.

И будет ли он заинлайнен или нет определяется исключительно эвристиками джита, а не виртуальностью. Кстати, потенциально и с виртуальностью можно бороться.

VD>>Итератор вызвается ровно один раз. Далее возвращается объект по которому и происходит итерация. Ведь нет только контрвариантности, а приведение к интерфейсам еще никто не отменял. IEnumerator<T> же унаследован от IEnumerator. Так что в примере вроде:


V>[скипнул код т.к. не по делу]


V>Если у нас енумератор от IEnumerator<T> и мы его сделли без yield return, в его с-ве T Current{get;} тот же момент.


Ничго не понял.

V>У них там недавно очередной релиз был. Состав их PoserCollections маловат, но это от того, что в "основном" составе хватает функциональности. Это как бы дописывание того, что не вошло во фреймворк (а могло бы, там совсем немного)


Согласен. Но похоже, что она и не вошла по причине экзотичности. То есть, кожется, что там куча всего нужного, а на практике что-то применять это все дело не приходится.

V>Ты думаешь что с STL/boost сложнее?


Ну, реализуй КОМ-овскую коллекцию на нем. Да и просто коллекцию то будет сложно. Нужны события и т.п. А уж с КОМ-овской за всегда трху на порядок больше.

V>>> Независимо от того — виртуальный метод или нет, вызов метода через интерфейс происходит абсолютно одинаково, независимо от "виртуальности" метода, реализующего интерфейсный. Поэтому нам однофигственно, виртуальный метод делать или нет.


VD>>Ошибаешся. Все несколько по разному. Изучи, на досуге, вот этот пример:


V>не смешно, это как в другой ветке где ты пытался предположить, что я не знаю о существовании unsafe у компилятора C#. Я имел ввиду механику вызова, т.е. затраты на вызов метода объекта через интерфейс. Они не зависят от виртуальности целевого метода.


Очень даже зависят. Ты все же повнимательнее погляди примерчик то. Там как раз показана разница в вызове виртуального члена класса через интерфейс и не виртуального.

V>И спрашивал, зачем мне объявлять эти абстрактные методы?


А зачем ты их в С++ объявляешь? Ты просто не можешь понять, что в дотнете виртуальность методов и реализация интфейсов вещи связанные не анпрямую.

V>Вот еще мешает приведенный кусок кода. Если бы не надо было объявлять за непонятно каким лешим абстрактные методы, было бы гораздо чище. Компилятор не в состоянии это сделать сам???


Да, не объявляй. Реализуй интерфейс где нужно и обойдешся без виртуальных методов. Я вообще не вижу смысла в классе не имеющем ни одного реально реализованного метода. Если ты хочешь создать базовый класс который реализовал бы некоторые методы, то можешь просто создать класс не реализующий интерфейс но определяющй часть методов. А дальше отнаследуйся от этого класса и реализуй интерфейс. Методы из базового класса автоматом воспримутся как реализация методов интерфейса.
using System;

interface ITest
{
    void Method1();
    void Method2();
    void Method3();
}

class BaseA
{
    public void Method1() { Console.WriteLine("BaseA.Method1();"); }
}

class BaseB : BaseA
{
    public void Method2() { Console.WriteLine("BaseB.Method2();"); }
}

class Test : BaseB, ITest
{
    public void Method3() { Console.WriteLine("Test.Method3();"); }
}

class Program
{
    static void Main()
    {
        Test test = new Test();
        test.Method1();
        test.Method2();
        test.Method3();
    }
}


V>>>Ну, а (ко|контр)вариантность конечно бы не помешала бы. Вот только не так уж она актуальна, чтобы ради не столько слез проливать.


V>Кому как. Приведенный случай обощается не только на один этот метод в интерфейсах коллекций. У кого-то может быть развитая система типов и эта контрвариантность могла бы сэкономить ненужные строки кода


Может быть, может быть. Вот только я как-то ни разу не наталкивался на столь острую необходимость. А в редких случаях переходник спасают.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка: 1 (1)
Здравствуйте, Дарней, Вы писали:

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


VD>>Про анализ потоков данных слышал? У джита есть все возможности для этого.


Д>это просто оптимизация,


Ага. А, что, кто-то говорил о чем-то другом?

Д>и срабатывает далеко не всегда


Не то что бы далего, но точно не всегда.

Д>object[] tmp = { -1, "a", null, 5.6 };

Д>как обходиться без проверок будем?

А надо обходиться? Если оптимизация не применима, то живем по старому. Никто же не запрещает создавать объекты в хипе?

VD>>А куда ты перейдешь, если код функции тебе не доступен? Это вообще не серьезный разговор. Найди, например, ради хохмы, код для функции Array.Copy() или Math.Sin(). Если найдешь что-то кроме-двух одной ассемблерной инструкции я лично сниму шляму.


Д>попробуй нажать "go to definition" в VS2005.


И что? Тебе там код кто-то даст? И вообще, ты хорошо понимашь где и как делаются подобные оптимизации? Это же делает джит или пре-джит. Им до до лампочки наличие или отсуствие кода.

Интересно, что они отличаются.

Д>А шляпа у тебя есть?


Найдем. Только она явно не понадобится.

Д>а почему хак?


Потому что для определния приведение это типа или нет используется довольно натянутая эвристика. int, double и т.п. являются встроенными типами и для них всегда делается зключение, что это тип. А вот для других идетификаторов делается предположение. И в случее вроде приведенного мной, это предположение сделано быть не может.

В общем, если интересны подробности, то залезь в спецификацию шарпа и погляди. Там это подробно описано (к сожалению пункт не помню).

Д>Не наводит Первое, кстати, намного интереснее. Почему к встроенному типу можно приводить без скобок, а к его реальному имени нельзя?


Вот, вот. Не лоегично? Но дело обстоит именно так. Всетроенные типы всегда типы (где бы они не упоминались), а вот все остальное еще не факт. И все это из-за попытки оставить С-шное соглашение о примедении типов.

Причем в С/С++ это работет без особых проблем. Ведь в них парсинг подразумевает последовательное сканирование. Тип применяемый где бы то нибыло обязан быть объявлен до его первого использования. В Шарпе же это не так. И для определения тип это или не тип используется натянутая эвристика.

Д>По хорошему, стоит вообще запретить ставить унарный минус перед составными выражениями без явного заключения их в скобки. Ибо нефиг.


Дело не в минусах. Это только простенький пример. Поверь мне на слово. Определение тип это или не тип делается ну, очень примитивным образом. Причем во всех случаях кроме приведения типов место где должен распологаться тип четко специфицировано и не конфликтует с другими конструкциями языка. А вот приведение типов понфликтует с вызовом метода и выражением взятым в скобки. Причем все это фигня до появления C# 2.0. В нем еще вводится перегруженная семантика для "<" и ">". В купе с приведением типов получается забавнеший парсинг с эвристиками. Они конечно работают. И выглядят довольно логично. Но если бы их небыло, или если бы они были по проще, то было бы куда лучше.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: Воронков Василий Россия  
Дата: 24.12.05 00:45
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

VD>Я незнаю, что тебе там напоминает. Но без new экземпляра не создать. Так что об этом можно уже перестать разговаривать.


Гм. Тут дело на самом деле не в С++. Синтаксис сам по себе похож на вызов конструктора. Например, если предположить что я забыл указать new, то компилятор даже попробует собрать что-нибудь такое:

A a = A(b);

и очень может быть что это ему удастся

VD>В С++ нет никаких cast<Type>(obj). В нем есть разные static_cast<Type>() и т.п., что есть не что иное как применение того самого функционанльного стиля в сочетании с шаблонами.


Хорошо. Пускай будет по аналогии с "разными static_cast<Type>()".

VD>Xxx<Y>() в С++ — это синтаксис вызова функции.


В С# тоже

VD>static_cast и т.п. были введены в язык исключительно из-за того, что переусложненная семантика языка требовала введения разных вариантов приведения типов.


Чем мне нравится подобный синтаксис — тем что он заметен, бросается в глаза. Типа "ахтунг, здесь приведение!". А со всякими (B)a, B(a) глаз просто замыливается. В твоем случае будет даже хуже. Глядя на какое-нибудь навороченное выражение вообще будет сложновато определить, где вызов метода, где приведение..

VD>Что касается "напоминаний". Да недолжны приведения типов ничего напоминать. Приведение типов есть функция из одного типа в другой. И нечего странного если она и выглядит как функция.


Правильно. Так как Xxx<Y>() в С# — это синтаксис вызова функции пускай она так и выглядит.
Re[8]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 01:56
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

ВВ>>A a = A(b);

ВВ>>и очень может быть что это ему удастся

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


дрим камс тру
class B
{
    private int _data;
    
    public B(int data)
    {
        _data = data;
    }
    
    public int Data
    {
        get { return _data; }
    }
}
    
class A
{
    private int _data;
    
    public A(B b)
    {
        _data = b.Data;
    }

    public int Data
    {
        get { return _data; }
    }
}


B b = new B(3);
A a = new A(b);


Если в последней строке забыть new то вместо создания нового типа получим приведение типа. Естественно что это может приводить в разным последствиям, например, сохранению связи между объектами, когда изменение a будет влиять и на b. Говоря попросту очередные грабли от которых в проекте наступает полная Ж.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 08.12.05 02:50
Оценка: +1
Здравствуйте, Кирилл Осенков, Вы писали:

КО>where T : enum

КО> http://blogs.msdn.com/cyrusn/archive/2005/03/23/400844.aspx

Тогда и where T : delegate, до кучи.

КО>Извините, если уже было. Просто наболело. Если есть чем поделиться — присоединяйтесь!


Насколько я понимаю, то речь идет о версиях 2.0 и ниже. Лабораторка третей версии не рассматривается. А то у меня есть на этот счет много пожеланий от нормальных кортежей, до венесения select в начало в Query expressions.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[2]: Чего не хватает в C#?
От: Аноним  
Дата: 08.12.05 08:32
Оценка: :)
Здравствуйте, xvost, Вы писали:

X>Цель — чтобы никто не мог даже изнутри класса достучатся до поля минуя сеттер/геттер проперти


Кто это — никто? Назови ее _buf0725416829 — волосы станут мягкими и шелковистыми.
Re[3]: Чего не хватает в C#?
От: xvost Германия http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата: 08.12.05 08:36
Оценка: +1
Здравствуйте, jorj, Вы писали:

J>Странно это как-то, девелопер пишет класс и не знает как ему следует обращаться к полю: напрямую или через сеттеры/геттеры.


Ну почему же. Во-первых, я могу не писать его, а модифицировать. Во-вторых, класс может быть весьма большим. В третьих, завтра другой девелопер влезет в этот класс, и не обратит внимание на грозное предупреждение о необходимости использовать сеттер-геттер, а не поле напрямую (например, при вызове сеттера может дергаться event....). В результате — необходимость следить за некоторыми соглашениями рукамию Тогда как можно было бы поручить это компилятору
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Re[3]: Чего не хватает в C#?
От: xvost Германия http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата: 08.12.05 08:36
Оценка: :)
Здравствуйте, Аноним, Вы писали:

X>>Цель — чтобы никто не мог даже изнутри класса достучатся до поля минуя сеттер/геттер проперти

А>Кто это — никто? Назови ее _buf0725416829 — волосы станут мягкими и шелковистыми.

После этого первый же code review мне настучит больно-больно.....
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Re[5]: Чего не хватает в C#?
От: Mab Россия http://shade.msu.ru/~mab
Дата: 09.12.05 11:49
Оценка: +1
А>Чем это отличается от
А>
А>public int Number;
А>

Хотя бы тем, что вводя property получаешь возможность менять реализацию с сохранением интерфейса сборки.
Re[2]: Чего не хватает в C#?
От: Павел Кузнецов  
Дата: 10.12.05 15:55
Оценка: +1
IT,

> Мне на сегодняшний день по большому счёту не хватает одной простой вещи — возможности запустить свои шаловливые ручки в кишочки компилятора, а точнее — вмешаться в процесс генерации кода.


[http://research.microsoft.com/phoenix/]Phoenix[/url] тебе поможет. Вопреки рассказам о чудесах оптимизации он именно для этого и предназначен. Его новизна как раз не в "глубине" выполняемых оптимизаций, а в том, что он работает с некоторым универсальным представлением, и к нему можно подключать в т.ч. и свои plugins.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 21:33
Оценка: +1
Здравствуйте, <Аноним>, Вы писали:

А>Ааа... Так надо сразу было написать, что это, типа, книжка такая есть.

А>Ты для примера года три побарабань по клаве, оттестируй, сдай, зайди за новой версией, перепиши, оттестируй, сдай...

Слушай, кончай заниматься провокациями. Ты явно не здоровую обстановку создаешь. А я как-то не люблю этого... особенно когда это делается из под анонима.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 22:01
Оценка: :)
Здравствуйте, Павел Кузнецов, Вы писали:

>> Мне на сегодняшний день по большому счёту не хватает одной простой вещи — возможности запустить свои шаловливые ручки в кишочки компилятора, а точнее — вмешаться в процесс генерации кода.


ПК>[http://research.microsoft.com/phoenix/]Phoenix[/url] тебе поможет. Вопреки рассказам о чудесах оптимизации он именно для этого и предназначен. Его новизна как раз не в "глубине" выполняемых оптимизаций, а в том, что он работает с некоторым универсальным представлением, и к нему можно подключать в т.ч. и свои plugins.


Паш, во преки ярлыкам которые тут фигачат на право и на лево — это срердство иниверсальное. Это замена бэкэнда и этим все сказано. Феникс и для оптимизаций подойдет, и для инструментирования, и для бэкэнд-АОП с метапрограммированием.

Вот только одна беда. Не очень то он пока доступен. Только преальфа и та закрытая.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 11.12.05 06:58
Оценка: +1
Здравствуйте, VladD2, Вы писали:

ie>>Устроить на RSDN голосование. А те пункты, что поддержит большинтсво, запостить в майкрософт. Ну и проголосовать всем RSDN, глядишь и толк будет.


VD>Или на худой конец устроить голосование о том какое спиртное нужно пить.


Пить нужно пиво

VD>В общем, бред это. Не может толпа решать что лучше для языка, а что хуже. Язык — это отражение мировазрения тех кто его придумал и создал. Мы можем только предлагать свои варианты и просить авторов их учесть. А уже их право соглаиться с нами или нет.


Скорее всего, Вы не правильно меня поняли. Я ни коим образом, ни одной клеточкой своего мозга, я не хотел, что бы авторы C# делали за меня язык моей мечты. Да и, по меньшей мере, наивно и глупо полагать что такое возможно (по крайней мере на яву).
Безусловно, автор имеет свое сугубо личное мнение и идеи развития C#. Однако, если некоторые из присутствующих в этом топике идей совпадают с авторскими (а может даже натолкнут на новые) и помогут ему отпределиться с введением тех или иных фитч в язык, уже хорошо.

VD>В конце концов тут не клуб старых компиляторостроителей. Тут ведь контингент от студентов до Дворкина .


+1
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[4]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.12.05 23:21
Оценка: +1
Здравствуйте, IT, Вы писали:

VD>>>12. Вложенные области видиости в типах:

КО>>Тоже классная идея.

IT>Лучше сделать что-то типа scope и дать возможность задавать ему модификаторы типа public, protected, а также навешивать на него атрибуты, которые распространялись бы на всё что внутри scope.


Это и есть область видмости (прямой перевод). Что до модификаторов доступа, то не ясно на что они будут влиять и, главное, зачем?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 12.12.05 12:26
Оценка: +1
Здравствуйте, Кирилл Осенков, Вы писали:

Еще хотелось бы что-то вроде:

if (num in [1, 2, 3])
{
    ...
}
if (obj in<MyObjComparer> [obj1, obj2, obj3])
{
    ...
}
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[2]: Чего не хватает в C#?
От: OnThink Россия http://vassilsanych.livejournal.com
Дата: 12.12.05 13:53
Оценка: :)
ie>Еще хотелось бы что-то вроде:

ie>
ie>if (num in [1, 2, 3])
ie>{
ie>    ...
ie>}
ie>if (obj in<MyObjComparer> [obj1, obj2, obj3])
ie>{
ie>    ...
ie>}
ie>


-- Так они и жили,-- продолжала Соня сонным голосом, зевая
и протирая глаза, -- как рыбы в киселе. А еще они рисовали...
всякую всячину... все, что начинается на М.
-- Почему на М? -- спросила Алиса.
-- А почему бы и нет? -- спросил Мартовский Заяц.
Алиса промолчала.
-- Мне бы тоже хотелось порисовать, -- сказала она,
наконец. -- У колодца.
-- Порисовать и уколоться? -- переспросил Заяц.
Соня меж тем закрыла глаза и задремала. Но тут Болванщик ее
ущипнул, она взвизгнула и проснулась.
-- ...начинается на М,--продолжала она.--Они рисовали
мышеловки, месяц, математику, множество... Ты когда-нибудь
видела, как рисуют множество?
-- Множество чего? -- спросила Алиса.
-- Ничего, -- отвечала Соня. -- Просто множество!

... << RSDN@Home 1.2.0 alpha rev. 619>>
Re[8]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.12.05 07:32
Оценка: +1
Здравствуйте, vdimas, Вы писали:
V>Еще раз медленно по слогам. Вот здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=1532394&amp;only=1
Автор: vdimas
Дата: 11.12.05


V>Я описываю "самый базовый" класс для своих коллекций:

V>
V>public abstract class CollectionPreBase<T> : ICollection<T> 
V>{
V>       public abstract IEnumerator<T> GetEnumerator();
V>       public abstract int Count { get; }
V>       public abstract void Add(T item);
V>       public abstract void Clear();
V>       public abstract bool Remove(T item);
V>...
V>



V>И спрашивал, зачем мне объявлять эти абстрактные методы?

Я правильно понимаю, что ты намекаешь на то, что компилятор мог бы и сам добавить эти методы за тебя?
Или ты хочешь получить такой специальный класс с заведомо неполной реализацией интерфейса?
В шарпе постарались свести возможности всяких неявностей к минимуму. Ну вот например для того, чтобы когда поменяется определение ICollection<T>, компилятор ткнул тебя носом ровно в твой abstract class CollectionPreBase<T>. Теперь ты вынужден либо написать реализацию для нового члена интерфейса, либо объявить его абстрактным (и тогда компилятор ткнет тебя уже во всех неабстрактных потомков, где ты должен реализовать этого мембера).
Если бы компилятор дописывал к классу невидымые абстрактные методы для каждого нереализованного явно члена интерфейса, то ругань была бы во всех потомках. Представь, что в ICollection переименовали Count в Length. Ты забираешь код, компиляешь проект... И тебе выпадает штук 70 ошибок о том, что нет реализации CollectionPreBase<T>.Length. Теперь тебе надо разбираться, то ли в каждом классе вносить этот Length { get { return Count; }}; то ли еще что.
Таким образом, это требование явно описать свои намерения. Оно сродни запрету проваливаться сквозь case в switch.

Вариант, в котором такие методы просто не существуют, еще хуже. Через рефлекшн ты всегда можешь получить интерфейс мэп для класса, который реализует заданный интерфейс. Для абсолютно каждого мембера интерфейса должна быть ненулевая entry — абстрактный ли там метод, виртуальный, или обычный — неважно. Но он должен быть, иначе сломается Великий Кристалл
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.12.05 10:55
Оценка: +1
Здравствуйте, vdimas, Вы писали:

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


V>>>И спрашивал, зачем мне объявлять эти абстрактные методы?

S>>Я правильно понимаю, что ты намекаешь на то, что компилятор мог бы и сам добавить эти методы за тебя?
S>>Или ты хочешь получить такой специальный класс с заведомо неполной реализацией интерфейса?
S>>В шарпе постарались свести возможности всяких неявностей к минимуму. Ну вот например для того, чтобы когда поменяется определение ICollection<T>, компилятор ткнул тебя носом ровно в твой abstract class CollectionPreBase<T>. Теперь ты вынужден либо написать реализацию для нового члена интерфейса, либо объявить его абстрактным (и тогда компилятор ткнет тебя уже во всех неабстрактных потомков, где ты должен реализовать этого мембера).
S>>Если бы компилятор дописывал к классу невидымые абстрактные методы для каждого нереализованного явно члена интерфейса, то ругань была бы во всех потомках. Представь, что в ICollection переименовали Count в Length. Ты забираешь код, компиляешь проект... И тебе выпадает штук 70 ошибок о том, что нет реализации CollectionPreBase<T>.Length. Теперь тебе надо разбираться, то ли в каждом классе вносить этот Length { get { return Count; }}; то ли еще что.
S>>Таким образом, это требование явно описать свои намерения. Оно сродни запрету проваливаться сквозь case в switch.

V>Гм... а ключевое слово abstract в объявлении имени класса на что? Не нужно никуда "проваливаться" за пределы абстрактного класса, поэтому кол-восообщений о такой ошибке "class does not implement ..." будет прежним.

Это с чего это прежним? Как компилятор отличит "случайно" не указанный Length в твоем абстрактном классе от намеренного, как требование перекрыть его в наследнике? Я вот что-то не понимаю.

V>Ээээ... А нас более интересует таблица методов некоего абстрактного типа, или оная у неких конкретных инстансов в момент вызова метода через интерфейс?

Любая. У тебя есть некий Type. Ты можешь попросить у него GetInterfaces(). Можешь попросить GetInterfaceMap(). И у этого InterfaceMapping для каждого из InterfaceMethods должен быть TargetMethod. Причем не равный Null.
V>Понимаешь, 2-е не применимо к 1-му, с счастью.

V>Тут еще 1 момент есть. Абстрактные методы — они же виртуальные неявно.

Ну почему же неявно. Вполне явно.
V>Неконсистентность с возможностями имплементации методов интерфейсов в аналогичном случае. Кристалл и так не совсем чист.
Все консистентно. Неясно, зачем тебе декларировать абстрактные методы в базовом классе, если тебе так хочется использовать невиртуальные методы в его потомках.
Зачем тебе такой базовый абстрактный класс, если в нем нет общей функциональности? Расскажи пожалуйста, что в этом CollectionPreBase есть такого, что оправдывает его применение.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.12.05 10:55
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Я что-то не понял, где здесь демонстрация неочевидного момента? Похоже 1-в-1 на мой пример и так и просится контрвариантность.

Это демонстрация того, что я очень быстро умею тайпать такой код — даже в форум нежалко запостить Уже выработал привычку.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.12.05 11:55
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>С value-типами это правильное требование, а с ссылочными — никак. Сейчас мы можем написать:

V>
V>object obj = GetSomeObject;
V>if(obj is MyType) {
V>    MyType mt = (MyType)obj;
V>}
V>


V>Если написать MyType(obj), то это будет вызов конструктора от obj, что вовсе не требуется.

Не, не будет. Конструктор вызывается только через new MyType(obj).
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 13.12.05 16:39
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Это с чего это прежним? Как компилятор отличит "случайно" не указанный Length в твоем абстрактном классе от намеренного, как требование перекрыть его в наследнике? Я вот что-то не понимаю.


Ok, согласен. Да, компилятор C++ точно так же говорит мне при попытке создать экземпляр абстрактного класса, что его нет. Я не помню проблем с этим. Действительно, если метода нет, то надо сделать так, чтобы он был
А где сделать — решать тебе. И в чем толк повторения этих методов в абстрактном классе. Если я добавлю еще один метод в абстрактный класс для требований реализации изменений интерфейса, как ты привел пример, то мне точно так же компилятор даст по рукам во всех наследниках. Т.е. в чем бенефиты?


S>Все консистентно. Неясно, зачем тебе декларировать абстрактные методы в базовом классе, если тебе так хочется использовать невиртуальные методы в его потомках.


Компилятор требует.

S>Зачем тебе такой базовый абстрактный класс, если в нем нет общей функциональности? Расскажи пожалуйста, что в этом CollectionPreBase есть такого, что оправдывает его применение.


Дык, посмотри в код. Пяток методов для реализации коллекции с 0-ля я уже сэкономил.
Re[15]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 15.12.05 15:05
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

Отлично, смущает одна деталь — статически не указано, что класс-наследник обязан так же реализовать IEnumerable<T>

Че-то я никак не приучу себя думать терминами даункастинга и кастинга "вбок", то бишь приведение к интерфейсам
Re[11]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 18.12.05 08:02
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Блин. Не является метод реализующий интерфейс виртуальным. Ну, не является.


Я уже просто в шоке от твоей невнимательности. Я НЕ ГОВОРИЛ ТАКОГО, ибо это и так известно. Я лишь утверждал, что вызов метода через интерфейс происходит одинаково независимо от способа реализации этого метода — виртуальным или обычным.

VD>Виртуальный метод — это метод под который отведен слов в таблице метдов.


Вообще-то в дотнете все методы сведены в таблицу, это не С++ Ну да ладно, продолжай...

VD>А метод реализующий метод интерфейса — это всего лишь наличие соотвествующего переходника в интерфейсной карте.


В карте конретного интерфейса

VD>Да будет тебе извесно для вызова метода интерфейса донет даже приведения не делает. То есть код вроде:

VD>
VD>ITest itf = (ITest)new A();
VD>


Стоп, или путаница терминов, или заблуждение. Для хранения — действительно не делает, ибо храним мы всегда Ssytem.Object, даже есл у нас тип переменной — интефейс, а вот для вызова...

VD>никакого приведения типов не делает. Оно попросту не нужно. В любом случае при вызове метода будет обращение к интерфейсномой карте откуда будет вынут адрес реального метода. Потому вызов метода интерфейса в 2-2.5 раза медленее чем виртуального метода.


Можно я посчитаю извлечение интерфейсной карты при вызове метода через интерфейс тем самым приведением, которое выполняется КАЖДЫЙ РАЗ при вызове метода через интерфейс? Потому и вызов в 2 раза медленнее... (технически — лишний уровень коссвенности)

Особенно эта схема прикольно работает для COM-объектов. Получили интерфейс нужного типа, обрадовались... Потом вызвали метод через интерфейс — ан нет, ошибка кастинга (QueryInterface говорит, что нет такого интерфейса-то...)


V>> Ведь наследников могут и опосля грузануть в домен, а базовый-то уже загружен и вызов виртуального метода кое-где заинлайнен... Как быть, если мы подадим туда экземпляр свежезагруженного наследника?


VD>Нельзя вызвать метод у наследника обладая ссылка на родителя. Если ссылка на наследника, то все карты проинициализированы и вызов пойдет туда куда надо.


Чего-чего? При чем тут это и вопрос инлайнига????

Вот тебе пример:
Base b = GetSomeObj();
b.SomeVirtualMethod();

Попробуй объяснить мне, как именно сдесь работает инлайнинг. Я тебя прошу об этом уже 3-й пост, а ты мне то статические методы приводишь, то вообще непонятно что...


VD>Короче, поверь человеку который с этим разбирался.


Не только ты смотрел как эти таблицы устроены и как реально выглядит вызов методов в асме.. И что с того? У меня есть те же исходники Shared CLI, при чем тут они и вопрос инлайнинга?


V>>IEnumerator<T> аналогичным образом наследует IEnumerator.


VD> Он не наследует, он унаследован от IEnumerator. И что?


Это, типа, для поддержания разговора?
И ничего. Подсказать как вспомнить о чем речь?


VD>Реализация IEnumVariant это часть реализации коллекции.


Угу, очень хорошо делается на STL и итераторах.

VD>В коде переходника ты не через интерфейс делашь вызов, а напрямую.


В коде переходника я вызывал абстрактный метод, пока мне синклер не показал, как это дело замедлить еще в 2 раза, провда, избавив от лишних абстрактных методов.


VD>Ты демонстрирушь совершенно бредовый код. Не понимшь что тебе два человека говорят, а потом еще и упрекашь, в том что тебе банальности говорят. Здорово.


Дык, привел бы нормальный код. Все что ты говрил не укладывалось на статическую систему типов. Вот Синклер приводил пример — первый был некомпилируем, второй содержал динамическое приведение. Я вообще разговор начал с того, что была бы контровариантность — все было бы ok.

V>>Правда, все это я могу теперь сделать с помощью типизированного generic-базового класса для кастомных наследников, в котором пропишу все эти методы-переходники. Вот тебе тот самый пример, где я буду писать переходники, т.е. мне фича контрвариантности реально нужна.


VD>Так, тогда о чем речь?


Об еще большего избавления от рутины.
Re[2]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.12.05 17:05
Оценка: +1
Здравствуйте, xvost, Вы писали:

Лучше уж оставить синтаксис абстрактных свойств, но если они не абстрактные, то автоматом генерить реализацию.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[4]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.12.05 17:05
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>1. Проперть с дефолтной реализацией:

S>
S>public int Number {}; 
S>

S>эквивалентное следующему:
S>
S>public int Number
S>{
S>   get 
S>     { return inner; } 
S>     set
S>     { inner = value; }
S>}
S>


Плохо. Дело в том, что практическая ценность события, на которое можно только подписаться или только отписаться не очень ясна. А вот свойства только с get встречаются едва ли не чаще, чем свойства с get/set. Так что get/set нужно указывать даже в минимальном варианте.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[15]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка: +1
Здравствуйте, Дарней, Вы писали:

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


VD>>Так назови хоть один довод против функционального стиля. Ну, кроме похожести на функцию.


Д>а что, понятность кода — этого уже недостаточно?


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

Пример я приводил. Из него четко видно, что функциональный стиль куда понятнее.

Д>а ты назови хоть один довод против записи с явным указанием ключевого слова cast


Неуныжное удлиннени кода. Шарп и так этим страдает. Зачем же ухудшать обстановку? Плюс это ровным счетом ничего не меняет, так как без проблем можно создать функцию cast<T>().

Д>не смущает, потому что typeof — это ключевое слово, которое имеется в языке в количестве 1 (одна) штука.


Ну, а partial, yald и многие другие ключевыми словами не являются. Это не смущает?
int yield = 0;
Console.WriteLine(++yield);



Еще раз повторюсь. Нет никакой разницы между методом преобразующим один тип в другой и оператором. Это все надоуманные догмы связанные с тем что ты привык к С-шному синтаксису. Те кто пишет на языках с функциональным приведением типов не испытывают комплексов по этому поводу.

Что же касается длинных префиксов, то С++ уже хорошо показал, что это не лучший путь. Многие избегают С++-ные привдения именно по причине их излишней длинных.

VD>>Я постоянно вижу.


Д>интересно, в каком коде и зачем они там нужны?


Везде где есть привдение типов. В общем, как только начинашь проектировать код в понятих типов, то и приведения получаются и операторы.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Вообще-то в дотнете все методы сведены в таблицу, это не С++ Ну да ладно, продолжай...


Все намного сложнее. К сожелению корректное изложение этого вопроса тянет на статью и в нем очень легко ошибиться. Так что пока что я воздержусь от этого. Лучше потом написать статейку с полными выкладками.

VD>>А метод реализующий метод интерфейса — это всего лишь наличие соотвествующего переходника в интерфейсной карте.


V>В карте конретного интерфейса


Опять таки, это все не простые вещи.

VD>>Да будет тебе извесно для вызова метода интерфейса донет даже приведения не делает. То есть код вроде:

VD>>
VD>>ITest itf = (ITest)new A();
VD>>


V>Стоп, или путаница терминов, или заблуждение. Для хранения — действительно не делает, ибо храним мы всегда Ssytem.Object, даже есл у нас тип переменной — интефейс, а вот для вызова...


Вот фиг тебе. В МСИЛ-е все переменные типизированны. Другое дело, что когда джит генерирует код, он делает многие проверки статически. Это приводит к тому, что код генерируемый им эти проверки уже не содержит.

V>Можно я посчитаю извлечение интерфейсной карты при вызове метода через интерфейс тем самым приведением, которое выполняется КАЖДЫЙ РАЗ при вызове метода через интерфейс? Потому и вызов в 2 раза медленнее... (технически — лишний уровень коссвенности)


Нельзя. Проверка типа делается. Но джитом и задолго до того как код будет выполнен. А вот извлечение адреса метода из карт — это чисто технический код. И если там не будет нужного указателя, то просто произойдет AV и т.п.

V>Особенно эта схема прикольно работает для COM-объектов. Получили интерфейс нужного типа, обрадовались... Потом вызвали метод через интерфейс — ан нет, ошибка кастинга (QueryInterface говорит, что нет такого интерфейса-то...)


Для большинства КОМ-объектов генерируется RCW (Runtime Callable Wrapper) — управляемые обертки которые предоставляют для CLR родной тип транслирующий все вызовы. При этом все работает значительно сложнее. Так что этот вопрос вообще нужно разбирать отдельно.

V>>> Ведь наследников могут и опосля грузануть в домен, а базовый-то уже загружен и вызов виртуального метода кое-где заинлайнен... Как быть, если мы подадим туда экземпляр свежезагруженного наследника?


VD>>Нельзя вызвать метод у наследника обладая ссылка на родителя. Если ссылка на наследника, то все карты проинициализированы и вызов пойдет туда куда надо.


V>Чего-чего? При чем тут это и вопрос инлайнига????


Это я отвечал на твои заявления. Что же касается инлайнинга, то в твоем коде нет вызова метода интерейса. Там есть вызов внутреннего метода класса который к тому же матится на интерфейс. И инлайнитг там более чем возможен.

V>Вот тебе пример:

V>
V>Base b = GetSomeObj();
V>b.SomeVirtualMethod();
V>


Твоей пример несколько иной.
using System;
using System.Diagnostics;

interface ITest1
{
    int F();
}

interface ITest2
{
    int X();
}

class A : ITest1, ITest2
{
    public int F()
    {
            Debugger.Break();
            return 8;
    }
    
    public int X() { return F(); }
}

class Program
{
    static void Main()
    {
        Console.WriteLine(((ITest2)new A()).X());
    }
}


То есть метод являющийся реализацией метода интерфейса ITest1 вызвается не через интерфейс, а напрямую как публичный метод класса A.

В общем, я не поленился запустить этот тест в релизе без отладчика и подключиться потом отладчиком. Вот колстэк:
mscorlib.dll!System.Diagnostics.Debugger.Break() + 0x56 bytes    
ConsoleApplication1.exe!A.X() + 0x5 bytes    
ConsoleApplication1.exe!Program.Main() + 0x13 bytes

А вот код метода A.X():
00000000  call        787B2D20 
00000005  mov         eax,8 
0000000a  ret


Все ясно? Или сечас мы услышим "ну, все таки..."?

Сечас смотрел телевизор и там Рост (актер) сиграл забавную сценку.

Сидит мент и ведет допрос связанного врача.
Метн:
— Вы продолжаете утверждать, что труп был мертв до вскрытия, а не умер от вскрытия?
— Да.
— Может быть вы перед тем как начать вскрытие измерили пулс?
— Нет.
— А, может быть Вы измерели температуру?
— Нет.
— Вы пощупали пульс?
— Нет?
— Тогда, может быть, Вы хотя бы поднесли ко рту трупа зеркало, чтобы убедиться, что он не дышит?
— (с ужасом и отчаяньем в голосе) Нет!
— Тогда почему же Вы так ТУПО и УПРЯМО твердите, что труп был мертв?!!!
— Да потому что его привизли ко мне без головы!


V>Попробуй объяснить мне, как именно сдесь работает инлайнинг. Я тебя прошу об этом уже 3-й пост, а ты мне то статические методы приводишь, то вообще непонятно что...


Ты подменил предмет разговора. Здесь инлайнинг правда, тоже возможен. Но для этого прийдется применять сложные оптимизации основанные на безе анализа потока управления. Однако твой случай совершенно другой. В нем не производится вызова через безовый класс или нитерфейс. Ты почему-то считашь, что если метод реализует интерфейс, то он обязан вызваться виртуально всегда. А я тебе уже два дня пытаюсь объяснить, что это совсем не так.

VD>>Короче, поверь человеку который с этим разбирался.


V>Не только ты смотрел как эти таблицы устроены и как реально выглядит вызов методов в асме.. И что с того? У меня есть те же исходники Shared CLI, при чем тут они и вопрос инлайнинга?


Если бы ты с разобрался с этим вопросом, то нам и разговаривать было бы не о чем.


V>И ничего. Подсказать как вспомнить о чем речь?


Давай.

VD>>Реализация IEnumVariant это часть реализации коллекции.


V>Угу, очень хорошо делается на STL и итераторах.


Казалось бы, причем тут STL?

Может лучше тебе что-то подсказать?

VD>>В коде переходника ты не через интерфейс делашь вызов, а напрямую.


V>В коде переходника я вызывал абстрактный метод,


Да с чего метод стал абстрактным? Ты просто переходик сдела. Все!

V>пока мне синклер не показал, как это дело замедлить еще в 2 раза, провда, избавив от лишних абстрактных методов.


Я тебе показал код который вообще избавляет от необходимости создавть как абстрактный класс, так и реализовывать интерфейсы в нем. Но ты смело проигнорировал мои слова.

V>Дык, привел бы нормальный код.


Я его привел. Снизайди до милости, погляди его внимательно:
Re[8]: Чего не хватает в C#?
Автор: VladD2
Дата: 14.12.05

Если тебе сложно его откапать, то процитирую его:
using System;

interface ITest
{
    void Method1();
    void Method2();
    void Method3();
}

class BaseA
{
    public void Method1() { Console.WriteLine("BaseA.Method1();"); }
}

class BaseB : BaseA
{
    public void Method2() { Console.WriteLine("BaseB.Method2();"); }
}

class Test : BaseB, ITest
{
    public void Method3() { Console.WriteLine("Test.Method3();"); }
}

class Program
{
    static void Main()
    {
        ITest test = new Test();
        //Test test = new Test(); // если заменить этой строку предыдущую, то ничего не зименится!
        test.Method1();
        test.Method2();
        test.Method3();
    }
}

Код выведет:
BaseA.Method1();
BaseB.Method2();
Test.Method3();


Обрати внимание. Класс Test использует реализации методов из BaseB и BaseA. Сам же интерфейс реализуется только в классе Test. То есть Шарп сам ноходит методы в базовых классах и сопоставляет их с методами реализуемого интерфейса. Если вдруг потребуется переопределить метод реалзованный в базовм классе, то достаточно будет реализовать этот метод в наследнике:
class Test : BaseB, ITest
{
    public new void Method2() { Console.WriteLine("Test.Method2();"); }
    public void Method3() { Console.WriteLine("Test.Method3();"); }
}

Этот вариант выведет:
BaseA.Method1();
Test.Method2();
Test.Method3();


V> Все что ты говрил не укладывалось на статическую систему типов. Вот Синклер приводил пример — первый был некомпилируем, второй содержал динамическое приведение. Я вообще разговор начал с того, что была бы контровариантность — все было бы ok.


Еще раз. Ты много о чем говорил. Контрвариантность для твоих задач ненужна. Но даже если она нужна, то достаточно сделать перходник. Ты уже пошел обсуждать проблему инлайнинга. Точнее ты постоянно прыгашь с одной проблемы на другую. Большое ощущение, что ты специально пыташся избежать получения ответа на свои вопросы.

Итак, что ты на данный момент не понимшь?

V>Об еще большего избавления от рутины.


Где ты ее увидел? Это создание одного метода перходника порождает такую огромную рутину, что от нее нужно избавляться?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 23.12.05 07:51
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Так тогда и п.5 автоматом выполняется. Кстати, TypeId и так есть, Type.GUID называется, только он под свитч не прокатывает.


О том и речь... Его бы как-нить константно объявить, что ли..

AVK>Опять же — какую реализацию делать? Последовательное сравнение? Или как со строками — через хештаблицу?


на 64 битах это будет 2 слова, вполне подойдет обычное сравнение.
Re[10]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.12.05 09:14
Оценка: +1
Здравствуйте, VladD2, Вы писали:

AVK>>Главное — не надо ударяться в крайности. Я сторонник золотой середины, т.е. вполне допускаю варианты, когда вероятность ошибки незначительна, а набирать и читать проще.


VD>Ты проводил исследование по поводу того насколько незначительны будут проблемы связанные с этим делом? Я думаю — нет. Тогда и не нужно приводить это дело в качестве аргумента.


А ты проводил?

VD>В общем, лучше вообще не создавать грабли, чем анализировать их опасность.


Грабли тут с двух сторон. Осталось определить с какой стороны зубья короче.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[12]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.12.05 09:14
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>С этим уже поздняк метаться. Backward compatibility никто отменять не будет.


Вобщем да. Хотя можно не отключать совсем, а выдавать варнинг. Можно, кстати, и без изменения языка добавить правило для FxCop, которое приведенный ранее код будет отлавливать.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[8]: Чего не хватает в C#?
От: Воронков Василий Россия  
Дата: 24.12.05 01:16
Оценка: :)
Здравствуйте, VladD2, Вы писали:

ВВ>>Правильно. Так как Xxx<Y>() в С# — это синтаксис вызова функции пускай она так и выглядит.

VD>Это необоснованно удленненный синтаксис.

В таком случае предлагаю альтернативный вариант — as<Y>();
Re[7]: Чего не хватает в C#?
От: WolfHound  
Дата: 24.12.05 11:29
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>А в STL все используют оператор < и предикат less.

И ничего умнее деревьев на этом базисе построить нельзя.
A>На самом же деле вместо того чтобы сортировать объекты ты предлагаешь брать хеши объектов и сортировать уже их.
Зачем сортировать хеши? Нужно объяснять как работает хеш таблица?
A>ИМХО не самое эффективное решение,
Правда чтоли?
A>учитывая что хеш может считаться совершенно по-разному.
И что с того?

A>Более того, что обозначает хеш? Он ничего не обозначает!

А ему и не недо ничего обозначать. Достаточно его свойства что объекты с разным хешем не равны.
A>Если значения возвращённые GetHashCode() двух объектов равны, то возможно, равны и сами объекты.
Возможно.
A>К тому же чтобы получить хеш сложного типа надо испотльзовать все его значимые поля, а чтобы сравнить, скорее всего первые несколько.
A>Например чтобы получить хеш строки надо обработать все её символы, а чтобы сравнить две строки, возможно только первый.
Есть еще такое слово как кеш.

A>Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net


Блин Рома ну имей совесть... ну не надо называть одну из самых распространенных структур данных (хеш таблица) приблудой .НЕТ.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 11:35
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

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


A>>А в STL все используют оператор < и предикат less.

WH>И ничего умнее деревьев на этом базисе построить нельзя.

А switch это что?

WH>Зачем сортировать хеши? Нужно объяснять как работает хеш таблица?


Нужно объяснять как работает switch?

A>>Более того, что обозначает хеш? Он ничего не обозначает!

WH>А ему и не недо ничего обозначать. Достаточно его свойства что объекты с разным хешем не равны.

Только вот switch работает используя отношение, а не неравенство.

A>>Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net

WH>
WH>Блин Рома ну имей совесть... ну не надо называть одну из самых распространенных структур данных (хеш таблица) приблудой .НЕТ.

Ку-ку. Вы ещё здесь? Я говорю о реализации оператора switch для любых типов при чём тут структуры данных? Не понял о чём речь и круто посмеялся Ну я рад за тебя.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Чего не хватает в C#?
От: WolfHound  
Дата: 24.12.05 11:50
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>А switch это что?

Это покоцанный pattern matching.

A>Нужно объяснять как работает switch?

А как он работает? Вот только не надо расказывать про конкретную реализацию. switch это абстракция, а как она реализована это уже вопрос десятый.

A>Только вот switch работает используя отношение, а не неравенство.

Не switch, а конкретная реализация. Почувствуйте разницу.

A>Ку-ку. Вы ещё здесь? Я говорю о реализации оператора switch для любых типов при чём тут структуры данных?

Тута тута... при том что его реализация должна быть так или иначе основана на той или иной структуре данных.
A>Не понял о чём речь и круто посмеялся Ну я рад за тебя.
Все я понял. Просто ты почумуто считаешь что switch можно реализовать только на дереве. Я с этим не согласен.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 13:22
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>А как он работает? Вот только не надо расказывать про конкретную реализацию. switch это абстракция, а как она реализована это уже вопрос десятый.


Конкретных реализация две — замена на последовательность if выстроенную в двоичное дерево поиска и таблица преходов. Всё остальное не так эффективно на практике.

WH>Тута тута... при том что его реализация должна быть так или иначе основана на той или иной структуре данных.


Да, только требования очень разные и если хеш таблица это вообще очень хорошо, то в частности может оказаться не так уж и хорошо.

WH>Все я понял. Просто ты почумуто считаешь что switch можно реализовать только на дереве. Я с этим не согласен.


Нет, можно и на связаном списке реализовать. я говорю об эффективных на практике реализациях.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 03:38
Оценка: :)
Здравствуйте, adontz, Вы писали:

A>Это не одна и та же операция. new A(b) это deep copy, а A(b) скорее всего сохранит связь между объектами a и b.


Ключевое слово тут "скорее всего". И говорит оно о том, что ты в очередной раз начинашь выдумывать. А между тем все просто. И конструктор, и приведение типов, и любая другая функция с типом "A -> B" является всего лишь функцией "A -> B", т.е. преобразующей объкт типа A в объект типа B. И все! Все остальное предположения. Конечно любая такая функция может делать все что угодно. В плоть до создания побочных эффектов. Но все же в программировании рассчет ведется на разумность программиста. А это, в данном случае, значит, что если функция имеет побочный эффект или сложную семантику, то это должно быть отражено в названии метода. Так что ни конструкторы, ни приведения типа не должны содержать оной. Более того они должны быть максимально прозрачн. Я, как пользователь, должен получить из объекта А объект Б и не более того.

Посему твои предположения лучше исключить из рассмотрения. Иначе мы вынуждены будем признать, что ЯП вообще не имеют право на существования, так как любая функция может нести в себе все что угодно и полагаться на нее нельзя. А стало быть программировать вообще нельзя, так как даже программа "здравствуй мир!" не имеет четко определенного поведения, так как вызвает функции код которых мы не изучали.

A> Если тебе почему-либо всё ещё не понятно, то вот другой пример — тут уже разница есть и она огромная...


Примеров подтасавывающих результаты можно придумть очень много. Думаю не стоит тратить времени на их анализ.

A>И не надо говорить, что это пример надуманный.


Конечно не надо. Ты и сам это знашь.

A> Преобразование типа это не создание нового объекта. Это просто another view for the same content.


Это догмы человека который не хочет сбросить шоры и посмотреть на мир проще. Между тем приведение типа не определяет семантики. Это всего лишь любое преобразование типов. И как оно будет выполненно не важно.

A> Типичнейший пример — приведение к типу интерфейса не создаёт нового объекта.


Заметь! Один из примеров! А другой преобразование строки в массив символов. Почему при этом не порадить новый массив?

A>Влад, это грабли хотя бы потому что есть альтернативное мнение.


Это проблемы косности мышления. Смотри на проблему шире.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 25.12.05 12:05
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Откровенно говоря переубеждать тебя нет ни времени, ни желания. Так что давай завязывать.


Влад, не отклоняйся от сценария, это моя фраза была.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 26.12.05 09:55
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Ключевое слово тут "скорее всего". И говорит оно о том, что ты в очередной раз начинашь выдумывать. А между тем все просто. И конструктор, и приведение типов, и любая другая функция с типом "A -> B" является всего лишь функцией "A -> B", т.е. преобразующей объкт типа A в объект типа B. И все! Все остальное предположения. Конечно любая такая функция может делать все что угодно. В плоть до создания побочных эффектов. Но все же в программировании рассчет ведется на разумность программиста. А это, в данном случае, значит, что если функция имеет побочный эффект или сложную семантику, то это должно быть отражено в названии метода. Так что ни конструкторы, ни приведения типа не должны содержать оной. Более того они должны быть максимально прозрачн. Я, как пользователь, должен получить из объекта А объект Б и не более того.


is, as, new, return — это всего лишь обычные функции, по большому счету (список можно продолжить)
Зачем вообще понадобилось делать для них специальные синтаксические конструкции, как ты думаешь?

VD>Это догмы человека который не хочет сбросить шоры и посмотреть на мир проще. Между тем приведение типа не определяет семантики. Это всего лишь любое преобразование типов. И как оно будет выполненно не важно.


как ни печально, но догмы — у тебя

ЗЫ любопытно наблюдать, как человек наступает на те же самые грабли, что и люди, которых он сам раньше критиковал за то же самое
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 26.12.05 20:30
Оценка: +1
Здравствуйте, Кирилл Осенков, Вы писали:

Вот ещё бы чего хотелось. Впрочем, это не C#, а сам фреймворк. Причём сделать это можно за пару минут. Рехтуем класс Activator.

public sealed class Activator
{
    // ...

    public static object CreateInstance(Type type, bool nonPublic)
    {
        // ...

        object[] attrs = type.GetCustomAttributes(typeof(IObjectFactory), true);

        if (attrs.Length > 0)
            return ((IObjectFactory)attrs[0]).CreateInstance();

        // ...
    }

    // ...
}
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.06 12:12
Оценка: +1
Здравствуйте, pvgoran, Вы писали:

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


VD>>А зачем нужны такие извращения? Шарп — это ООЯ. Нафига нужно воодить еще один вид описания полиморфных методов? Я и так могу объявить виртуальный метод и переопределить его в классах.


P>А причем здесь C#?


Понятно. Ты голову подними и название темы прочти.


VD>>Я не спорю, что сопоставление с образцом было бы полезно. Но обычное. Та самая замена if-ам.


P>Ну, не знаю... По-моему, if'ы (или их замену) сопоставлением с образцом назвать можно только с большой натяжкой. Где в этом (и аналогичных) определениях образец?


if-ы не аналогичны. if-ы выполняют ту же роль. Ветвления выполнения по некоторому условию.

P>По сравнению с "нормальным" pattern matching'ом, в котором есть образец и назначение имен компонентам образца, ценность "if-сопоставления" выглядит не особенно большой.


Я не понимаю что такое "нормальным pattern matching". Мы уже вроде бы договорились, что полиморфизм отделяем. Вот и попробуй объяснить, что же такое в этом случае "нормальнымый pattern matching"?
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Чего не хватает в C#?
От: jorj  
Дата: 08.12.05 08:12
Оценка:
Здравствуйте, xvost, Вы писали:

X>Цель — чтобы никто не мог даже изнутри класса достучатся до поля минуя сеттер/геттер проперти


Странно это как-то, девелопер пишет класс и не знает как ему следует обращаться к полю: напрямую или через сеттеры/геттеры.
Если уж создатель класса не разбирает что-там к чему у него понаписано, то что говорить о других?
Re[4]: Чего не хватает в C#?
От: Аноним  
Дата: 08.12.05 10:08
Оценка:
Здравствуйте, xvost, Вы писали:

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


X>>>Цель — чтобы никто не мог даже изнутри класса достучатся до поля минуя сеттер/геттер проперти

А>>Кто это — никто? Назови ее _buf0725416829 — волосы станут мягкими и шелковистыми.

X>После этого первый же code review мне настучит больно-больно.....



Так загоняй все поля приватами во вложенный класс, геттеры-сеттеры внутри и снаружи. Какие проблемы... Кстати, что будет означать такая запись:



public int P1
{
  private int field1;
  get{return field2;}
  set {field3 = value;}
}
 
public int P2
{
  private int field1;
  get{return field1;}
}
Re[4]: Чего не хватает в C#?
От: Аноним  
Дата: 08.12.05 11:11
Оценка:
Здравствуйте, xvost, Вы писали:

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


X>>>Цель — чтобы никто не мог даже изнутри класса достучатся до поля минуя сеттер/геттер проперти

А>>Кто это — никто? Назови ее _buf0725416829 — волосы станут мягкими и шелковистыми.

X>После этого первый же code review мне настучит больно-больно.....


Наверно это очхреновая штука, если не стучит за красивые имена сущностей сомнительной семантики.
Re[3]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 08.12.05 11:36
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

[...skip...]

КО>А по поводу select-а, кажется они на это пошли, чтобы можно было показать IntelliSense.

КО>Если бы select стоял в начале, они бы не смогли предугадать, что я там собираюсь выбирать, т.к. не знали бы ещё откуда (from-то идёт ниже и ещё не напечатан!)

IntelliSense — вряд ли.
Почему-то с foreach таких заморочек небыло, а тут на тебе. А в для редактора эти проблемы должны решаться с помощью код-сниппетов, а не с помощью дескриминации читаемости выражений.

КО>Мне лично кажется from-where-select более разумным, чем select-from-where, ведь когда мы обращаемся к методам объекта, сначала идёт объект, а затем метод (поэтому и можно после нажатия на точку показать список методов объекта!).

КО>Другое дело мы уже к SQL привыкли...

То-то и оно
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 08.12.05 11:50
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Голосовать здесь


А, кстати, по поводу голосовать. Может собрать списочек того, что хотелось бы видеть. Например, из этого топика, пофлеймить с месяцок по поводу того, что действительно нужно, а что нет. Устроить на RSDN голосование. А те пункты, что поддержит большинтсво, запостить в майкрософт. Ну и проголосовать всем RSDN, глядишь и толк будет.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[2]: Чего не хватает в C#?
От: Аноним  
Дата: 08.12.05 12:06
Оценка:
Здравствуйте, ie, Вы писали:

ie>Здравствуйте, Кирилл Осенков, Вы писали:


КО>>Голосовать здесь


ie>А, кстати, по поводу голосовать. Может собрать списочек того, что хотелось бы видеть. Например, из этого топика, пофлеймить с месяцок по поводу того, что действительно нужно, а что нет. Устроить на RSDN голосование. А те пункты, что поддержит большинтсво, запостить в майкрософт. Ну и проголосовать всем RSDN, глядишь и толк будет.


Мне бы хотелось видеть C# образца FW1.1 еще лет пять-десять... Ну, чтобы там сидел специальный человек, затыкал свои дырки, присылал мне упдейты в виде сервиспаков, чтобы это называлось FW1.1... А у вас что не получается?..
Re[2]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 08.12.05 12:06
Оценка:
Здравствуйте, ie, Вы писали:

ie>А, кстати, по поводу голосовать. Может собрать списочек того, что хотелось бы видеть. [...] Ну и проголосовать всем RSDN, глядишь и толк будет.

Ну! А я о чём?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[4]: Чего не хватает в C#?
От: Аноним  
Дата: 08.12.05 12:24
Оценка:
Здравствуйте, ie, Вы писали:

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


А>>Мне бы хотелось видеть C# образца FW1.1 еще лет пять-десять... Ну, чтобы там сидел специальный человек, затыкал свои дырки, присылал мне упдейты в виде сервиспаков, чтобы это называлось FW1.1... А у вас что не получается?..


ie>Да вот не получается как-то. После того как попишешь на 2.0 с месяцок, на 1.1 почему-то не тянет.


Я по сабжу понял, у вас проблемно со всеми версиями? Давайте с примерами и иллюстрациями. Типа, писал-писал, под 1.1 и вот оно встало... Потом взял 2.0 — встало в другом месте...
Re[4]: Чего не хватает в C#?
От: jorj  
Дата: 08.12.05 13:11
Оценка:
Здравствуйте, Andrbig, Вы писали:

A>Здравствуйте, Кирилл Осенков, Вы писали:


КО>>Чтобы: если внутри свойства упоминается слово inner, компилятор бы автоматически генерировал private поле нужного типа.


A>С автогенерируемым названием, т.е. меняющимся от компиляции к компиляции — чтоб отбить любителей рефлекшена.


Что толку, от автогенерируемого идентификатора, если он юзается только в сеттере и геттере? Или Вы предлагаете все логику запихать в сеттер и геттер?
Re[5]: Чего не хватает в C#?
От: Andrbig  
Дата: 08.12.05 13:20
Оценка:
Здравствуйте, jorj, Вы писали:

J>Что толку, от автогенерируемого идентификатора, если он юзается только в сеттере и геттере? Или Вы предлагаете все логику запихать в сеттер и геттер?


Про логику не понял, а толк в текстовой совместимости и бинарной несовместимости между версиями.

А вообще-то моя мысль вытекла из вопроса — как именовать данное приватное поле inner? Добавлять подчеркивание? Два? Три? А если такое уже есть? В общем, тут еще есть вопросы.
Re[6]: Чего не хватает в C#?
От: jorj  
Дата: 08.12.05 13:28
Оценка:
Здравствуйте, Andrbig, Вы писали:

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


J>>Что толку, от автогенерируемого идентификатора, если он юзается только в сеттере и геттере? Или Вы предлагаете все логику запихать в сеттер и геттер?


A>Про логику не понял, а толк в текстовой совместимости и бинарной несовместимости между версиями.


A>А вообще-то моя мысль вытекла из вопроса — как именовать данное приватное поле inner? Добавлять подчеркивание? Два? Три? А если такое уже есть? В общем, тут еще есть вопросы.


во-первых, это получается уже не приватное поле inner, а просто локальная переменная, которая не видна извне, иначе опять же смысла в огороде нету.
во-вторых, при дизассемблировании, мне не важна локальная переменная, мне важна внутренняя логика всей реализации. Заметьте, что в этой самой имплементации везде будет обращение к нормально именнованному свойству класса.
Re[7]: Чего не хватает в C#?
От: Mab Россия http://shade.msu.ru/~mab
Дата: 09.12.05 10:10
Оценка:
Здравствуйте, jorj, Вы писали:
J>во-первых, это получается уже не приватное поле inner, а просто локальная переменная,
При чем тут локальная переменная? Насколько я понял, хочется, чтобы поле было видно всего в двух методах -- геттере и сеттере.
Re[8]: Чего не хватает в C#?
От: Аноним  
Дата: 09.12.05 10:44
Оценка:
Здравствуйте, Mab, Вы писали:

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

J>>во-первых, это получается уже не приватное поле inner, а просто локальная переменная,
Mab>При чем тут локальная переменная? Насколько я понял, хочется, чтобы поле было видно всего в двух методах -- геттере и сеттере.

Фактически, модификация статических полей в рамках функции. Давно присутсвует в С++. На заре развития C# некоторые его приверженцы (очень известные на форуме Философия Программирования ) открещивались от такой функциональности, называя это старым и ненужным наследием. Чтож, времена меняются.
Re[9]: Чего не хватает в C#?
От: Mab Россия http://shade.msu.ru/~mab
Дата: 09.12.05 10:46
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Фактически, модификация статических полей в рамках функции. Давно присутсвует в С++.

Казалось бы, в C++ видимость таких переменных ограничена одной функцией. Так что аналогия не совсем прямая.
Re[9]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 09.12.05 10:53
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Фактически, модификация статических полей в рамках функции. Давно присутсвует в С++. На заре развития C# некоторые его приверженцы (очень известные на форуме Философия Программирования ) открещивались от такой функциональности, называя это старым и ненужным наследием. Чтож, времена меняются.


Не правильная у Вас аналогия родилась. Идеология функций и пропертей достаточно разная, так что отождествлять смысла не имеет.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[4]: Чего не хватает в C#?
От: SiAVoL Россия  
Дата: 09.12.05 11:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я понимаю, что Настоящие Пацаны всегда набирают код руками, но те, кто пользуется клипбордом рискуют нарваться на

Настоящие Пацаны пользуют ReSharper

А так, идея с "виртуальным" полем мне тоже нравится. При всех своих достоинствах (недостатков я вообще пока не вижу) она легко реализуема на уровне компилятора.
... << RSDN@Home 1.2.0 alpha rev. 569>>
Re[5]: Чего не хватает в C#?
От: Аноним  
Дата: 09.12.05 11:42
Оценка:
Здравствуйте, SiAVoL, Вы писали:

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


S>>Я понимаю, что Настоящие Пацаны всегда набирают код руками, но те, кто пользуется клипбордом рискуют нарваться на

SAV>Настоящие Пацаны пользуют ReSharper

Настоящие Пацаны используют Code Snippets
Re[3]: Чего не хватает в C#?
От: dimchick Украина  
Дата: 09.12.05 11:43
Оценка:
Здравствуйте, ie, Вы писали:

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


D>>Дмитро Ніконов (Microsoft)

D>>Сьогодні розробники використовують одну мову програмування для написання вихідного коду програми, і зовсім іншу мову, наприклад SQL, для доступу до даних із СУБД. А якщо створити одну мову, що зможе достукатися й до даних об'єкта і до даних із СУБД, і до даних у форматі XML? Нове розширення до Visual Studio за назвою LINQ (Language Integrated Query) дозволяє писати запити до даних будь-якого формату й звертатися до об'єктів .NET, даних із XML і баз даних однаковим способом. У доповіді будуть продемонстровані можливості LINQ у новій версії Visual Studio, а також буде розказано про плани Microsoft у даній області.

ie>Ничерта не понял, но очень интересно

В 2-х словах: 13 декабря в Киеве будет конференция, проводимая Microsoft.
Одной из тем конференции будет обсуждение языка, который позволит обращаться к данным объекта и к данным в БД единообразно с помощью XML.
Re[10]: Чего не хватает в C#?
От: Аноним  
Дата: 09.12.05 11:44
Оценка:
Здравствуйте, Mab, Вы писали:

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


А>>Фактически, модификация статических полей в рамках функции. Давно присутсвует в С++.

Mab>Казалось бы, в C++ видимость таких переменных ограничена одной функцией. Так что аналогия не совсем прямая.

Смотрим на выделенные слова, думаем.
Re[4]: Чего не хватает в C#?
От: Аноним  
Дата: 09.12.05 11:45
Оценка:
S>1. Проперть с дефолтной реализацией:
S>
S>public int Number {}; 
S>

S>эквивалентное следующему:
S>
S>public int Number
S>{
S>   get 
S>     { return inner; } 
S>     set
S>     { inner = value; }
S>}
S>


Чем это отличается от
public int Number;

?
Re[4]: Чего не хватает в C#?
От: OnThink Россия http://vassilsanych.livejournal.com
Дата: 09.12.05 12:01
Оценка:
D>>>Дмитро Ніконов (Microsoft)
D>>>Сьогодні розробники використовують одну мову програмування для написання вихідного коду програми, і зовсім іншу мову, наприклад SQL, для доступу до даних із СУБД. А якщо створити одну мову, що зможе достукатися й до даних об'єкта і до даних із СУБД, і до даних у форматі XML? Нове розширення до Visual Studio за назвою LINQ (Language Integrated Query) дозволяє писати запити до даних будь-якого формату й звертатися до об'єктів .NET, даних із XML і баз даних однаковим способом. У доповіді будуть продемонстровані можливості LINQ у новій версії Visual Studio, а також буде розказано про плани Microsoft у даній області.

ie>>Ничерта не понял, но очень интересно

D>В 2-х словах: 13 декабря в Киеве будет конференция, проводимая Microsoft.
D>Одной из тем конференции будет обсуждение языка, ...

Жаль я на этом языке не разговариваю .
А вообще это рускоязычный форум.
... << RSDN@Home 1.2.0 alpha rev. 619>>
Re[5]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 09.12.05 12:01
Оценка:
Здравствуйте, <Аноним>, Вы писали:

S>>1. Проперть с дефолтной реализацией: [...]


А>Чем это отличается от

А>
А>public int Number;
А>

А>?

Поле не может быть членом интерфейса;
поле нельзя переопределить в производных классах (нельзя добавить или изменить реализацию);
нельзя подменить на свойство, которое делает что-то умное, не ломая клиентов;
могут возникнуть осложнения с Reflection;
и пр. и пр.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[7]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 09.12.05 12:01
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Мне не приходило в голову выгрузить 100тыс юзеров со всеми атрибутами из базы, чтобы потом часть атрибутов в том же произвольном порядке запихнуть в массив.


По меньшей мере глупо из моего поста делатьумозаключение о том, что мне приходило это в голову.

А>Ради бога, замените string[] на грязное ругательство,


На какое?

А>побалуйтесь мумпсоподобным синтаксисом,


Каким, каким синтаксисом??? Что-то я Вас перестаю понимать.

А>удовлетворитесь любым другим способом, но без тормозов и с обратной совместимостью


-1
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[8]: Чего не хватает в C#?
От: Аноним  
Дата: 09.12.05 12:13
Оценка:
Здравствуйте, ie, Вы писали:

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


А>>Мне не приходило в голову выгрузить 100тыс юзеров со всеми атрибутами из базы, чтобы потом часть атрибутов в том же произвольном порядке запихнуть в массив.


ie>По меньшей мере глупо из моего поста делатьумозаключение о том, что мне приходило это в голову.


Неужели? Вы выгрузили только имена необходимых юзеров а правильном порядке и таки пытаетесь запихнуть их в массив??

А>>Ради бога, замените string[] на грязное ругательство,


ie>На какое?


IEnumerator<string>

А>>побалуйтесь мумпсоподобным синтаксисом,


ie>Каким, каким синтаксисом??? Что-то я Вас перестаю понимать.


погугли MUMPS, тебе понравится

А>>удовлетворитесь любым другим способом, но без тормозов и с обратной совместимостью


ie>-1


Мы не местные
Re[4]: Чего не хватает в C#?
От: Merle Австрия http://rsdn.ru
Дата: 09.12.05 12:23
Оценка:
Здравствуйте, dimchick, Вы писали:

D>Одной из тем конференции будет обсуждение языка, который позволит обращаться к данным объекта и к данным в БД единообразно с помощью XML.

Это все уже неоднократно обсуждалось: http://rsdn.ru/?mid=1382740
Автор: AndrewVK
Дата: 14.09.05
, и даже специальную встречу на UG организовывали *LINQ посвященную.
А с Димой Никоновым мы как раз вчера долго и c удовольствием общались по этому поводу.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[9]: Чего не хватает в C#?
От: ie Россия http://ziez.blogspot.com/
Дата: 09.12.05 12:32
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Неужели? Вы выгрузили только имена необходимых юзеров а правильном порядке и таки пытаетесь запихнуть их в массив??


Код который я привел был написан исключительно для примера. Тебе знакомо такое понятие — пример. Если не нравится пример с юзерами, замени User на DirectoryInfo.

А>>>Ради бога, замените string[] на грязное ругательство,

ie>>На какое?
А>IEnumerator<string>

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

А>>>побалуйтесь мумпсоподобным синтаксисом,

ie>>Каким, каким синтаксисом??? Что-то я Вас перестаю понимать.
А>погугли MUMPS, тебе понравится

Не понравилось.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[10]: Чего не хватает в C#?
От: Аноним  
Дата: 09.12.05 12:59
Оценка:
Здравствуйте, ie, Вы писали:

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


А>>Неужели? Вы выгрузили только имена необходимых юзеров а правильном порядке и таки пытаетесь запихнуть их в массив??


ie>Код который я привел был написан исключительно для примера. Тебе знакомо такое понятие — пример. Если не нравится пример с юзерами, замени User на DirectoryInfo.


Ааа... Так надо сразу было написать, что это, типа, книжка такая есть.
Ты для примера года три побарабань по клаве, оттестируй, сдай, зайди за новой версией, перепиши, оттестируй, сдай...
Re[5]: Чего не хватает в C#?
От: Andrbig  
Дата: 09.12.05 15:07
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>А так, идея с "виртуальным" полем мне тоже нравится. При всех своих достоинствах (недостатков я вообще пока не вижу) она легко реализуема на уровне компилятора.


Где будет находиться это поле? В классе, там же где и свойство? А как тогда будет называться?
Re[6]: Чего не хватает в C#?
От: Mab Россия http://shade.msu.ru/~mab
Дата: 09.12.05 15:11
Оценка:
Здравствуйте, Andrbig, Вы писали:

A>Где будет находиться это поле? В классе, там же где и свойство? А как тогда будет называться?

Как-нибудь нечитаемо. Какая разница как именно?
Re[2]: Чего не хватает в C#?
От: _FRED_ Черногория
Дата: 10.12.05 10:28
Оценка:
Здравствуйте, IT, Вы писали:

IT>Мне на сегодняшний день по большому счёту не хватает одной простой вещи — возможности запустить свои шаловливые ручки в кишочки компилятора, а точнее — вмешаться в процесс генерации кода.


Для каких целей? Может я тоже помечтаю об этом Мало что ли RSharp'а и XCSharp'а?
<< RSDN@Home 1.2.0 alpha rev. 616 >> =01:22= [Windows 2003 — 5.2.3790.65536]
under «*none*»
Help will always be given at Hogwarts to those who ask for it.
Re[3]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 10.12.05 17:23
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>[http://research.microsoft.com/phoenix/]Phoenix[/url] тебе поможет. Вопреки рассказам о чудесах оптимизации он именно для этого и предназначен. Его новизна как раз не в "глубине" выполняемых оптимизаций, а в том, что он работает с некоторым универсальным представлением, и к нему можно подключать в т.ч. и свои plugins.

Надо будет повнимательнее посмотреть что это такое. С первого взгляда всё кажется очень сложным, что тоже является своего рода серьёзным препятствием.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Чего не хватает в C#?
От: vdimas Россия  
Дата: 10.12.05 17:50
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

Вот, выморозило только что:
    public class WidgetCollection : ICollection<Widget> {
        
        ...

        public IEnumerator<Widget> GetEnumerator() {
            Widget w = _widgetHost.FirstChild;
            while (w != null) {
                yield return w;
                w = w._next;
            }
        }

        System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() {
            return GetEnumerator();
        }

        ...
    }


С какой стати я должен был еще писать выделенное? Почему невозможно переопределить виртуальный метод или оный из интерфейсов, если возвращаемое значения совместимо по типу?

В общем, идиотизм.


В С++ я могу так:
// интерфейсы
struct I1 {};

struct I2 {
    virtual I1* m1()=0;
};


// реализация
struct R1 : I1 {};

struct S2 : I2 {
    R1* m1() { return new R1(); };
};
Re[8]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 21:33
Оценка:
Здравствуйте, Mab, Вы писали:

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

J>>во-первых, это получается уже не приватное поле inner, а просто локальная переменная,
Mab>При чем тут локальная переменная? Насколько я понял, хочется, чтобы поле было видно всего в двух методах -- геттере и сеттере.

А какой тогда смысл на него вообще смотреть? Пусть уж его вообще видно не будет. Ну, создаст для него компилятора имя вроде __адв98AF2C0F_BD40_469a_9C8D_E6041A092AB6 и фиг бы с ним. А вот синтаксис должен быть как можно кратче. Иначе из-за чего огород городить. Менять такие поля приходится редко, а уж если нужно логику наворачивать, то и текущий синтаксис подойдет.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 21:33
Оценка:
Здравствуйте, SiAVoL, Вы писали:

S>>Я понимаю, что Настоящие Пацаны всегда набирают код руками, но те, кто пользуется клипбордом рискуют нарваться на

SAV>Настоящие Пацаны пользуют ReSharper

И как он позволяет сделать чтение исходников более простым процессом?

Я вот сейчас пользуюсь регионами чтобы уменьшить (визуально) декларацию свойств.

SAV>А так, идея с "виртуальным" полем мне тоже нравится. При всех своих достоинствах (недостатков я вообще пока не вижу) она легко реализуема на уровне компилятора.


В МС++ 2.0 уже вроде как реализована. Только пришлось вводить новое ключевое слово.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 21:33
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

А>>Чем это отличается от

А>>
А>>public int Number;
А>>

А>>?

КО>Поле не может быть членом интерфейса;

КО>поле нельзя переопределить в производных классах (нельзя добавить или изменить реализацию);
КО>нельзя подменить на свойство, которое делает что-то умное, не ломая клиентов;
КО>могут возникнуть осложнения с Reflection;
КО>и пр. и пр.

Главное из "пр." — это то, что на поле можно сделать ссылку и модифицировать его незаметно для класса где оно объеявлено, а для свойства ткой фокус не удастся, так что самое вожаное отличие заключается в том, что декларативное свойство не нарушает инкапсуляции, в отличии от поля.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 21:33
Оценка:
Здравствуйте, ie, Вы писали:

ie>А, кстати, по поводу голосовать. Может собрать списочек того, что хотелось бы видеть. Например, из этого топика, пофлеймить с месяцок по поводу того, что действительно нужно, а что нет. Устроить на RSDN голосование. А те пункты, что поддержит большинтсво, запостить в майкрософт. Ну и проголосовать всем RSDN, глядишь и толк будет.


Ага. Еще можно устроить голосование по поводу того каоково должно быть значение числа Пи в мирное время. Ну, решить голосованием какую минимальную зарплату должны платить программистам в России. Или на худой конец устроить голосование о том какое спиртное нужно пить.

В общем, бред это. Не может толпа решать что лучше для языка, а что хуже. Язык — это отражение мировазрения тех кто его придумал и создал. Мы можем только предлагать свои варианты и просить авторов их учесть. А уже их право соглаиться с нами или нет.

В конце концов тут не клуб старых компиляторостроителей. Тут ведь контингент от студентов до Дворкина .
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 22:01
Оценка:
Здравствуйте, vdimas, Вы писали:

V>
V>        System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() {
V>            return GetEnumerator();
V>        }
V>


А использовать using религия не позволяет? Глядишь и не так страшно было бы:
IEnumerator IEnumerable.GetEnumerator() { return GetEnumerator(); }
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 11.12.05 10:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>8. Добавление реализации (миксины, трэтсы).


Я искал что-то такое, но не мог выразить словами

VD>
VD>metamacro "using" CodeEmitFunc
VD>{
VD>    "using" "(" LocalVarDecl ")"
VD>        Block
VD>}
VD>

Раз уж мы решили отказаться от юзингов, встроенных в язык, то этот макрос должен сразу генерить код с try/finally, но в общем идея понятна.

VD>11. Декларативные свойства:

VD>int Property1 var { get; set; } // свойство со скрытой переменной
Здесь мне вариант Sinclair-а больше нравится:
int Property1 { }

По умолчанию, если пустые скобки, должно быть эквивалентно твоему варианту. Так лаконичнее.

VD>12. Вложенные области видиости в типах:

Тоже классная идея.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[3]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 11.12.05 22:35
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

VD>>12. Вложенные области видиости в типах:

КО>Тоже классная идея.

Лучше сделать что-то типа scope и дать возможность задавать ему модификаторы типа public, protected, а также навешивать на него атрибуты, которые распространялись бы на всё что внутри scope.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 12.12.05 03:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это и есть область видмости (прямой перевод). Что до модификаторов доступа, то не ясно на что они будут влиять и, главное, зачем?


Ну ладно, модификаторы я как-нибудь переживу, а вот атрибуты так поиметь хотелось бы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.12.05 03:19
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Чем это отличается от

А>
А>public int Number;
А>

А>?
Метаданными. Метакод получается проще, когда тебе не надо различать поля и свойства.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 12.12.05 04:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>3. Замена приведений типов с С-стиля на функциональный стиль. Например, вместо:

VD>
VD>A a = (A)b;
VD>

VD>будет писаться:
VD>
VD>A a = A(b);
VD>


а еще лучше, сделать разный синтаксис для (Button)control и (int)myLong
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[3]: Чего не хватает в C#?
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 12.12.05 05:00
Оценка:
Здравствуйте, jorj, Вы писали:

J>Странно это как-то, девелопер пишет класс и не знает как ему следует обращаться к полю: напрямую или через сеттеры/геттеры.


Это добавит ещё и возможность сложных расчетов внутри get/set, чтоб завел свои переменные и паришся с математикой.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Вселенная бесконечна как вширь, так и вглубь.
Re[4]: Чего не хватает в C#?
От: Curufinwe Украина  
Дата: 12.12.05 15:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вот только одна беда. Не очень то он пока доступен. Только преальфа и та закрытая.


Уже доступен. Несколько дней назад стал доступен для скачивания.
Но разбираться в нём действительно сложно
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[6]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.05 20:36
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ну ладно, модификаторы я как-нибудь переживу, а вот атрибуты так поиметь хотелось бы.


А с чем их ассоциировать?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.05 20:36
Оценка:
Здравствуйте, Curufinwe, Вы писали:

VD>>Вот только одна беда. Не очень то он пока доступен. Только преальфа и та закрытая.


C>Уже доступен. Несколько дней назад стал доступен для скачивания.

C>Но разбираться в нём действительно сложно

Да, это я уже понял. Просто Паша у нас по русски говорит все хуже и хуже и вместо того, чтобы что-то сказать все больеш улыбается.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 12.12.05 22:29
Оценка:
Здравствуйте, VladD2, Вы писали:

V>>Речь не об этом, а о том, что тип IEnumerator<Widget> совместим снизу вверх с IEnumerator, и мой метод IEnumerator<Widget> GetEnumerator() должен "покрывать" оба метода из этих интерфейсов. Не покрывает!!!


VD>Это ты говоришь о контрвариантности. Ее Шарп к сожалению не поддерживает (ну, почти... для делегатов она все же поддерживается).


Хорошо хоть это, спасибо за инфу. (Проверю этот момент и на сигнатурах параметров методов)

VD>В прочем не так уж часто она требуется.


Абсолютно согласен, если она требуется, то что-то не так в доме Облоньских в плане дизайна.
Может быть, кто-то нагнал пурги и сделал так:
public interface IEnumerable<T> : IEnumerable {
    IEnumerator<T> GetEnumerator();
}


Хотя надо было вот так:
public interface IEnumerable : IEnumerable<object> {}


причем, я хорошо понимаю причины, по которым так не сделали — чтобы иметь возможность пройтись по коллекции "чего угодно" в своих компонентных моделях и дизайнерах. Насколько часто такая задача стоит в run-time в реальных приложениях, где мы оперируем со своей известной системой типов?

Просто, если уж речь идет о задаче пройтись по коллекции "чего угодно", да еще очевидно в задачах, где и так рефлекшен используют, то банально можно так (в случае моего варианта наследования IEnumerable):
public class ObjectEnumeratorAdapter<T> : IEnumerator<object> {
    IEnumerator<T> _e;
    
    public ObjectEnumeratorAdapter(IEnumerator<T> e) {
        _e = e;
    }

    public object Current { get { return _e.Current; } }

    public bool MoveNext() { _e.MoveNext(); } 
    public void Reset() { _e.reset(); }
}


Всего делов.

А причины "унаследованности имеющегося кода" я даже рассматривать не хочу. Бинарно — все равно не унаследовались, а в плане исходников — невелики были бы переделки. Зато — "чистота линий".

V>>Т.е. нафига мне вообще второй раз писать GetEnumerator()?


VD>Это конечно прискорбно, но не думаю, что это хоть как-то может реально осложнить жизнь. Все же переходник пишется за пару секунд. Особенно в студии.


Понимаешь, мы от .Net ожидаем "чистоту линий". На дворе 2005-й год, все-таки. А твой ответ: "а тут по-быстрому это можно сделать, а в студии еще быстрей" напоминают мне мои собственные аргументы в защиту С++.

Но там хоть вопросы не так стояли, ты говорил что "долго" или "опасно", а тебе показывали как именно надо делать, чтобы было "не долго" и не "опасно".

Относительно .Net, я никого не спрашивал, как это сделать быстро. Я хочу знать — зачем я должен это делать?

V>>Мы тут получаем лишний уровень делегирования на ровном месте,


VD>Ну, это форменное притягивание за уши "жаренных фактов". Вызов может быть заинлайнен, .


Я смотрел на дизасемблированный код в отладчике без дебаг-информации и с включенной оптимизацией, и я нигде не видел инлайна при вызове даже собственных виртуальных методов, если у объекта есть наследжники. Если сам увидишь хоть раз подобное — покажи нам, ok?

VD>да и стоимость его на фоне создания итератора и его работы нивелируется


Создается итератор вроде быстро, или даром GC свой хлеб ест?

А вот со стоимостью ты загнул. В моем случае стоимость выполнения тела итератора, типа такого:
yield return el=el.next;
гораздо меньше чем затраты на его вызов. А тут целых 2 вызова. Итераторы — они же зааведомо имеют отношение не к единичным вызовам, коллекции разные бывают...


V>>не говоря уже о том, что это просто раздражает.


VD>Сдается мне, что у тебя сначало выработолось раздражение, а потом ты уже начал подбирать для него основания. Иначе бы ты был просто в бешенстве от несуразностей и глупостей имеющихся в плюсах.


То, что С++ практически полностью унаследовал С, в этом его была сила в момент становления популярности, но это же для него слабость теперь.

В те начала 90-х мне не требовалась "чистота линий и концепций", мне требовались адекватные инструменты для условий того времени. И С++ был, несомненно, вне всякой конкуренции. Сейчас я хочу большего, раз уж мы смирились с виртуальными машинами и пр. веяниями.

V>>А ведь это блин коллекции, и своих коллекций тонны...


VD>Да? И можно огласить список или хотя бы объяснить откуда у тебя берутся тонны коллекций?


Посмотри у себя в коде. Везде, где yield return — там твоя собственная коллекция.

V>>Какие-то ненужные строки в выделеном... В С++ мне достаточно было бы указать имплементацию только 3-х реально реализованных методов. Но даже написав такой early base все тоже не панацея, т.к. в наследниках надо писать override.


VD>Ну, почти убедил. Вот только одна загвоздка. В нашей С++-библиотеке код связанный с коллекциями занимал процентов 60, а то и более. А вот используя дотнет процент получается мизерным. Что я делаю не так?


Во-первых, в 60 не верю, но верю, что прилично.
Во-вторых, ты не использовал в STL, это тоже очевидно (или "недостаточно" использовал). Проект был на MFC/ATL?

Рекомендую так же PowerCollections. Код вокруг коллекций на .Net будет еще мизернее.

В третьих, ты тогда использовал компилятор, который не поддерживает частичные специализации, очевидно (или вы не использовали оную). Сейчас этот код на С++ может быть еще мизернее, чем на .Net с PowerCollections.


V>>2. при порождении абстрактного класса от интерфейса требуется явно указать все методы из интерфейса как abtract (если не имплементируем их). Можно подумать, что компилятор сам не в состоянии "дописать" абстрактные методы.


VD>Может спецификацию почитать? C# не делает методы интефейсов виртуальными.


А может, гораздо полезнее оппонента внимательней читать? Речь шла о базовых классах. Ну напиши, гражданин прочитавший спецификацию, те самые базовые классы коллекций без виртуальных методов. В предыдущем посте я даже код привел.

Я уже не говорю о том, что само замечание из разряда: "где это я?". Речь шла об обсуждении имплементации интерфейсов. Независимо от того — виртуальный метод или нет, вызов метода через интерфейс происходит абсолютно одинаково, независимо от "виртуальности" метода, реализующего интерфейсный. Поэтому нам однофигственно, виртуальный метод делать или нет.

Я не понимаю зачем мне надо описывать в базовом абстрактном классе те методы, которые я не собираюсь в нем имплементировать (он же абстрактный!!!). Ответа я пока не увидел.

VD>Ну, а реализовать интерфейс можно за пару секунд. Вставл на его имени в списке наследования, нажал Alt+Shift+F10...


Я не успеваю нажать, у меня сама эта менюшка выскакивает, что я делаю не так?

ДА и вообще, не о хелперах по расставлению подпорок речь. Речь о том, что относительно самых частоиспользуемых интерфейсов было принято откровенно "слабовольное" решение при переходе на генерики, и пути назад уже нет. Им или стоило добавить упомянутую возможность реализации интерфейсов как в С++ (блин, да ведь это копейки по сравнению с другими новшествами 2.0), или же унаследовать интерфейсы "наоборот", как я предложил, но потрудится переписать часть кода от 1.0 (1.1).

Мне, например, пришлось переписать даже часть кода при переходе к 1.1 от 1.0, и ничего, не умер.
Re[6]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.05 00:26
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Может быть, кто-то нагнал пурги и сделал так:

V>
V>public interface IEnumerable<T> : IEnumerable {
V>    IEnumerator<T> GetEnumerator();
V>}
V>


V>Хотя надо было вот так:

V>
V>public interface IEnumerable : IEnumerable<object> {}
V>


Полностью согласен. Так было бы правильнее. И об этом уже кто-то в Интернете говорил. Но IEnumerable уже есть. И он не таков. И в МС не решились менять сигнатуру.

V>причем, я хорошо понимаю причины, по которым так не сделали — чтобы иметь возможность пройтись по коллекции "чего угодно" в своих компонентных моделях и дизайнерах. Насколько часто такая задача стоит в run-time в реальных приложениях, где мы оперируем со своей известной системой типов?


Я что-то не понял. А что помешает пройтись по коллекции если она реализует и IEnumerable<T> (где T — тип элемента коллекции), и IEnumerable<object>?

Просто такое решение не сильно решает проблему о которой ты говоришь.

V>Просто, если уж речь идет о задаче пройтись по коллекции "чего угодно", да еще очевидно в задачах, где и так рефлекшен используют, то банально можно так (в случае моего варианта наследования IEnumerable):

V>
V>public class ObjectEnumeratorAdapter<T> : IEnumerator<object> {
V>    IEnumerator<T> _e;
    
V>    public ObjectEnumeratorAdapter(IEnumerator<T> e) {
V>        _e = e;
V>    }

V>    public object Current { get { return _e.Current; } }

V>    public bool MoveNext() { _e.MoveNext(); } 
V>    public void Reset() { _e.reset(); }
V>}
V>


V>Всего делов.


Опять не понял. А зачем все так усложнять?

V>Понимаешь, мы от .Net ожидаем "чистоту линий". На дворе 2005-й год, все-таки. А твой ответ: "а тут по-быстрому это можно сделать, а в студии еще быстрей" напоминают мне мои собственные аргументы в защиту С++.


Неужели эти аргументы настолько смешны?

Если серьезно, то проблемы есть и в Шарпе. Но описанная тобой, на мой взгляд, совсем не актуальна. Я бы с такой проблемой смог жить без проблем.

Что до чистоты, то ков/конт-вариантность прекрасно работает на ссылочных типах и не работает на вэлью-типах. Видимо это разработчиков и остановило.

V>Я смотрел на дизасемблированный код в отладчике без дебаг-информации и с включенной оптимизацией, и я нигде не видел инлайна при вызове даже собственных виртуальных методов, если у объекта есть наследжники. Если сам увидишь хоть раз подобное — покажи нам, ok?


Очень смешно. Ладно. Прочтем ликбез по банальному вопросу в стопервый раз.
Запустив из под отладчика дотнет-приложение ты никогда не увидишь ни одной оптимизации. Чтобы увидить оптимизированный код нужно подключиться к уже запущенному приложению. Сделать это можно, например, вставив в функцию вызво ассерта или дебаг-брэйка (надо рассказвать где они лежат?). Что же до примеров инлайнинга и оптимизации, то вот тебе классика:
public static int InlineTest(int iteration)
{
        Trace.Assert(false);
        return InlinedProc(ref iteration, 0x123456);
}

//[MethodImpl(MethodImplOptions.NoInlining)]
static int InlinedProc(ref int a,  int b)
{
        //Trace.Assert(false);
        return a & b;
}

Запусти этот код по Ctrl+F5 и нажатием Retry продключись к коду отладчиком. Увидшь, что в колстэке есть только InlineTest. Его код будет таким:
00000000  push        eax  
00000001  mov         dword ptr [esp],ecx 
00000004  xor         ecx,ecx 
00000006  call        798BCEEC 
0000000b  mov         eax,dword ptr [esp] 
0000000e  and         eax,123456h 
00000013  pop         ecx  
00000014  ret

италиком выделен код относящийся к вызову Trace.Assert().

Как видишь от вызова не осталось и следа. А теперь еще забавнее. Подставь вместо 0x123456 нолик. Как ты думашь что выйдет? Правильно, выйдет полное вычисление выражения во время компиляции:
00000000  push        eax  
00000001  mov         dword ptr [esp],ecx 
00000004  xor         ecx,ecx 
00000006  call        798BCEEC 
0000000b  xor         eax,eax 
0000000d  pop         ecx  
0000000e  ret


VD>>да и стоимость его на фоне создания итератора и его работы нивелируется


V>Создается итератор вроде быстро, или даром GC свой хлеб ест?


ЖЦ хест свой хлеб конечно не даром. И если его сравнивать с maloc/free и т.п., то он их порвет как тузик грелку сровнявлшись по скорости с пулами для конекретных случаев, но по сравнению со стоимостью вызова это очень нехилые затраты. И не нужно забывать, что итераторы просто так не создают. А ведь итератор это интерфейс у которого на каждой итерации вызвается два виртуальных метода (свойства). К тому же итератор это конечный автомат который производит вычисления. В общем, он не бесплатен. И на его фоне лишний вызов ничего не стоит.

V>А вот со стоимостью ты загнул. В моем случае стоимость выполнения тела итератора, типа такого:

V>yield return el=el.next;
V>гораздо меньше чем затраты на его вызов. А тут целых 2 вызова. Итераторы — они же зааведомо имеют отношение не к единичным вызовам, коллекции разные бывают...

Итератор вызвается ровно один раз. Далее возвращается объект по которому и происходит итерация. Ведь нет только контрвариантности, а приведение к интерфейсам еще никто не отменял. IEnumerator<T> же унаследован от IEnumerator. Так что в примере вроде:
class A : IEnumerable<int>, IEnumerable
{
    int[] _array = { 1, 3, 4, 8, 12 };

    public IEnumerator<int> GetEnumerator()
    {
        foreach (int i in _array)
            yield return i;
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

оверхэд для IEnumerable.GetEnumerator() будет не более чем на один метод при создании итератора. Вот если написать так:
class A : IEnumerable<int>, IEnumerable
{
    int[] _array = { 1, 3, 4, 8, 12 };

    public IEnumerator<int> GetEnumerator()
    {
        foreach (int i in _array)
            yield return i;
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        foreach (int i in GetEnumerator())
            yield return i;
    }
}

то действительно будет оверхэд.

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

V>То, что С++ практически полностью унаследовал С, в этом его была сила в момент становления популярности, но это же для него слабость теперь.


Согласен. Но проблемы С++ далего выходят за те что унаследованы от С. Ведь С при всех его недостатках язык очень простой. А С++ очень сложный. Вряд ли можно так унаследовать свойства, чтобы перевернуть их с ног на голову.

V>В те начала 90-х мне не требовалась "чистота линий и концепций", мне требовались адекватные инструменты для условий того времени. И С++ был, несомненно, вне всякой конкуренции. Сейчас я хочу большего, раз уж мы смирились с виртуальными машинами и пр. веяниями.


Полностью согласен! Но я еще не видел полностью безгрешных людй и полностью чистых линий. Хотя конечно хочется.

V>Посмотри у себя в коде. Везде, где yield return — там твоя собственная коллекция.


1. У меня нет тонн yield return-ов.
2. Не везде где у меня встречается yield return действительно имеется коллекция. Я использую yield return и для декомпозиции алгоритмов. Ведь в список и итерация есть судь два разных взгляда на одну проблему. Итераторы все же это еще и реализация континюэйшонов, и ДКА... в некотором смысле.

И все же где ты нашел тонны коллекций в дотнетеном коде? И почему у меня коллеции можно пересчитать на пальцах одной руки? С переходом на второй фрэймворк я вооще не ощущаю потребности в создании собственных сложных коллекций. Разве что наследуюсь от чего-то и расширяю функционал.

V>Во-первых, в 60 не верю, но верю, что прилично.


Скачай исходники ascDb. Они доступны.

V>Во-вторых, ты не использовал в STL, это тоже очевидно (или "недостаточно" использовал).


У меня были свои коллекции. А STL-ные были мне неудобны по некоторым причинам. Одна из них МС-ная реализация постоянно цепляла CRT от которого мы избавились для облегчения контролов (КОМ-контролов).

V> Проект был на MFC/ATL?


АТЛ.

V>Рекомендую так же PowerCollections. Код вокруг коллекций на .Net будет еще мизернее.


Знашь, я его видел скорее всего значительно раньше тебя. Он у меня валяется на диске. Но вот ни разу не воспользовался. Один раз хотел... В редакторе думал для хранения строк применить их BigList<T>, но провел эксперементы и оказалось, что на объемах строк приеменимых в редакторе кода обычный List<T> работает даже быстрее. Потом пару раз смотрел на их алгоритмы, но опять же на практике или хватало встроенных средств, или моя реализация оказывалась лучше. Хотя это уже отступление. Возомжно когд-нить я таки подцеплю эту библиотеку.

V>В третьих, ты тогда использовал компилятор, который не поддерживает частичные специализации, очевидно (или вы не использовали оную). Сейчас этот код на С++ может быть еще мизернее, чем на .Net с PowerCollections.


Да, не поддерживал. Но я сильно сомневаюсь, что я даже с ней получил бы такой кайф как в дотнете. Тут многие плюсовики наезжают на него называя негибким. Но, черт побери, коллекции на нем делаются влет! А мы занимались КОМ-ом, где просто std::vector ну никак не покатывал. Одно рисование интерфейса для КОМ-коллекции может в депресию загнать. А на дотнете я делаю коллекцию в пару нажатий. Ну, что может быть проще чем:
class MyCollection : System.Collections.ObjectModel.Collection<Item>
{
}



V>А может, гораздо полезнее оппонента внимательней читать? Речь шла о базовых классах.


Где?

V> Ну напиши, гражданин прочитавший спецификацию, те самые базовые классы коллекций без виртуальных методов. В предыдущем посте я даже код привел.


А зачем "без виртуальных"? Нахре на же на своих айцах то сидеть? Что экономишь то? Пусть лучше MS, Sun и IBM бабки в оптимизацию вкладывают. Глядишь и проблема исчезнет.

V>Я уже не говорю о том, что само замечание из разряда: "где это я?". Речь шла об обсуждении имплементации интерфейсов.


Вообще-то мема была... и есть... короче, читай сабжект... А ух кода там разговор отклонялся — это другое дело.

V> Независимо от того — виртуальный метод или нет, вызов метода через интерфейс происходит абсолютно одинаково, независимо от "виртуальности" метода, реализующего интерфейсный. Поэтому нам однофигственно, виртуальный метод делать или нет.


Ошибаешся. Все несколько по разному. Изучи, на досуге, вот этот пример:
using System;

interface ITest
{
    void Method1();
    void Method2();
}

class A : ITest
{
    public void Method1() { Console.WriteLine("A.Method1();"); }
    public virtual void Method2() { Console.WriteLine("A.Method2();"); }
}

class B : A
{
    public void Method1() { Console.WriteLine("B.Method1();"); }
    public override void Method2() { Console.WriteLine("B.Method2();"); }
}

class C : A, ITest
{
    public void Method1() { Console.WriteLine("C.Method1();"); }
    public override void Method2() { Console.WriteLine("C.Method2();"); }
}

class Program
{
    static void Main(string[] args)
    {
        ITest itf = new B();
        itf.Method1();
        itf.Method2();

        itf = new C();
        itf.Method1();
        itf.Method2();
    }
}

его вывод:
A.Method1();
B.Method2();
C.Method1();
C.Method2();


V>Я не понимаю зачем мне надо описывать в базовом абстрактном классе те методы, которые я не собираюсь в нем имплементировать (он же абстрактный!!!). Ответа я пока не увидел.


Ты же об интерфейсе говорил? С абстрактными классами все один в один как в С++.

VD>>Ну, а реализовать интерфейс можно за пару секунд. Вставл на его имени в списке наследования, нажал Alt+Shift+F10...


V>Я не успеваю нажать, у меня сама эта менюшка выскакивает, что я делаю не так?


Ты забыл сделать "...".

V>ДА и вообще, не о хелперах по расставлению подпорок речь.


Знаешь, смешно про подпорки слышать в контексте сравнения с С++. От где подпорка на подпорке. На самом языке вообще мало чего можно написать. Сразу нужно идти подпорки страгать. Хочешь память занять — изволь настрогать подпорку хэлпер. Колбэк метода — подпорку вроде boost::bind...

V> Речь о том, что относительно самых частоиспользуемых интерфейсов было принято откровенно "слабовольное" решение при переходе на генерики, и пути назад уже нет. Им или стоило добавить упомянутую возможность реализации интерфейсов как в С++ (блин, да ведь это копейки по сравнению с другими новшествами 2.0), или же унаследовать интерфейсы "наоборот", как я предложил, но потрудится переписать часть кода от 1.0 (1.1).


Ты перескочил с (ко|контр)вариантности на реализацию интерфейсов. С интерфейсами и виртуальными методами в Шарпе все ОК. Дай бог другим языкам, чтобы в них все было так продумано и чисто. Ну, а (ко|контр)вариантность конечно бы не помешала бы. Вот только не так уж она актуальна, чтобы ради не столько слез проливать.

V>Мне, например, пришлось переписать даже часть кода при переходе к 1.1 от 1.0, и ничего, не умер.


Ну, ты крут.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.05 01:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

А>>Чем это отличается от

А>>
А>>public int Number;
А>>

А>>?
S>Метаданными. Метакод получается проще, когда тебе не надо различать поля и свойства.

Извини, но это глупость. Они в принципе разные! У них только синтаксис похож. Попробуй передать свойство по ссылке.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 13.12.05 01:52
Оценка:
Здравствуйте, VladD2, Вы писали:

IT>>Ну ладно, модификаторы я как-нибудь переживу, а вот атрибуты так поиметь хотелось бы.


VD>А с чем их ассоциировать?


Со всем что в скопе. Мне например хотелось бы такого счастья:

class MyClass
{
    [Bindable(false)]
    scope
    {
        public string Field1;
        public string Field2;
        public string Field3;
    }
}
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.05 02:49
Оценка:
Здравствуйте, IT, Вы писали:

IT>Со всем что в скопе. Мне например хотелось бы такого счастья:


IT>
IT>class MyClass
IT>{
IT>    [Bindable(false)]
IT>    scope
IT>    {
IT>        public string Field1;
IT>        public string Field2;
IT>        public string Field3;
IT>    }
IT>}
IT>


А не кажется ли тебе, что именно от этого пытались уйти разработчики Шарпа? Вспомни. Зачем они оказались от
public:

и перешли к указанию модификаторов у каждого поля и метода?

Мне кажется тут будет тоже самое. Да и с рефакторингом будет проблемы.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 13.12.05 02:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А не кажется ли тебе, что именно от этого пытались уйти разработчики Шарпа? Вспомни. Зачем они оказались от


Это я тебе привёл очень маленький пример, я бы даже сказал совсем масенький. Как только начинаешь пользоваться атрибутами по максимуму, то возникает проблема замусоривания ими всего кода.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 13.12.05 06:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Полностью согласен. Так было бы правильнее. И об этом уже кто-то в Интернете говорил. Но IEnumerable уже есть. И он не таков. И в МС не решились менять сигнатуру.


О том и речь... Начинается новая песня про новое поколение legacy кода? Не рано ли?

V>>причем, я хорошо понимаю причины, по которым так не сделали — чтобы иметь возможность пройтись по коллекции "чего угодно" в своих компонентных моделях и дизайнерах. Насколько часто такая задача стоит в run-time в реальных приложениях, где мы оперируем со своей известной системой типов?


VD>Я что-то не понял. А что помешает пройтись по коллекции если она реализует и IEnumerable<T> (где T — тип элемента коллекции), и IEnumerable<object>?


В том-то и дело, что при моем способе взаимного наследования IEnumerable никто не захочет реализовать IEnumerable<object>, все будут использовать типизированную версию интерфейса, поэтому понадобится некий хелпер в случае, если к нам приходит object и мы знаем, что он поддерживает IEnumerable<T> от неизвестного T, и хотим пройтись по его элементам.


VD>Если серьезно, то проблемы есть и в Шарпе. Но описанная тобой, на мой взгляд, совсем не актуальна. Я бы с такой проблемой смог жить без проблем.


не смешно, C# предполагается в новый весьма серьезный и долгоиграющий main-stream. Думаю, лет 10 отдадим этому, а тут такое начало

VD>Что до чистоты, то ков/конт-вариантность прекрасно работает на ссылочных типах и не работает на вэлью-типах. Видимо это разработчиков и остановило.


Что-то не сообразил в чем подвох. value-типы же не наследуются. Если ты про реализацию ими интерфейсов, то можно было бы генерить thunk-переходник при компиляции.

V>>Я смотрел на дизасемблированный код в отладчике без дебаг-информации и с включенной оптимизацией, и я нигде не видел инлайна при вызове даже собственных виртуальных методов, если у объекта есть наследжники. Если сам увидишь хоть раз подобное — покажи нам, ok?


VD>Очень смешно. Ладно. Прочтем ликбез по банальному вопросу в стопервый раз.


Это все известно, у меня прекрасно инлайнятся методы объектов. Речь шла о вызове объектом собственного виртуального метода.

VD>Итератор вызвается ровно один раз. Далее возвращается объект по которому и происходит итерация. Ведь нет только контрвариантности, а приведение к интерфейсам еще никто не отменял. IEnumerator<T> же унаследован от IEnumerator. Так что в примере вроде:


[скипнул код т.к. не по делу]

Если у нас енумератор от IEnumerator<T> и мы его сделли без yield return, в его с-ве T Current{get;} тот же момент.


VD>Так что бороться нужно не за устранение оверхэда в дотнете, а за устранение фобий и неправльного понимания у его пользователей.


V>>Рекомендую так же PowerCollections. Код вокруг коллекций на .Net будет еще мизернее.


VD>Знашь, я его видел скорее всего значительно раньше тебя. Он у меня валяется на диске. Но вот ни разу не воспользовался. Один раз хотел... В редакторе думал для хранения строк применить их BigList<T>, но провел эксперементы и оказалось, что на объемах строк приеменимых в редакторе кода обычный List<T> работает даже быстрее.


У них там недавно очередной релиз был. Состав их PoserCollections маловат, но это от того, что в "основном" составе хватает функциональности. Это как бы дописывание того, что не вошло во фреймворк (а могло бы, там совсем немного)

V>>В третьих, ты тогда использовал компилятор, который не поддерживает частичные специализации, очевидно (или вы не использовали оную). Сейчас этот код на С++ может быть еще мизернее, чем на .Net с PowerCollections.


VD>Да, не поддерживал. Но я сильно сомневаюсь, что я даже с ней получил бы такой кайф как в дотнете. Тут многие плюсовики наезжают на него называя негибким. Но, черт побери, коллекции на нем делаются влет! А мы занимались КОМ-ом, где просто std::vector ну никак не покатывал. Одно рисование интерфейса для КОМ-коллекции может в депресию загнать. А на дотнете я делаю коллекцию в пару нажатий. Ну, что может быть проще чем:

VD>
VD>class MyCollection : System.Collections.ObjectModel.Collection<Item>
VD>{
VD>}
VD>

VD>

Ты думаешь что с STL/boost сложнее? Да у тебя там не только выбор базовых классов больше, но и зачастую несколько важных параметров как стратегии/поведения натсраиваются. Просто, если речь шла о COM, то только в ATL 7.1 я увидел нормальные smart-поинтеры-адаптеры для хранения COM-объектов в агрегатах STL. До этого использовал самописные смарт-поинтеры и все было вполне нормально с STL+COM.

V>> Независимо от того — виртуальный метод или нет, вызов метода через интерфейс происходит абсолютно одинаково, независимо от "виртуальности" метода, реализующего интерфейсный. Поэтому нам однофигственно, виртуальный метод делать или нет.


VD>Ошибаешся. Все несколько по разному. Изучи, на досуге, вот этот пример:


не смешно, это как в другой ветке где ты пытался предположить, что я не знаю о существовании unsafe у компилятора C#. Я имел ввиду механику вызова, т.е. затраты на вызов метода объекта через интерфейс. Они не зависят от виртуальности целевого метода.

V>>Я не понимаю зачем мне надо описывать в базовом абстрактном классе те методы, которые я не собираюсь в нем имплементировать (он же абстрактный!!!). Ответа я пока не увидел.


VD>Ты же об интерфейсе говорил? С абстрактными классами все один в один как в С++.


Еще раз медленно по слогам. Вот здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=1532394&amp;only=1
Автор: vdimas
Дата: 11.12.05


Я описываю "самый базовый" класс для своих коллекций:


public abstract class CollectionPreBase<T> : ICollection<T> 
{
       public abstract IEnumerator<T> GetEnumerator();
       public abstract int Count { get; }
       public abstract void Add(T item);
       public abstract void Clear();
       public abstract bool Remove(T item);
...



И спрашивал, зачем мне объявлять эти абстрактные методы?


V>> Речь о том, что относительно самых частоиспользуемых интерфейсов было принято откровенно "слабовольное" решение при переходе на генерики, и пути назад уже нет. Им или стоило добавить упомянутую возможность реализации интерфейсов как в С++ (блин, да ведь это копейки по сравнению с другими новшествами 2.0), или же унаследовать интерфейсы "наоборот", как я предложил, но потрудится переписать часть кода от 1.0 (1.1).


VD>Ты перескочил с (ко|контр)вариантности на реализацию интерфейсов. С интерфейсами и виртуальными методами в Шарпе все ОК. Дай бог другим языкам, чтобы в них все было так продумано и чисто.


Вот еще мешает приведенный кусок кода. Если бы не надо было объявлять за непонятно каким лешим абстрактные методы, было бы гораздо чище. Компилятор не в состоянии это сделать сам???

V>>Ну, а (ко|контр)вариантность конечно бы не помешала бы. Вот только не так уж она актуальна, чтобы ради не столько слез проливать.


Кому как. Приведенный случай обощается не только на один этот метод в интерфейсах коллекций. У кого-то может быть развитая система типов и эта контрвариантность могла бы сэкономить ненужные строки кода
Re[9]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 13.12.05 09:32
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>И спрашивал, зачем мне объявлять эти абстрактные методы?

S>Я правильно понимаю, что ты намекаешь на то, что компилятор мог бы и сам добавить эти методы за тебя?
S>Или ты хочешь получить такой специальный класс с заведомо неполной реализацией интерфейса?
S>В шарпе постарались свести возможности всяких неявностей к минимуму. Ну вот например для того, чтобы когда поменяется определение ICollection<T>, компилятор ткнул тебя носом ровно в твой abstract class CollectionPreBase<T>. Теперь ты вынужден либо написать реализацию для нового члена интерфейса, либо объявить его абстрактным (и тогда компилятор ткнет тебя уже во всех неабстрактных потомков, где ты должен реализовать этого мембера).
S>Если бы компилятор дописывал к классу невидымые абстрактные методы для каждого нереализованного явно члена интерфейса, то ругань была бы во всех потомках. Представь, что в ICollection переименовали Count в Length. Ты забираешь код, компиляешь проект... И тебе выпадает штук 70 ошибок о том, что нет реализации CollectionPreBase<T>.Length. Теперь тебе надо разбираться, то ли в каждом классе вносить этот Length { get { return Count; }}; то ли еще что.
S>Таким образом, это требование явно описать свои намерения. Оно сродни запрету проваливаться сквозь case в switch.

Гм... а ключевое слово abstract в объявлении имени класса на что? Не нужно никуда "проваливаться" за пределы абстрактного класса, поэтому кол-восообщений о такой ошибке "class does not implement ..." будет прежним.

S>Вариант, в котором такие методы просто не существуют, еще хуже. Через рефлекшн ты всегда можешь получить интерфейс мэп для класса, который реализует заданный интерфейс. Для абсолютно каждого мембера интерфейса должна быть ненулевая entry — абстрактный ли там метод, виртуальный, или обычный — неважно. Но он должен быть, иначе сломается Великий Кристалл


Ээээ... А нас более интересует таблица методов некоего абстрактного типа, или оная у неких конкретных инстансов в момент вызова метода через интерфейс? Понимаешь, 2-е не применимо к 1-му, с счастью.

Тут еще 1 момент есть. Абстрактные методы — они же виртуальные неявно. Неконсистентность с возможностями имплементации методов интерфейсов в аналогичном случае. Кристалл и так не совсем чист.
Re[7]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 13.12.05 09:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Увы, так не получится. Дело в том, что не все языки поддерживают дженерики.

V>>причем, я хорошо понимаю причины, по которым так не сделали — чтобы иметь возможность пройтись по коллекции "чего угодно" в своих компонентных моделях и дизайнерах.
S>Нет. Для того, чтобы пользователи недженерикоподдерживающих языков могли пользоваться библиотеками с дженерик-поддержкой.
S>Для них IEnumerable<object> не существует. Ок, мы для них унаследовали не-дженерик версию интерфейса.
S>Но все равно не удается принудительно заставить разработчика коллекции предоставить доступ к IEnumerable...

Кстати, очевидный аргумент, thnx.


S>Единственный вариант, который бы прокатил — это поддержка контравариантности в реализациях интерфейсов. Но я подозреваю, что она чревата еще большим количеством неочевидных моментов.


S>Я уже привык к тому, что я могу делать специфичные версии методов, называя их так же. А в явных реализациях интерфейса просто делегировать вызов:


S>
S>public FileResource this[string name] 
S>{
S>  get 
S>    {
S>      ...
S>    }
S>}

S>IResource IResourceFolder.this[string name] { get { return this[name]; } };
S>


Я что-то не понял, где здесь демонстрация неочевидного момента? Похоже 1-в-1 на мой пример и так и просится контрвариантность.


S>Кстати, есть еще много мест в стандартной библиотеке, где дженерики бы отлично смотрелись. Например,

S>
S>T[] MemberInfo.GetCustomAttributes<T>(bool inherit) where T : Attribute
S>

S>вместо
S>
S>object[] MemberInfo.GetCustomAttributes(Type t, bool inherit);
S>

S>Увы — явно не хотелось загрязнять System.Reflection дженериками.

Да, с учетом первого аргумента — ты прав.
Re[2]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 13.12.05 10:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Понимаю, что большинство из описанных ниже улучшений вряд ли появятся в Шарпе, но уж если мечтать, то по полной программе.


VD>Все дальнейшие расуждения делаются отталкиваясь от C# 3.0. Если это не так оговорюсь отдельно.


VD>1. Введение в язык понятия функциональный тип. Отличия от делегата следующие. Может ссылатьсч только одну функцию/метод. Тип определяется сочетанием списка формальных параметров с типом возвращаемых значений, а не именем (как это происходит с делегатом). Это позволит автоматически приводить любую функцию к такому типу если она подходит по параметрам. Для такого типа должен быть реализовано атоматический вывод типов. Так код вроде:

VD>
VD>var f = (a, b) => a * b;
VD>

VD>должен порождать переменную f тип которой является функциональным типом о котором шла речь.
VD>Понятное дело, что функциональные типы должны быть совместимыми с соответсвтующими делегатами.

Т.е. речь идет об aliasing типов, я правильно понял? Все делегаты определенной сигнатуры должны быть совместимы м/у собой и с определенным неким автовыводимым типом. Не нарушая стройность системы типов, т.е. учитывая, что тип делегата — это такой же тип как все остальные типы, этой фичей (алиасингом) должна обладать сама система типов.

Да, иногда хочется завести ДРУГОЙ тип без наследования (и переопределения конструкторов и т.д.). Не как using или typedef в С++, а именно другой тип. Хотя, ключевое слово typedef мне нравится.

VD>2. (Ко/контр)вариантность где только это можно. То есть для всего что работает со ссылочными типами начиная от методов, свойств индексеров и кончая интерфейсами и колекциями.


Эт точно...

VD>3. Замена приведений типов с С-стиля на функциональный стиль. Например, вместо:

VD>
VD>A a = (A)b;
VD>

VD>будет писаться:
VD>
VD>A a = A(b);
VD>


С value-типами это правильное требование, а с ссылочными — никак. Сейчас мы можем написать:
object obj = GetSomeObject;
if(obj is MyType) {
    MyType mt = (MyType)obj;
}


Если написать MyType(obj), то это будет вызов конструктора от obj, что вовсе не требуется.


VD>4. Устранение оператора "as" и введение конструкции "var if" выглядящей следующим образом:

VD>
VD>var if (b = a as B)
VD>{
VD>    b.A_Method();
VD>}
VD>

VD>или
VD>
VD>var if (b = a as B)
VD>    b.A_Method();
VD>


может... лучше дать возможность проверять на null оператору if?

и писать хоть с var хоть с явным указанием типа:
if(B b = a as B) ...

В C++ такое допустимо можно.

VD>Как развитие оператора можно добавить к нему конструкцию "else":



Cледуя констентности его НУЖНО туда добавить, так же как и в while() и в середину оператора for(...; сюда; ...);

VD>5. Ввести у объектов идентификатор типа чтобы были возможно использовать их в switch:


Он есть у них! И мы даже можем его получить, это значение типа Guid. Прав на все 100%. В compile-time он должен быть доступен как константа. Правда, в твоем виде эта константа как бы неопределена на момент компиляции, поэтому я бы сделал еще один оператор, типа: typeid(A).

VD>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".


И все-таки, я бы оставил для аргументов switch только константные значения. Правда, расширил бы их на ссылочные типы, но проверял бы именно на ReferenceEqual. Как-то привыклось думать, что switch — эффективный механизм.

VD>7. Позволить описывать анонимные типы и повзолить автоматическое приведение между анонимными типами содержащими одинаковый набор полей, а так же между обычными типами и анонимными типами если они обладают одинаковой структурой.


Хм... с первым понятно, со вторыми — не так уж и понятно. Для value-типов такие игры будут безопасны, а с сылочными — не уверен. Ну толку, что я привел экземпляр ссылочного типа к другому. Экземпляр остался тот же... У него что, методы от другого типа появится должны, или самореализоваться некоторые интерфейсы, которые могут быть реализованы в том другом типе?

VD>8. Добавление реализации (миксины, трэтсы).

VD>
VD>class Test<T> : T
VD>


Ты же был против подобных вещей?
Разумеется, этой возможности ой как не хватало с самого начала.

VD>9. Добавить возможность давать кострэйны на делегаты и статические методы/свойства.


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

Например, у нас иерархия бизнес-объектов. Каждый тип бизнес-объектов должен иметь некий именно свой дескриптор (через который мы делаем CRUD и пр. операции над бизнес-сущностью данного типа). Мы можем захотеть использовать именно этот дескриптор в обощенных алгоритмах. Однако, нам необходимо гарантировать, что у каждого типа бизнес-объекта есть именно свой статический член-дескриптор, а не унаследованный.


VD>10. Ввести в язык некие синтаксические макросы позволяющие заниматься метапрограммированием и переписать весь синтаксический сахар них. Так из языка должны уйти: foreach, итераторы, switch для строк (да и новый switch для объектов), using () и т.п. Вместо этого должна появиться стандартная мета-библиотека в которой должны присутствовать реализации для всех вышеперечисленных сладостей. Определение мета-макросов дожно быть максимально декларативным чтобы допускать рефакторинг кода созданного на их основе.


VD>metamacro "using" CodeEmitFunc
VD>{
VD>    "using" "(" LocalVarDecl ")"
VD>        Block
VD>}

Хе, начитались OCalm и Hascel?

Хорошая штука там у них насчет этого. Только вот у C# в этом плане оооочень большая проблема, а именно — неопределенность порядка компиляции проекта. Т.е. прямо в самой программе написать ее расширения — трудно.

Т.е. эту фичу я бы сделал не синтаксическим моментом, а через некие интерфейсы расширения компилятора(!!!). Аналогично тому как можешь подавать InstanceDecriptor в TypeConvertor и пр. Т.е. дать возможность работать с AST компилятора...

И тогда подобные расширения синтаксиса можно будет делать не обязательно декларативно, а императивно. И целевые сборки-расширители надо подключать к компилятору с помощью ключей компиляции...

Блииин, да это такую мощную фигню можно сделать. Я бы поучаствовал в подобном проекте разработки компилятора, в котором можно подключать внешние обработчики/трансформаторы AST.

Вот было бы поле для деятельности

А насчет декларативности... Дык, можно было бы написать некий расширитель, который как раз предоставлял такой синтаксис для декларативного описания других расширителей.


А возвращаясь к теме функциональных, это да, надо брать из их наработок максимум (желательно с синтаксисом, не противоречащим остальному) типа:
var a : b = FuncReturn2();

int : double FuncReturn2() {
    return 10 : 10.0;
}
Re[4]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 13.12.05 16:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>и кривизна при парсинге.


кстати, про кривизну при парсинге — кого-то мне это напоминает
начинается на "В", кончается на "ирт"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[2]: Чего не хватает в C#?
От: Gaperton http://gaperton.livejournal.com
Дата: 14.12.05 19:14
Оценка:
Здравствуйте, ie, Вы писали:

ie>Здравствуйте, Кирилл Осенков, Вы писали:


ie>Еще хотелось бы что-то вроде:


ie>
ie>if (num in [1, 2, 3])
ie>{
ie>    ...
ie>}
ie>if (obj in<MyObjComparer> [obj1, obj2, obj3])
ie>{
ie>    ...
ie>}
ie>


Как то скромненько. Хотеть, так уж так хотеть как следует, чтоб не вредно было:

if( num in fib = 1:1:[ a+b | (a,b) in zip(fib, tail(fib)) ] )
{
...
}


Короче, закрый один глаз и загадай желание
Re[10]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.05 19:20
Оценка:
Здравствуйте, IT, Вы писали:

IT>Это я тебе привёл очень маленький пример, я бы даже сказал совсем масенький. Как только начинаешь пользоваться атрибутами по максимуму, то возникает проблема замусоривания ими всего кода.


И все же, что будет кгда атрибуты будут зависеть от местоположения членов класса в файле? Не вызовет ли это еще большех проблем?

Мне кажется тут нужно придумывать некий днугой выход. Например вводить атрибуты которые при применении к чему-либо разварачивались бы в набор других атрибутов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.05 19:20
Оценка:
Здравствуйте, Дарней, Вы писали:

VD>>Зачем? Проблема (A)b в том, что это ужасный синтаксис и кривизна при парсинге.


Д>проблема в том, что это абсолютно разные операции. Одна из них требует проверки RTTI в рантайме, другая нет.


И какая разница? Да и про проверки — это твои предположения. Компилятор во многих случаях может вае и без проверок в рантайме сделать.

Д> И смысл у них совершенно разный.


Смысл у них совершенно идентичный — приведение типов.

VD>>
VD>>((C)((A)b).Prop1).Prop2
VD>>// или
VD>>C(A(b).Prop1).Prop2
VD>>


Д>Этот синтаксис еще хуже, потому что с одного взгляда нельзя отличить приведение типов от вызова функции.


И это прекрасно! А чем собственно отличается любая другая функци преобразующая один тип в другой?

Д> Лучше уж тогда писать что-то вроде cast<type>(A). Заодно и отобьет желание приводить типы без необходимости.


Это куча совершенно лишнего текста. А отбивать желание лучше путем насаждения знаний.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 14.12.05 20:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>Ok, согласен. Да, компилятор C++ точно так же говорит мне при попытке создать экземпляр абстрактного класса, что его нет. Я не помню проблем с этим. Действительно, если метода нет, то надо сделать так, чтобы он был

V>>А где сделать — решать тебе. И в чем толк повторения этих методов в абстрактном классе. Если я добавлю еще один метод в абстрактный класс для требований реализации изменений интерфейса, как ты привел пример, то мне точно так же компилятор даст по рукам во всех наследниках. Т.е. в чем бенефиты?

S>В том, что ты это делаешь намеренно. Ты ведь не обязан делать его абстрактным — может, тебе будет вполне достаточно


Ok, в этом моменте все-равно нет истины есть лишь предпочтения. Скажу лишь, что я отталкиваюсь от той мысли, что если я ИСПОЛЬЗУЮ некие интерфейсы, то они обычно достаточно сильно фиксированы, т.е. я не ожидаю изменений интерфейсов. Если же я РАЗРАБАТЫВАЮ интерфейсы и классы, их реализующие, то мне тем более все-равно, потому как делая собственные изменения в интерфейсах я заведомо знаю, что мне прямо сейчас придется доделать все классы, которые реализуют этот интерфейс.

S>>>Все консистентно. Неясно, зачем тебе декларировать абстрактные методы в базовом классе, если тебе так хочется использовать невиртуальные методы в его потомках.

V>>Компилятор требует.
S>Компилятор ничего не требует. Хочешь делать невиртуальную реализацию метода интерфейса — делай.
V>>Дык, посмотри в код. Пяток методов для реализации коллекции с 0-ля я уже сэкономил.
S>Где? Они ж абстрактные! Т.е. ты обязан перекрыть их в классах-наследниках! Ничего ты не сэкономил — наследников точно так же можно наследовать и от object. Сдается мне, что ты не совсем верно применяешь связку абстрактный класс/интерфейс.
S>Вот что я имею в виду:

[скипнул код]

ВСЕ!!! ПОНЯЛ ЧТО ТЫ ИМЕЛ В ВИДУ!!! (дважды не мог врубиться о чем ты, применительно к моему случаю)

Ты просто забыл с чего я начал свою подветку

Сказать по правде, увидев твой код я обалдел, от выделенного:
public abstract class CollectionPreBase<T> // : object 
    ...
    IEnumerator IEnumerable.GetEnumerator() {
            return GetEnumerator();
    }
}


и побежал проверять на компиляторе, но увы, чудес не бывает:

error CS0540: 'Widgets.CollectionPreBase<T>.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable'


(а про подобное применение интерфейсов я и сам когда-то кому-то разъяснял здесь на форуме .Net 1-2 года назад, найти ту мессагу нереально)


S>Как видишь, а) никаких лишних абстрактных методов б) никакой насильственной виртуальности в) ничего лишнего в конкретных классах-потомках.


Да вижу, вижу
Re[9]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 14.12.05 21:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я про то, что (ко/контр)вариантность для вэлью-типов не проходит. Хотя иногда кажется логичным, что метод:

VD>
VD>long F();
VD>

VD>совместим с методом
VD>
VD>int F();
VD>

VD>так как int приводится к long.

Такое я бы не допускал, у нас же value-типы не наследуются. И наличие оператора преобразования тут не при чем.

Я говорю о ситуации, когда у нас так:
// в интерфейсе
IComparable F();

// в реализации
int F();

для таких случаев можно генерить thunk прямо в runtime при загрузке класса одновременно с таблицей метдов.


VD>А где ты увидил виртуальный метод? Фигово ты читал ликбез.

VD>Нет тут ничего виртуального. Вот если бы ты привел бы this к ссылке на интерфейс, то о виртальности можно было бы поговорить.

Фигово ты помнишь о чем речь. this у меня уже абстрактный.
Напоминаю, в базовом абстрактном классе я делаю так:
IEnumerator IEnumerable.GetEnumerator() {
    return GetEnumerator();
}



VD>"IEnumerator<int> GetEnumerator()" не является винтуальным методом. В дотнете реализация интерфейса и виртуальность метода не одно и то же.


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



VD>И будет ли он заинлайнен или нет определяется исключительно эвристиками джита, а не виртуальностью. Кстати, потенциально и с виртуальностью можно бороться.


Ты это уже говорил, но пока верится туго. Понимаешь, слишком многофакторная задача — оценить возможность наличия наследников с переопределенными виртуальными методыми... Ведь наследников могут и опосля грузануть в домен, а базовый-то уже загружен и вызов виртуального метода кое-где заинлайнен... Как быть, если мы подадим туда экземпляр свежезагруженного наследника?

V>>Если у нас енумератор от IEnumerator<T> и мы его сделли без yield return, в его с-ве T Current{get;} тот же момент.


VD>Ничго не понял.


IEnumerator<T> аналогичным образом наследует IEnumerator.

V>>У них там недавно очередной релиз был. Состав их PoserCollections маловат, но это от того, что в "основном" составе хватает функциональности. Это как бы дописывание того, что не вошло во фреймворк (а могло бы, там совсем немного)


VD>Согласен. Но похоже, что она и не вошла по причине экзотичности. То есть, кожется, что там куча всего нужного, а на практике что-то применять это все дело не приходится.


V>>Ты думаешь что с STL/boost сложнее?


VD>Ну, реализуй КОМ-овскую коллекцию на нем. Да и просто коллекцию то будет сложно. Нужны события и т.п. А уж с КОМ-овской за всегда трху на порядок больше.


Если ты про SafeArray, то вот ATL::SafeArray<T>, если тебе для внутренних нужд, то вот: std::vector< _comptr_t<T> >

А вообще-то можно IEnumVariant и прочие IEnumXXX, есть полно их шаблонных исполнений, это — самое то в духе COM.


V>>не смешно, это как в другой ветке где ты пытался предположить, что я не знаю о существовании unsafe у компилятора C#. Я имел ввиду механику вызова, т.е. затраты на вызов метода объекта через интерфейс. Они не зависят от виртуальности целевого метода.


VD>Очень даже зависят. Ты все же повнимательнее погляди примерчик то. Там как раз показана разница в вызове виртуального члена класса через интерфейс и не виртуального.


русским по-белому, если НАС КТО-ТО ВЫЗЫВАЕТ ЧЕРЕЗ ИНТЕРФЕЙС (ведь это МЫ реализовали интерфейс, для того, чтобы нас дергали за него), то механика вызова метода ЧЕРЕЗ ИНТЕРФЕЙС не зависит от способа реализации этого метода в нашем классе, т.е. от его виртуальности.

Ты мне доказываешь совсем другую вещь, типа что компилятор генерит разный байт-код для вызова метода напрямую или же через интерфейс. Блин, в голову не придет спорить с этим.


V>>И спрашивал, зачем мне объявлять эти абстрактные методы?


VD>А зачем ты их в С++ объявляешь? Ты просто не можешь понять, что в дотнете виртуальность методов и реализация интфейсов вещи связанные не анпрямую.


Ага, мне Синклер тоже так говорил, да я не мог врубиться — при чем тут в моем случае, вот мой ответ http://www.rsdn.ru/Forum/Message.aspx?mid=1539697&amp;only=1
Автор: vdimas
Дата: 14.12.05


VD>Да, не объявляй. Реализуй интерфейс где нужно и обойдешся без виртуальных методов. Я вообще не вижу смысла в классе не имеющем ни одного реально реализованного метода.


Я тоже, но я там реализовал 4 или 5 методов в базовом классе коллекций, именно для того, чтобы не реализовывать их в наследниках. Все остальные методы мне пришлось объявить как abstract

VD>Если ты хочешь создать базовый класс который реализовал бы некоторые методы, то можешь просто создать класс не реализующий интерфейс но определяющй часть методов. А дальше отнаследуйся от этого класса и реализуй интерфейс. Методы из базового класса автоматом воспримутся как реализация методов интерфейса.


Блин, ну спасибо огромное за информацию. Когда-то я уже говорил тебе, что с тобой трудно разговаривать из-за того, что ты легко себе предполагаешь, будто собеседник нихрена не понимает. Предположил бы лучше, что прекрасно понимает и задает вопросы по делу. По приведенной ссылке выше сходил?


V>>Кому как. Приведенный случай обощается не только на один этот метод в интерфейсах коллекций. У кого-то может быть развитая система типов и эта контрвариантность могла бы сэкономить ненужные строки кода


VD>Может быть, может быть. Вот только я как-то ни разу не наталкивался на столь острую необходимость. А в редких случаях переходник спасают.


Ты нет, а я неоднократно в форумах отвечал на подобные вопросы, типа:

у меня есть некий базовый класс, в нем метод:
public virtual BaseObject Value { get; }
Я хочу, чтобы в моем наследнике был такой же Value но уже типизированный.


Я всем предлагал следующее решение:

в базовом:
public BaseObject Value { get { return ValueCore; } }
protected virtual BaseObject ValueCore { get; }


в наследнике:
public new DerivedObject Value { get { blah-blah-blah }}
protected override BaseObject ValueCore { get { return Value; } }


Конкретно в моей ORM-системе, есть базовый EntityManager. Его можно получить для любого типа. Если не зарегистрирован некий кастомный, то мы получаем общий-базовый. Я хочу, чтобы сигнатуры базового и кастомного совпадали — есть очень много очевидных причин для этого, но кастомный был бы при этом типизирован.


Правда, все это я могу теперь сделать с помощью типизированного generic-базового класса для кастомных наследников, в котором пропишу все эти методы-переходники. Вот тебе тот самый пример, где я буду писать переходники, т.е. мне фича контрвариантности реально нужна.
Re[6]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 15.12.05 02:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И какая разница? Да и про проверки — это твои предположения. Компилятор во многих случаях может вае и без проверок в рантайме сделать.


и каким интересно образом он приведет от Object к Control без проверки?

VD>Смысл у них совершенно идентичный — приведение типов.


приведение типов тоже разное бывает

VD>И это прекрасно! А чем собственно отличается любая другая функци преобразующая один тип в другой?


тем, что функция — это вызов куска кода, который находится в твоей проге или одной из библиотек. Ты можешь кликнуть на имя фукнкции и перейти в ее тело, чтобы посмотреть, что там происходит. Куда ты будешь переходить, если это окажется не функция, а оператор приведения типов?

VD>Это куча совершенно лишнего текста. А отбивать желание лучше путем насаждения знаний.


зато никаких проблем при парсинге , и легко находится с помощью банального Ctrl+Shift+F
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[7]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.12.05 04:19
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>тем, что функция — это вызов куска кода, который находится в твоей проге или одной из библиотек. Ты можешь кликнуть на имя фукнкции и перейти в ее тело, чтобы посмотреть, что там происходит. Куда ты будешь переходить, если это окажется не функция, а оператор приведения типов?

Туда же, куда перехожу по клику на typeof(int). А что?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 15.12.05 05:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Туда же, куда перехожу по клику на typeof(int). А что?


значит, на определение результирующего типа. ясно. а зачем делать эту операцию похожей на вызов функции?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.12.05 06:23
Оценка:
Здравствуйте, Дарней, Вы писали:
Д>значит, на определение результирующего типа. ясно. а зачем делать эту операцию похожей на вызов функции?
Там выше по ветке уже приведены аргументы. Давайте по кругу ходить не будем?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 15.12.05 07:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Там выше по ветке уже приведены аргументы.


ни одного внятного аргумента, зачем нужно делать приведение типов похожим на вызов функции, я не видел
это еще имело некоторый смысл в C++, где широко применялись кастомные операторы конверсии типов. Но зачем делать кальку с решений, потерявших свою актуальность, я не знаю
то же самое касается и других решений, которые часто слепо копируют из C++, не разбираясь в их смысле — наподобие форматирования имен членов перечисления и констант в ВЕРХНЕМ_РЕГИСТРЕ, или применения венгерской нотации в 2005 году
надо все-таки думать, почему когда-то было принято то или иное решение, а не руководствоваться принципом "здесь так принято", как шимпанзе в известном эксперименте

S>Давайте по кругу ходить не будем?


давайте
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[11]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.12.05 09:42
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>ни одного внятного аргумента, зачем нужно делать приведение типов похожим на вызов функции, я не видел

Ужасный синтаксис и кривизна при парсинге

Д>это еще имело некоторый смысл в C++, где широко применялись кастомные операторы конверсии типов.
Гм. Вообще-то в C# тоже есть кастомные операторы конверсии типов.
Д>Но зачем делать кальку с решений, потерявших свою актуальность, я не знаю
Почему они вдруг потеряли свою актуальность?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 15.12.05 10:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>[q]Ужасный синтаксис и кривизна при парсинге


если ты отмотаешь выше, то увидишь, что эти слова относились к текущему синтаксису приведения типов — с чем я вполне согласен
но приведение типов в функциональном стиле с точки зрения парсинга все равно ничуть не лучше

S>Гм. Вообще-то в C# тоже есть кастомные операторы конверсии типов.


я знаю.

S>Почему они вдруг потеряли свою актуальность?


А когда ты видел в программе хотя бы один, в последний раз?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[16]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.12.05 03:52
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>Отлично, смущает одна деталь — статически не указано, что класс-наследник обязан так же реализовать IEnumerable<T>

Да, есть такая неприятность. Надо еще подумать — нет ли более красивого варианта.
Я тут уже поразвлекался со всякими комбинациями дженериков, типа MyClass: BaseGeneric<MyClass>, ICloneable<MyClass>
V>Че-то я никак не приучу себя думать терминами даункастинга и кастинга "вбок", то бишь приведение к интерфейсам
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 06:46
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>значит, на определение результирующего типа. ясно. а зачем делать эту операцию похожей на вызов функции?


А какая разница между вызовом функции и явным вызовом оператора приведения типа?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 06:46
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>и каким интересно образом он приведет от Object к Control без проверки?


Про анализ потоков данных слышал? У джита есть все возможности для этого.

VD>>И это прекрасно! А чем собственно отличается любая другая функци преобразующая один тип в другой?


Д>тем, что функция — это вызов куска кода, который находится в твоей проге или одной из библиотек. Ты можешь кликнуть на имя фукнкции и перейти в ее тело, чтобы посмотреть, что там происходит. Куда ты будешь переходить, если это окажется не функция, а оператор приведения типов?


А куда ты перейдешь, если код функции тебе не доступен? Это вообще не серьезный разговор. Найди, например, ради хохмы, код для функции Array.Copy() или Math.Sin(). Если найдешь что-то кроме-двух одной ассемблерной инструкции я лично сниму шляму.

VD>>Это куча совершенно лишнего текста. А отбивать желание лучше путем насаждения знаний.


Д>зато никаких проблем при парсинге , и легко находится с помощью банального Ctrl+Shift+F


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

Вот тебе примерчик для домашнего изучения. Почему вот этот код:
int a = (int)- - -1;

без вопросов компилируется. А вот этот:
int a = (System.Int32)- - -1;

нет?

Погляди на второе сообщение об ошибке при компиляции. Может наведет на мысль.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 06:46
Оценка:
Здравствуйте, Дарней, Вы писали:

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


S>>[q]Ужасный синтаксис и кривизна при парсинге


Д>если ты отмотаешь выше, то увидишь, что эти слова относились к текущему синтаксису приведения типов — с чем я вполне согласен

Д>но приведение типов в функциональном стиле с точки зрения парсинга все равно ничуть не лучше

Так назови хоть один довод против функционального стиля. Ну, кроме похожести на функцию. А то ведь typeof() тоже на функцию похож, хотя это оператор, но тебя это что-то не смущает.

S>>Гм. Вообще-то в C# тоже есть кастомные операторы конверсии типов.


Д>я знаю.


И?

S>>Почему они вдруг потеряли свою актуальность?


Д>А когда ты видел в программе хотя бы один, в последний раз?


Я постоянно вижу. А если их не использовать, то они и в С++ проблем не создадут.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 06:46
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Т.е. речь идет об aliasing типов, я правильно понял? Все делегаты определенной сигнатуры должны быть совместимы м/у собой и с определенным неким автовыводимым типом. Не нарушая стройность системы типов, т.е. учитывая, что тип делегата — это такой же тип как все остальные типы, этой фичей (алиасингом) должна обладать сама система типов.


Нет. Речь идет о введнии функционального типа. К нему должны приводиться любая функция и любой делегат, если конечно они совпадают по сигнатуре. Но делегаты между собой приводиться не должны.

V>Да, иногда хочется завести ДРУГОЙ тип без наследования (и переопределения конструкторов и т.д.). Не как using или typedef в С++, а именно другой тип. Хотя, ключевое слово typedef мне нравится.


Это другое. Хотя глобальные алиасы и глобальные строгие typedef-ы тоже пригодились бы. Те же IntPtr обернуть и сократить длинные имена.

VD>>2. (Ко/контр)вариантность где только это можно. То есть для всего что работает со ссылочными типами начиная от методов, свойств индексеров и кончая интерфейсами и колекциями.


V>Эт точно...


Кстати, С++ вроде не поддерживает контр-вариантности. И не поддерживает ковариантности для параметров. А это тоже полезно.

V>С value-типами это правильное требование, а с ссылочными — никак. Сейчас мы можем написать:

V>
V>object obj = GetSomeObject;
V>if(obj is MyType) {
V>    MyType mt = (MyType)obj;
V>}
V>


V>Если написать MyType(obj), то это будет вызов конструктора от obj, что вовсе не требуется.


Не понял причем тут вэлью-типы. Они, кстати, на сегодня оператором as не поддерживаются.
Но вызов конструктора точно не будет, так как синтаксис конструктора:
new TypeName(...)

или
new TypeName[...]

то есть всегда начинается с new.

VD>>4. Устранение оператора "as" и введение конструкции "var if" выглядящей следующим образом:

VD>>
VD>>var if (b = a as B)
VD>>{
VD>>    b.A_Method();
VD>>}
VD>>

VD>>или
VD>>
VD>>var if (b = a as B)
VD>>    b.A_Method();
VD>>


V>может... лучше дать возможность проверять на null оператору if?


Зачем же возвращать в язык неприятнешие грабли?

V>и писать хоть с var хоть с явным указанием типа:

V>
V>if(B b = a as B) ... 
V>

V>В C++ такое допустимо можно.

Такое в С++ недопустимо, так как тип нельзя объявлять внутри выражения (expressoin).

А нужно это чтобы избавить мир от любителей использовать оператор as для приведения типов (что ведет к граблям). Ну, и за одно это несколько сократит синтаксис подобного кода.



VD>>Как развитие оператора можно добавить к нему конструкцию "else":

V>

V>Cледуя констентности его НУЖНО туда добавить, так же как и в while() и в середину оператора for(...; сюда; ...);


На счет while и for — не понял.

VD>>5. Ввести у объектов идентификатор типа чтобы были возможно использовать их в switch:


V>Он есть у них! И мы даже можем его получить, это значение типа Guid. Прав на все 100%. В compile-time он должен быть доступен как константа. Правда, в твоем виде эта константа как бы неопределена на момент компиляции, поэтому я бы сделал еще один оператор, типа: typeid(A).


Интересно чем же это typeid(A) будет более определен нежели A.TypeId?

В приципе мне пофигу как это будет сделано. Мне важно, чтобы тип можно было засунуть в switch. Я даже пережил бы если для этих целей испльзовалcz бы имеющиеся тип Type, а для switch-ча применялся бы паттерн Прототип. Ну, что-то типа:
switch (obj.GetType())
{
    case typeof(A): ...
    case typeof(B): ...
}

Реализация банальна. Когда компилятор встречает такой switch, он создает Dictionary<Type, int>. При инициализации метода заполняет словарь прототипами типов и порядковыми номерами. Далее делает банальный переходник и switch на целочисленных константах.

VD>>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".


V>И все-таки, я бы оставил для аргументов switch только константные значения. Правда, расширил бы их на ссылочные типы, но проверял бы именно на ReferenceEqual. Как-то привыклось думать, что switch — эффективный механизм.


Строки проблем не вызвают, хотя их константность явно эмелируется. Принцип я уже описал. Меделенее строк не будет. Они тоже через Hashtable реализованы.

VD>>7. Позволить описывать анонимные типы и повзолить автоматическое приведение между анонимными типами содержащими одинаковый набор полей, а так же между обычными типами и анонимными типами если они обладают одинаковой структурой.


V>Хм... с первым понятно, со вторыми — не так уж и понятно. Для value-типов такие игры будут безопасны, а с сылочными — не уверен.


А какая разница? Кстати, анонимные типы — это как раз ссылочные типы, как не странно.

V> Ну толку, что я привел экземпляр ссылочного типа к другому. Экземпляр остался тот же... У него что, методы от другого типа появится должны, или самореализоваться некоторые интерфейсы, которые могут быть реализованы в том другом типе?


Речь идет о копировании данных. Ну, да это действительно вопрос тонки. Тут можно и детальнее проработать или плюнуть.

VD>>8. Добавление реализации (миксины, трэтсы).

VD>>
VD>>class Test<T> : T
VD>>


V>Ты же был против подобных вещей?


Где? Я против множественного наследования. Но я за миксины. Точнее даже не за миксины, а за Traits.
V>Разумеется, этой возможности ой как не хватало с самого начала.

Ну, я без нее как не странно живу (хотя после многолетнего опыта с АТЛ думал не смогу), но лишней такая возмжность точно не стала бы.

VD>>9. Добавить возможность давать кострэйны на делегаты и статические методы/свойства.


V>С учетом алиасинга первое вполне возможно, второе спорно. Статические методы-св-ва могут быть у целевого типа, а могут быть у его базовых типов. Как задать требование, что некий статический член должен быть именно у целевого типа?


Статические методы точно так же перекрываются.

V>Например, у нас иерархия бизнес-объектов. Каждый тип бизнес-объектов должен иметь некий именно свой дескриптор (через который мы делаем CRUD и пр. операции над бизнес-сущностью данного типа). Мы можем захотеть использовать именно этот дескриптор в обощенных алгоритмах. Однако, нам необходимо гарантировать, что у каждого типа бизнес-объекта есть именно свой статический член-дескриптор, а не унаследованный.


Не понял.


VD>>10. Ввести в язык некие синтаксические макросы позволяющие заниматься метапрограммированием и переписать весь синтаксический сахар них. Так из языка должны уйти: foreach, итераторы, switch для строк (да и новый switch для объектов), using () и т.п. Вместо этого должна появиться стандартная мета-библиотека в которой должны присутствовать реализации для всех вышеперечисленных сладостей. Определение мета-макросов дожно быть максимально декларативным чтобы допускать рефакторинг кода созданного на их основе.


V>
VD>>metamacro "using" CodeEmitFunc
VD>>{
VD>>    "using" "(" LocalVarDecl ")"
VD>>        Block
VD>>}
V>

V>Хе, начитались OCalm и Hascel?

Скорее Лиспа и The Java Syntactic Extender.

V>Хорошая штука там у них насчет этого. Только вот у C# в этом плане оооочень большая проблема, а именно — неопределенность порядка компиляции проекта. Т.е. прямо в самой программе написать ее расширения — трудно.


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

V>Т.е. эту фичу я бы сделал не синтаксическим моментом, а через некие интерфейсы расширения компилятора(!!!). Аналогично тому как можешь подавать InstanceDecriptor в TypeConvertor и пр. Т.е. дать возможность работать с AST компилятора...


V>И тогда подобные расширения синтаксиса можно будет делать не обязательно декларативно, а императивно. И целевые сборки-расширители надо подключать к компилятору с помощью ключей компиляции...


V>Блииин, да это такую мощную фигню можно сделать. Я бы поучаствовал в подобном проекте разработки компилятора, в котором можно подключать внешние обработчики/трансформаторы AST.


V>Вот было бы поле для деятельности


Блин, столько радостных соплей в то время когда R# уже год как все это делать может.
Вэкам в новый мир!

V>А насчет декларативности... Дык, можно было бы написать некий расширитель, который как раз предоставлял такой синтаксис для декларативного описания других расширителей.


Еще раз. Сами по себе эти метамакросы пол дела. Очень важно, чтобы их понимали IDE и разные тулзы вроде рефакторинга. Вот тут то декларативность пригодится как нельзя кстати. Хотя бы на уровне синтаксиса это дело дожно быть декларативным. Ну, а уж на стадии трансформации можно и императивщинку залудить. Хотя опять же тут стиль запросов (вроде SQL) несколько более приемлем.

V>А возвращаясь к теме функциональных, это да, надо брать из их наработок максимум (желательно с синтаксисом, не противоречащим остальному) типа:

V>
V>var a : b = FuncReturn2();

V>int : double FuncReturn2() {
V>    return 10 : 10.0;
V>}
V>


Блин, это и есть анонимные типы. И то что я о них говорил. На сегодня такой пример делается "на ура":
var a = new{ Test=123, Name="Вася" };
Console.WriteLine(a);

выводит:
{Test=123, Name=Вася}

А вот описать анонимный тип, чтобы использовать его как возвращаемое значение функции или свойства нельзя. Тем самым убиваются очень мощьные возможности. Хорошо бы чтобы можно было далать как-то так:
{ int Test; string Name; } MyFunc()
{
    if (xxx)
        return new { Name="Петя" }; // Test == 0
        
    return new { 12345, "Петя" }; // задание полей по порядку
}

ну, или:
var { int Test; string Name; } MyFunc()
{
    if (xxx)
        return new { Name="Петя" }; // Test == 0
        
    return new { 12345, "Петя" }; // задание полей по порядку
}

Множественная инициализация переменных конечно тже была бы полезна.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 07:23
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ты это уже говорил, но пока верится туго.


Это не вопрос веры.

V> Понимаешь, слишком многофакторная задача — оценить возможность наличия наследников с переопределенными виртуальными методыми...


Блин. Не является метод реализующий интерфейс виртуальным. Ну, не является. Виртуальный метод — это метод под который отведен слов в таблице метдов. А метод реализующий метод интерфейса — это всего лишь наличие соотвествующего переходника в интерфейсной карте. Да будет тебе извесно для вызова метода интерфейса донет даже приведения не делает. То есть код вроде:
ITest itf = (ITest)new A();

никакого приведения типов не делает. Оно попросту не нужно. В любом случае при вызове метода бдет обращение к интерфейсномой карте откуда будет вынут адрес реального метода. Потому вызов метода интерфейса в 2-2.5 раза медленее чем виртуального метода.

V> Ведь наследников могут и опосля грузануть в домен, а базовый-то уже загружен и вызов виртуального метода кое-где заинлайнен... Как быть, если мы подадим туда экземпляр свежезагруженного наследника?


Нельзя вызвать метод у наследника обладая ссылка на родителя. Если ссылка на наследника, то все карты проинициализированы и вызов пойдет туда куда надо. Короче, поверь человеку который с этим разбирался.

V>IEnumerator<T> аналогичным образом наследует IEnumerator.


Он не наследует, он унаследован от IEnumerator. И что?

V>Если ты про SafeArray, то вот ATL::SafeArray<T>, если тебе для внутренних нужд, то вот: std::vector< _comptr_t<T> >


Нет я про КОМ-коллекцию. К тому же ATL::SafeArray — это очень убогая вещь.

V>А вообще-то можно IEnumVariant и прочие IEnumXXX, есть полно их шаблонных исполнений, это — самое то в духе COM.


Реализация IEnumVariant это часть реализации коллекции.

VD>>Очень даже зависят. Ты все же повнимательнее погляди примерчик то. Там как раз показана разница в вызове виртуального члена класса через интерфейс и не виртуального.


V>русским по-белому, если НАС КТО-ТО ВЫЗЫВАЕТ ЧЕРЕЗ ИНТЕРФЕЙС (ведь это МЫ реализовали интерфейс, для того, чтобы нас дергали за него), то механика вызова метода ЧЕРЕЗ ИНТЕРФЕЙС не зависит от способа реализации этого метода в нашем классе, т.е. от его виртуальности.


В коде переходника ты не через интерфейс делашь вызов, а напрямую.

V>Ты мне доказываешь совсем другую вещь, типа что компилятор генерит разный байт-код для вызова метода напрямую или же через интерфейс. Блин, в голову не придет спорить с этим.


А что же ты боишся за то что метод не будет заинлайнен?
В общем, с чем спориш то?

V>Ага, мне Синклер тоже так говорил, да я не мог врубиться — при чем тут в моем случае, вот мой ответ http://www.rsdn.ru/Forum/Message.aspx?mid=1539697&amp;only=1
Автор: vdimas
Дата: 14.12.05


Ну, кто в этом виноват?

V>Я тоже, но я там реализовал 4 или 5 методов в базовом классе коллекций, именно для того, чтобы не реализовывать их в наследниках. Все остальные методы мне пришлось объявить как abstract


Я тебе уже третий раз говорю. Не реализуй в этом классе интефейс. Реализуй только аналогичные (и только необходимые) методы. Дальше унаследуй от этого класса конкретный класс в котором и реализуй интерфейс. Получишь тот же ээффект, только без абстрактных изысков. Они ведь ненужны.

VD>>Если ты хочешь создать базовый класс который реализовал бы некоторые методы, то можешь просто создать класс не реализующий интерфейс но определяющй часть методов. А дальше отнаследуйся от этого класса и реализуй интерфейс. Методы из базового класса автоматом воспримутся как реализация методов интерфейса.


V>Блин, ну спасибо огромное за информацию. Когда-то я уже говорил тебе, что с тобой трудно разговаривать из-за того, что ты легко себе предполагаешь, будто собеседник нихрена не понимает. Предположил бы лучше, что прекрасно понимает и задает вопросы по делу. По приведенной ссылке выше сходил?


Ты демонстрирушь совершенно бредовый код. Не понимшь что тебе два человека говорят, а потом еще и упрекашь, в том что тебе банальности говорят. Здорово.

V>Правда, все это я могу теперь сделать с помощью типизированного generic-базового класса для кастомных наследников, в котором пропишу все эти методы-переходники. Вот тебе тот самый пример, где я буду писать переходники, т.е. мне фича контрвариантности реально нужна.


Так, тогда о чем речь?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Чего не хватает в C#?
От: Oyster Украина https://github.com/devoyster
Дата: 17.12.05 10:27
Оценка:
Здравствуйте, dimchick, Вы писали:

D>Проект Linq (C# 3.0, VB 10.0) — майбутнє мов програмування


Поздно, конечно, отвечаю, но скорее VB 9.0, а не 10.0.
Re[17]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 18.12.05 08:02
Оценка:
Здравствуйте, Sinclair, Вы писали:


V>>Отлично, смущает одна деталь — статически не указано, что класс-наследник обязан так же реализовать IEnumerable<T>

S>Да, есть такая неприятность. Надо еще подумать — нет ли более красивого варианта.
    public abstract IEnumerator<T> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() {
                    return GetEnumerator();
    }


GetEnumerator по-любому будет в наследнике, поэтому записываем в абстракт.
Re[4]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.12.05 17:05
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Это добавит ещё и возможность сложных расчетов внутри get/set, чтоб завел свои переменные и паришся с математикой.


А вот этого делать нельзя. Объяснять почему?
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[2]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.12.05 20:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>4. Устранение оператора "as" и введение конструкции "var if" выглядящей следующим образом:

VD>
VD>var if (b = a as B)
VD>{
VD>    b.A_Method();
VD>}
VD>

VD>или
VD>
VD>var if (b = a as B)
VD>    b.A_Method();
VD>


Честно говоря, все равно не понял в чем кайф. На сахарок не тянет, бо слишком многословно.

VD>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".


Так тогда и п.5 автоматом выполняется. Кстати, TypeId и так есть, Type.GUID называется, только он под свитч не прокатывает.
Опять же — какую реализацию делать? Последовательное сравнение? Или как со строками — через хештаблицу?

VD>8. Добавление реализации (миксины, трэтсы).


Идея верная, но вот тот код, что ты привел как то не очень.

VD>11. Декларативные свойства:


VD>[c#]

VD>int Property1 var { get; set; } // свойство со скрытой переменной

А var зачем?
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[14]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 19.12.05 02:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Так назови хоть один довод против функционального стиля. Ну, кроме похожести на функцию.


а что, понятность кода — этого уже недостаточно?
а ты назови хоть один довод против записи с явным указанием ключевого слова cast

VD>А то ведь typeof() тоже на функцию похож, хотя это оператор, но тебя это что-то не смущает.


не смущает, потому что typeof — это ключевое слово, которое имеется в языке в количестве 1 (одна) штука.

VD>Я постоянно вижу.


интересно, в каком коде и зачем они там нужны?

VD>А если их не использовать, то они и в С++ проблем не создадут.


... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[10]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 19.12.05 02:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А какая разница между вызовом функции и явным вызовом оператора приведения типа?


если это кастомный оператор, то практически никакой. Но кастомные операторы конверсии типов в C# составляют хорошо если 1% от общего количества применения операторов приведения типов
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[8]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 19.12.05 02:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Про анализ потоков данных слышал? У джита есть все возможности для этого.


это просто оптимизация, и срабатывает далеко не всегда
object[] tmp = { -1, "a", null, 5.6 };
как обходиться без проверок будем?

VD>А куда ты перейдешь, если код функции тебе не доступен? Это вообще не серьезный разговор. Найди, например, ради хохмы, код для функции Array.Copy() или Math.Sin(). Если найдешь что-то кроме-двух одной ассемблерной инструкции я лично сниму шляму.


попробуй нажать "go to definition" в VS2005.
А шляпа у тебя есть?

VD>Преятно поговорить с разбирающися парсинге человеком. Я, как бы, занимался парсингом этого дела и скажу тебе, что это грязнеший хак.


только издеваться не надо
а почему хак?

VD>Вот тебе примерчик для домашнего изучения. Почему вот этот код:

VD>
VD>int a = (int)- - -1;
VD>

VD>без вопросов компилируется. А вот этот:
VD>
VD>int a = (System.Int32)- - -1;
VD>

VD>нет?

Error 1 To cast a negative value, you must enclose the value in parentheses D:\projects\temp\ConsoleApplication2\ConsoleApplication2\Program.cs 52 12 ConsoleApplication2
Error 2 'int' is a 'type', which is not valid in the given context D:\projects\temp\ConsoleApplication2\ConsoleApplication2\Program.cs 52 20 ConsoleApplication2

Не наводит Первое, кстати, намного интереснее. Почему к встроенному типу можно приводить без скобок, а к его реальному имени нельзя?
По хорошему, стоит вообще запретить ставить унарный минус перед составными выражениями без явного заключения их в скобки. Ибо нефиг.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[5]: Чего не хватает в C#?
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 19.12.05 06:47
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А вот этого делать нельзя. Объяснять почему?


Да.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Вселенная бесконечна как вширь, так и вглубь.
Re[6]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.05 09:08
Оценка:
Здравствуйте, Real 3L0, Вы писали:

AVK>>А вот этого делать нельзя. Объяснять почему?


R3>Да.


Typically, users will not understand the negative performance implications of calling a property. To fix, make the property a method.

... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re: Чего не хватает в C#?
От: dotter  
Дата: 19.12.05 09:14
Оценка:
Иногда, когда отлаживаешся, нужно отключить блок try — catch, чтобы программа вывалилась на ошибку в правильном месте.


try
{
  // Some Code
} 
catch
{
  // Some handling
}

Обычно это делается так 

#if !DEBUG
try
{
#endif
// Some Code
#if !DEBUG
} 
catch
{
  // Some handling
}
#endif

а хотелось бы поставить что-то вроде:

debugged try
{
  // Some Code
} 
catch
{
  // Some handling
}


После чего try-catch отключается. Соответстветнно, при сборке в release это должно приводить к ошибке компиляции.
Re[2]: Чего не хватает в C#?
От: Mab Россия http://shade.msu.ru/~mab
Дата: 19.12.05 09:18
Оценка:
Здравствуйте, dotter, Вы писали:

D>Иногда, когда отлаживаешся, нужно отключить блок try — catch, чтобы программа вывалилась на ошибку в правильном месте.

В каком смысле -- в правильном месте?
Re[7]: Чего не хватает в C#?
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 19.12.05 11:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>

Typically, users will not understand the negative performance implications of calling a property. To fix, make the property a method.


Мой транслэйт, для таких как я :

Обычно пользователи не понимают снижения производительности при использования свойств. Для решения этой проблемы используйте свойства в виде методов.

Правильно перевёл?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Вселенная бесконечна как вширь, так и вглубь.
Re[5]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 19.12.05 11:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Плохо. Дело в том, что практическая ценность события, на которое можно только подписаться или только отписаться не очень ясна. А вот свойства только с get встречаются едва ли не чаще, чем свойства с get/set. Так что get/set нужно указывать даже в минимальном варианте.


Я если честно не понял. Какие события? Можешь поподробнее?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[7]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 19.12.05 12:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Антон указал на то, что автоматическое создание полей в компиляторе C# уже есьть, а именно в случае событий поле делегата явно можно не указывать, компилятор сгенерирует его самостоятельно. И предложил аналогичный синтаксис для свойств. На что я заметил, что в случае свойств, в отличие от событий, крайне важно указать список поддерживаемых операций.

Понятно, спасибо.

Мне всё же нравится синтаксис
public int PropertyName { }

Можно сделать соглашение, что пустые скобки означают наличие обоих аксессоров get и set. Если нужно только get, или только set, нужно указывать явно. Или, если нравится, можно явно указать оба, почему бы нет.

Получается вполне однозначно, а главное — лаконично.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка:
Здравствуйте, Дарней, Вы писали:

VD>>А какая разница между вызовом функции и явным вызовом оператора приведения типа?


Д>если это кастомный оператор, то практически никакой.


А если нет, то что изменится?

Д>Но кастомные операторы конверсии типов в C# составляют хорошо если 1% от общего количества применения операторов приведения типов


Какая разница каков процент?

ЗЫ

Так есть хоть какие то аргументы против кроме "непривычно"?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


VD>>4. Устранение оператора "as" и введение конструкции "var if" выглядящей следующим образом:

VD>>
VD>>var if (b = a as B)
VD>>{
VD>>    b.A_Method();
VD>>}
VD>>

VD>>или
VD>>
VD>>var if (b = a as B)
VD>>    b.A_Method();
VD>>


AVK>Честно говоря, все равно не понял в чем кайф.


Кайф в том, что эта конструкция просто не даст использовать неверно оператор as и сокращает код позволяя избавиться от отдельной декларации переменной и отдельной проверки. Аналог этого кода:
B b = a as B;

if (b != null)
    b.A_Method();

Как видишь уже коротко. Если взять более сложный вариант:
var if (b = a as B)
    b.A_Method();
else var if (c = a as С)
    c.A_Method();
else 
    throw new MyException(...);

То он будет уже выглядить совсем запутанно:
B b = a as B;

if (b != null)
    b.A_Method();
else
{
    С c = a as С;
    
    if (c != null)
            c.A_Method();
    else 
            throw new MyException(...);
}


AVK> На сахарок не тянет, бо слишком многословно.


Так что как видишь, согращение и упрощение кода не такое уж и меленькое.
Но главное избавление от использования as в качестве опретатора приведения типов (без проверки на null).


VD>>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".


AVK>Так тогда и п.5 автоматом выполняется.


Не выполняется. Это разные вещи. Одно другому не противоречит.

AVK> Кстати, TypeId и так есть, Type.GUID называется, только он под свитч не прокатывает.


Он не толко не прокатывает под switch. Он еще не доступен во время компиляции, так что написать нечто вроде:
sace typeof(A).GUIDЖ:

не выйдет. А хотелось бы именно это. Хотя если бы можно было делать свитчь по объектам, то и это было бы не пробелемой.

AVK>Опять же — какую реализацию делать? Последовательное сравнение? Или как со строками — через хештаблицу?


Последовательное сравнение в свтитче никогда не делалось и надеюсь делаться небудет. Если идентификаторы будут целочисленные, то свитчь и так справится. Если это будут объекты, то ясен пестик, нужно делать хэш-таблицу.

VD>>8. Добавление реализации (миксины, трэтсы).


AVK>Идея верная, но вот тот код, что ты привел как то не очень.


Да мне в общем-то пофигу. Продемонстрировал то что вервым в голову пришло. Только я что-то не вижут что плохого в таком варанте?

VD>>11. Декларативные свойства:


VD>>[c#]

VD>>int Property1 var { get; set; } // свойство со скрытой переменной

AVK>А var зачем?


Чтобы отличать это дело от случая когда кто-то забыл влепить ключевое слово abstract. Как бы приказ компилятору породить переменную. Ну, и получается унифицировано со вторым вариантом (в тотором свойство реализует толко get, а переменная доступна). Опять же меня бы устроили и продуманные вариации на тему.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну примерно. Основная идея следующая — обычно, когда свойство используется, подсознательно предполагается, что это операция относительно дешевая, поэтому, если на самом деле она дорогая, то могут быть проблемы с производительностью. Для избежания подобного дорогие алгоритмы рекомендуется оформлять ввиде методов. См. к примеру GetSchemaTable().


Жаль, что понятие "дорогой" слишком уж относительное.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Лучше уж оставить синтаксис абстрактных свойств, но если они не абстрактные, то автоматом генерить реализацию.


Не. Это нрабли. Ошибся и плучин незапланированное поведение. Уж лучше еще одно ключевое слово. Ну, типа var что я предлагал.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:17
Оценка:
Здравствуйте, vdimas, Вы писали:
S>>Да, есть такая неприятность. Надо еще подумать — нет ли более красивого варианта.
V>
V>    public abstract IEnumerator<T> GetEnumerator();
V>    IEnumerator IEnumerable.GetEnumerator() {
V>                    return GetEnumerator();
V>    }
V>


V>GetEnumerator по-любому будет в наследнике, поэтому записываем в абстракт.


А какой смысл ради этого вообще реализовывать IEnumerable.GetEnumerator в бащрвом классе? Что борьба с копипыстом даже ценой усложнения программы?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: Воронков Василий Россия  
Дата: 20.12.05 02:08
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>В МС++ 2.0 уже вроде как реализована. Только пришлось вводить новое ключевое слово.


А что там реализовано? Вроде бы просто свойство с геттером и сеттером генериться при краткой записи, причем нельзя указать нужен ли только геттер или сеттер. Или я что-то просмотрел?
Re[7]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 02:20
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А что там реализовано?


Дык ты вроде сам ниже и описал "что?".

ВВ>Вроде бы просто свойство с геттером и сеттером генериться при краткой записи, причем нельзя указать нужен ли только геттер или сеттер. Или я что-то просмотрел?


Именно так. Но ведь никто не обещал, что МС++ станет лучшим языком всех времен и народов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 20.12.05 03:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А если нет, то что изменится?


сказка про белого бычка, начинам по новой

VD>Так есть хоть какие то аргументы против кроме "непривычно"?


непривычно? это после С++ то непривычно? похоже, месье тонкий шутник
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[10]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 20.12.05 03:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ага. А, что, кто-то говорил о чем-то другом?


я говорил о характере самой операции, а ты зачем-то завел речь об оптимизации
неважно, что в некоторых случаях можно обойтись без использования отражения — потому что в общем случае, такая проверка нужна

VD>И что? Тебе там код кто-то даст? И вообще, ты хорошо понимашь где и как делаются подобные оптимизации? Это же делает джит или пре-джит. Им до до лампочки наличие или отсуствие кода.


а при чем тут вообще джит? читай выше

VD>Найдем. Только она явно не понадобится.


да уж. с такими темпами перевода темы с одного на другое, тебя хрен переспоришь

VD>Потому что для определния приведение это типа или нет используется довольно натянутая эвристика. int, double и т.п. являются встроенными типами и для них всегда делается зключение, что это тип. А вот для других идетификаторов делается предположение. И в случее вроде приведенного мной, это предположение сделано быть не может.


это все хорошо, но какое отношение оно имеет к cast? для него вообще грамматика LL(1) легко строится
хотя конечно интересно. Не думал, что у них парсер настолько черех ж%;у сделан
почему бы не сделать чистый КС-парсер, который будет проверять язык на соответствие некоторому КС-надмножеству языка, а разрешение неоднозначных конструкций сделать вторым этапом, когда уже есть точная информация об имеющихся в наличии типах?
а еще хорошо бы, чтобы парсер умел сам заглядывать вперед и перебирать возможные ветки разбора для неоднозначных мест в грамматике (если уж мечтать, так по полной программе )

VD>Вот, вот. Не лоегично? Но дело обстоит именно так. Всетроенные типы всегда типы (где бы они не упоминались), а вот все остальное еще не факт. И все это из-за попытки оставить С-шное соглашение о примедении типов.


да я его и не защищаю (С-шное соглашение, то есть)
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[16]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 20.12.05 03:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А что кто-то доказал, что функциональный стиль уменьшит понятность? Вот С-шный точно ее уменьшает, так как получается куча лишних скобок и неопледеленность.


обрати внимание — я вообще не проводил сравнение "functional style cast vs C-style cast".

VD>Неуныжное удлиннени кода. Шарп и так этим страдает. Зачем же ухудшать обстановку? Плюс это ровным счетом ничего не меняет, так как без проблем можно создать функцию cast<T>().


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

Д>>не смущает, потому что typeof — это ключевое слово, которое имеется в языке в количестве 1 (одна) штука.


VD>Ну, а partial, yald и многие другие ключевыми словами не являются. Это не смущает?

VD>
VD>int yield = 0;
VD>Console.WriteLine(++yield);
VD>


да. но и со скобками их ведь не пишут

VD>Еще раз повторюсь. Нет никакой разницы между методом преобразующим один тип в другой и оператором. Это все надоуманные догмы связанные с тем что ты привык к С-шному синтаксису. Те кто пишет на языках с функциональным приведением типов не испытывают комплексов по этому поводу.


а откуда ты знаешь, к какому синтаксису я привык?

VD>Что же касается длинных префиксов, то С++ уже хорошо показал, что это не лучший путь. Многие избегают С++-ные привдения именно по причине их излишней длинных.


а вот длинной линейкой, да по рукам им, по рукам!

VD>Везде где есть привдение типов. В общем, как только начинашь проектировать код в понятих типов, то и приведения получаются и операторы.


пример операторов неявной конверсии типов — в студию!
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[2]: Чего не хватает в C#?
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 20.12.05 05:09
Оценка:
VladD2,
VD>4. Устранение оператора "as" и введение конструкции "var if" выглядящей следующим образом:

VD>
VD>var if (b = a as B)
VD>{
VD>    b.A_Method();
VD>}
VD>

VD>или
VD>
VD>var if (b = a as B)
VD>    b.A_Method();
VD>


Как тебе такой вариант:
if (var b = a as B)
    b.A_Method();

(Чуть логичнее, имхо.)
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[10]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.05 05:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Жаль, что понятие "дорогой" слишком уж относительное.


Тут надо прикидывать сценарий использования. Если это свойство используется для чтения из БД критерии простоты одни, если для работы хештаблицы — совсем другие.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[4]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.05 05:35
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Лучше уж оставить синтаксис абстрактных свойств, но если они не абстрактные, то автоматом генерить реализацию.


VD>Не. Это нрабли. Ошибся и плучин незапланированное поведение.


А в чем там можно ошибится? Без модификатора abstract такое прокатит в только интерфейсах, а там просто свойство не прокатывает, а с ним и так все прекрасно видно. Т.е. по факту ключевое слово уже есть, но указывается оно не для кодогенерации, а наоборот, для ее отключения.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[19]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 20.12.05 07:57
Оценка:
Здравствуйте, VladD2, Вы писали:


S>>>Да, есть такая неприятность. Надо еще подумать — нет ли более красивого варианта.

V>>
V>>    public abstract IEnumerator<T> GetEnumerator();
V>>    IEnumerator IEnumerable.GetEnumerator() {
V>>                    return GetEnumerator();
V>>    }
V>>


V>>GetEnumerator по-любому будет в наследнике, поэтому записываем в абстракт.


VD> А какой смысл ради этого вообще реализовывать IEnumerable.GetEnumerator в бащрвом классе? Что борьба с копипыстом даже ценой усложнения программы?


А зачем вообще базовые классы пишут?

Речь с самого начал шла о том, что во всех подобных случаях надо писать 2 метода вместо 1-го из-за отсутствия контрвариантности. И какая разница в какой ситуации — в написании собственных коллекций либо в реализации неких своих IEntityDescriptor, IEntityStorage и т.д.

Ситуации-то аналогичные, вот в чем прикол. Действительно, для некоторых задач именно так удобней в иерархии:
inteface IEnumerable<T> : IEnumrebale


И не только для IEnumerable, для моих внутренних интерфейсов — то же самое. Т.е. рассматривается ситуация совместного существования типизированных и нетипизированных вариантов.

Пора закругляться, ИМХО. Я давно сказал и показал что хотел, см. начало моей подветки. Отсутствие контрвариантности на фоне других улучшений считаю досадным промахом проектировщиков .Net 2.0
Re[13]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 20.12.05 07:58
Оценка:
Здравствуйте, VladD2, Вы писали:

Скипнул пояснения как работают переопределения методов интерфейсов, задолбал ей-богу. Можно я тебе приведу гораздо более короткий и сочный пример, какой привел бы я, если бы пытался объяснить то, что пытаешься объяснить мне ты (хотя никто тебя не просит).

Вот более короткий и достаточный пример для моего случая:
public interface I1 {
    void M1();
}

public class C1 {
    public void M1() {}
}

public class C2 : C1, I1 {} // все! больше ничего не надо.


Тебе не надоело отвечать не на то уже который раз???


VD>Еще раз. Ты много о чем говорил. Контрвариантность для твоих задач ненужна.


Вот вырезка:


Ты нет, а я неоднократно в форумах отвечал на подобные вопросы, типа:

у меня есть некий базовый класс, в нем метод:public virtual BaseObject Value { get; }

Я хочу, чтобы в моем наследнике был такой же Value но уже типизированный.


Я всем предлагал следующее решение:

в базовом:
public BaseObject Value { get { return ValueCore; } }
protected virtual BaseObject ValueCore { get; }



в наследнике:
public new DerivedObject Value { get { blah-blah-blah }}
protected override BaseObject ValueCore { get { return Value; } }



Конкретно в моей ORM-системе, есть базовый EntityManager. Его можно получить для любого типа. Если не зарегистрирован некий кастомный, то мы получаем общий-базовый. Я хочу, чтобы сигнатуры базового и кастомного совпадали — есть очень много очевидных причин для этого, но кастомный был бы при этом типизирован.


VD>Но даже если она нужна, то достаточно сделать перходник.


Так нужна или нет? У меня и так в моей системе на .Net 1.1 по 2-4 переходника на класс, а ентитей — море, на каждый ентити подвязан свой менеджер и на многие из них — некий entity-view, поддерживающий statefull. И это еще я поленился все коллекции ентитей типизированными сделать (коллекции — свои, ленивые, заточенные под ORM и т.д.), иначе бы у меня практически весь мой код из этих переходников и состоял бы. (Даже на метод с той же сигнатурой, но возвращающей как результат типизированную колекцию потребовался бы лишний переходник, вместо простого переопределения в случае с конрвариантностью)

VD>Ты уже пошел обсуждать проблему инлайнинга.


Да нет, я просто сказал что GetEnumerator у меня абстрактный и его вызов — типа лишний уровень коссвенности, т.е. никак не может заинлайинтся (ты мне пишешь, что все это должно инлайниться). Ты мне уже 10-й раз советуешь сделать его не абстрактным, правда все на словах. Вот подветка, где Синклер показал КАК это сделать. Просмотри внимательно и тебе станет понятно, почему именно я "сопротивляюсь": http://www.rsdn.ru/Forum/Message.aspx?mid=1539904&amp;only=1
Автор: Sinclair
Дата: 15.12.05


Там все понятно. И не приводи плиз больше объяснений, как можно перекрывать методы интерфейсов в дотнете. См начало этого поста.

VD>Точнее ты постоянно прыгашь с одной проблемы на другую. Большое ощущение, что ты специально пыташся избежать получения ответа на свои вопросы.


Просто ты потерял нить беседы где-то в середине и уже который раз объясняешь мне не то. В другой подветке уже давно разобрались (по ссылке приведенной выше).

VD>Итак, что ты на данный момент не понимшь?





VD>Где ты ее увидел? Это создание одного метода перходника порождает такую огромную рутину, что от нее нужно избавляться?


Если в приведенном примере всего 1 метод, то это не значит, что им дело ограничивается. Это я ПРИМЕР привел, весьма показательный. Попытайся понять так же мой пример с ORM.
Re[4]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.05 08:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кайф в том, что эта конструкция просто не даст использовать неверно оператор as и сокращает код позволяя избавиться от отдельной декларации переменной и отдельной проверки. Аналог этого кода:

VD>
VD>B b = a as B;

VD>if (b != null)
VD>    b.A_Method();
VD>

VD>Как видишь уже коротко. Если взять более сложный вариант:
VD>
VD>var if (b = a as B)
VD>    b.A_Method();
VD>else var if (c = a as С)
VD>    c.A_Method();
VD>else 
VD>    throw new MyException(...);
VD>

VD>То он будет уже выглядить совсем запутанно:
VD>
VD>B b = a as B;

VD>if (b != null)
VD>    b.A_Method();
VD>else
VD>{
VD>    С c = a as С;
    
VD>    if (c != null)
VD>            c.A_Method();
VD>    else 
VD>            throw new MyException(...);
VD>}
VD>


Все равно в твоем варианте все очень нетривиально и плохо читаемо. Я скорее против такой фичи, нежели за.

AVK>> На сахарок не тянет, бо слишком многословно.


VD>Так что как видишь, согращение и упрощение кода не такое уж и меленькое.


Ерунда. Тем более что as в 90% случаев в моем коде единичный, а там экономии практически нет. Я бы еще понял если бы ты предложил аналог оператора ??.

VD>Но главное избавление от использования as в качестве опретатора приведения типов (без проверки на null).


Только оно какое то странное. Одно то, что нужно аж 2 новых ключевых слова для простейшей вобщем то штуки пугает.

AVK>>Опять же — какую реализацию делать? Последовательное сравнение? Или как со строками — через хештаблицу?


VD>Последовательное сравнение в свтитче никогда не делалось и надеюсь делаться небудет.


В некоторых случаях на больших свитчах компилятор шарпа if использует вперемешку с вычислением, как в обычном свитче.

VD>Если идентификаторы будут целочисленные, то свитчь и так справится.


Ну GUID вобщем то можно назвать целочисленным. Type.GUID, кстати, на этапе компиляции обязательно известен, потому что он протаптывается в сборку в обязательном порядке.

AVK>>Идея верная, но вот тот код, что ты привел как то не очень.


VD>Да мне в общем-то пофигу. Продемонстрировал то что вервым в голову пришло. Только я что-то не вижут что плохого в таком варанте?


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

VD>>>[c#]

VD>>>int Property1 var { get; set; } // свойство со скрытой переменной

AVK>>А var зачем?


VD>Чтобы отличать это дело от случая когда кто-то забыл влепить ключевое слово abstract. Как бы приказ компилятору породить переменную.


ИМХО это уже перебор.

VD> Ну, и получается унифицировано со вторым вариантом (в тотором свойство реализует толко get, а переменная доступна).


Зато неунифицированно с другими синтаксическими конструкциями шарпа.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 12:20
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Жаль, что понятие "дорогой" слишком уж относительное.


AVK>Тут надо прикидывать сценарий использования. Если это свойство используется для чтения из БД критерии простоты одни, если для работы хештаблицы — совсем другие.


Это ты пыташся развернуть мои слова? Я что-то не пойму к чему ты ведешь?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 12:20
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Не. Это нрабли. Ошибся и плучин незапланированное поведение.


AVK>А в чем там можно ошибится?


Забыть вписать abstract.

AVK> Без модификатора abstract такое прокатит в только интерфейсах, а там просто свойство не прокатывает, а с ним и так все прекрасно видно.


Вот вот. И abstract там не допустим. А так получается, что можно ничайно сделать неверное поведение. С этим в Шарпе боролись как могли когда его проектировали. А ты предлагашь снова пойти по плюсовому пути. Через некоторое время будешь объяснять всем, что "нужно внимательнее писать код".

AVK> Т.е. по факту ключевое слово уже есть, но указывается оно не для кодогенерации, а наоборот, для ее отключения.


Какое такое ключевое слово? Если ты про abstract, то но предназначено для других целей. И уж точно нельзя полагаться на его отсуствие как на решение программиста. Это может быть просто забывчиваость. Сейчас если ты напишишь это дело без abstract, то получишь ошибку. А в твоем случае, ты получишь неверное поведение. Это недопустимо.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 12:20
Оценка:
Здравствуйте, vdimas, Вы писали:

VD>> А какой смысл ради этого вообще реализовывать IEnumerable.GetEnumerator в бащрвом классе? Что борьба с копипыстом даже ценой усложнения программы?


V>А зачем вообще базовые классы пишут?


Ну, чтобы реализовать примитивные перходники занимающие 3 строчки. Прикинь, как круто?! Заводишь отдельный файл... в нем класс на 30 строчек, там химичешь... Трахашся с пометкой тонны методов словом abstract... И в итоге экономишь аж... Ну, нихрена в общем не экономишь, но ведь добился повторного использования кода!

V>Речь с самого начал шла о том, что во всех подобных случаях надо писать 2 метода вместо 1-го


Ужас, то каой! Во всех! Ну, ты их видимо только и делашь, что пишешь. Просто такие непроиводительные затраты, что нет слов!

V>Пора закругляться, ИМХО. Я давно сказал и показал что хотел, см. начало моей подветки. Отсутствие контрвариантности на фоне других улучшений считаю досадным промахом проектировщиков .Net 2.0


Ага. Пора. А то ты докопался к проблеме не стоящей и выеденного яйца и развивашь тему. Думаю, она никому кроме тебя все же не интересна. Вопрос ведь давно ясен. Никто не против появления ковариантности в Шарпе. Только вот не надо под это подводить столь "мощьную" идиологическую базу. Смешно ведь.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.05 12:32
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Тут надо прикидывать сценарий использования. Если это свойство используется для чтения из БД критерии простоты одни, если для работы хештаблицы — совсем другие.


VD>Это ты пыташся развернуть мои слова? Я что-то не пойму к чему ты ведешь?


К тому, что в каждом конкретном случае обычно понятно что стоит сделать свойством, а что надо объявлять как метод.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[6]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.05 12:32
Оценка:
Здравствуйте, VladD2, Вы писали:


AVK>> Без модификатора abstract такое прокатит в только интерфейсах, а там просто свойство не прокатывает, а с ним и так все прекрасно видно.


VD>Вот вот. И abstract там не допустим. А так получается, что можно ничайно сделать неверное поведение.


Ну это если совсем уж без башни. Лично я не представляю насколько нужно грязно программировать, чтобы допустить настолько дибильную ошибку, да еще этого и не заметить. Кроме того, в реальных проектах от абстрактного класса обычно наследуются и, если abstract пропустить, компилятор начнет ругаться на override в наследниках.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[2]: Чего не хватает в C#?
От: GlebZ Россия  
Дата: 20.12.05 18:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>1. Введение в язык понятия функциональный тип. Отличия от делегата следующие. Может ссылатьсч только одну функцию/метод. Тип определяется сочетанием списка формальных параметров с типом возвращаемых значений, а не именем (как это происходит с делегатом). Это позволит автоматически приводить любую функцию к такому типу если она подходит по параметрам. Для такого типа должен быть реализовано атоматический вывод типов. Так код вроде:

VD>
VD>var f = (a, b) => a * b;
VD>

VD>должен порождать переменную f тип которой является функциональным типом о котором шла речь.
VD>Понятное дело, что функциональные типы должны быть совместимыми с соответсвтующими делегатами.
+1000. Только вполне достаточно было бы чтобы компилятор мог определить что делегат можно тупо вызвать как указатель на функцию. Для анонимов, в большинстве своем, по моему это можно сделать.

VD>5. Ввести у объектов идентификатор типа чтобы были возможно использовать их в switch:

VD>
VD>switch (someObj.TypeId)
VD>{
VD>    case typeof(A).TypeId: ... break;
VD>    case typeof(C).TypeId: ... break;
VD>    case typeof(D).TypeId: ... break;
VD>    case typeof(E).TypeId: ... break;
VD>}
VD>

Слишком нетривиально и неоднозначно. Учитывая версии различных сборок которые могут подгружаться.
VD>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".
Может тогда уж лучше нормальный pattern matching?
VD>7. Позволить описывать анонимные типы и повзолить автоматическое приведение между анонимными типами содержащими одинаковый набор полей, а так же между обычными типами и анонимными типами если они обладают одинаковой структурой.
+1

VD>10. Ввести в язык некие синтаксические макросы позволяющие заниматься метапрограммированием и переписать весь синтаксический сахар них. Так из языка должны уйти: foreach, итераторы, switch для строк (да и новый switch для объектов), using () и т.п. Вместо этого должна появиться стандартная мета-библиотека в которой должны присутствовать реализации для всех вышеперечисленных сладостей. Определение мета-макросов дожно быть максимально декларативным чтобы допускать рефакторинг кода созданного на их основе.

VD>
VD>metamacro "using" CodeEmitFunc
VD>{
VD>    "using" "(" LocalVarDecl ")"
VD>        Block
VD>}

VD>Stattments CodeEmitFunc(Scope scope)
VD>{
VD>    // Читаем код макроса из scope, генерируем на его основе
VD>  // окончательный код и возвращаем его из метода.
VD>}
VD>

Эээ. У меня есть подозрение что такое может выполняться только на уровне CLR и при компиляции такого в runtime — JIT просто ляжет.

Я бы сюда добавил бы friends на уровне классов. Все таки иногда очень хочется. Только не в сишном варианте.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 21.12.05 07:46
Оценка:
Здравствуйте, VladD2, Вы писали:


V>>А зачем вообще базовые классы пишут?


VD>Ну, чтобы реализовать примитивные перходники занимающие 3 строчки. Прикинь, как круто?! Заводишь отдельный файл... в нем класс на 30 строчек, там химичешь... Трахашся с пометкой тонны методов словом abstract... И в итоге экономишь аж... Ну, нихрена в общем не экономишь, но ведь добился повторного использования кода!


Ты Влад страшно далек от народа, очевидно. Я постоянно наблюдаю ситуации, когда в самописных с 0-ля коллекциях такие методы как CopyTo или Contains не реализованы... А потом они начинают вызываться, и хорошо если там NotImplementedException, а тож зачастую просто — ничего... Я ж базовые классы не для себя лично пишу

V>>Речь с самого начал шла о том, что во всех подобных случаях надо писать 2 метода вместо 1-го


VD>Ужас, то каой! Во всех! Ну, ты их видимо только и делашь, что пишешь. Просто такие непроиводительные затраты, что нет слов!


У меня этих случаев очень много, пол-проекта. Такова специфика. Куча похожих по функциональности бизнес-объектов, над каждым из которых хочется иметь строго типизированное подмножество этой функциональности. Если тебе и сейчас плохо понятно о чем речь, то спроси у своего друга, сколько всего различных бизнес-сущностей в среднем проекте. Ответ тебя удивит.


V>>Пора закругляться, ИМХО. Я давно сказал и показал что хотел, см. начало моей подветки. Отсутствие контрвариантности на фоне других улучшений считаю досадным промахом проектировщиков .Net 2.0


VD>Ага. Пора. А то ты докопался к проблеме не стоящей и выеденного яйца и развивашь тему. Думаю, она никому кроме тебя все же не интересна. Вопрос ведь давно ясен. Никто не против появления ковариантности в Шарпе. Только вот не надо под это подводить столь "мощьную" идиологическую базу. Смешно ведь.


Докапываешься здесь только ты. Я высказываю свое мнение в специально созданном для этого топе. Если ты не в состоянии представить себе технические моменты в тех областях, за которые еще не брался, то лучше промолчать, чем пытаться оценивать проблему в "выеденное яйцо". Помимо полного невладения описываемой областью проявил банальное отсутствие воображения.
Re[13]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.05 09:51
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>К тому, что в каждом конкретном случае обычно понятно что стоит сделать свойством, а что надо объявлять как метод.


Вот я и не пойму к чебы ты это сказал. Я ведь заметил, что:

Жаль, что понятие "дорогой" слишком уж относительное.


То есть, как раз намекнул, на то что критерий дороговизны слишком расплывчатый.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.05 10:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну это если совсем уж без башни. Лично я не представляю насколько нужно грязно программировать, чтобы допустить настолько дибильную ошибку, да еще этого и не заметить. Кроме того, в реальных проектах от абстрактного класса обычно наследуются и, если abstract пропустить, компилятор начнет ругаться на override в наследниках.


Понимаш ли, С++-ники точно так же аргументируют наличие обилия граблей в С++. А Хегельберг со товарищами очень не мало времени потратили на то, чтобы избавить Шарп от граблей. так зачем же привносить новые грабли в этот замечательный язык? Цена вопроса ведь одно небольшое ключевое слово. Лично я не держусь за var и за его расположение. Пусть это будет другое, возможно контекстно зависимое, ключевое слово. Но пусть оно будет. Это убережет от случайностей, а значит сделат код чище и предсказуемее.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.05 10:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Все равно в твоем варианте все очень нетривиально и плохо читаемо. Я скорее против такой фичи, нежели за.


Очень аргументировано. Жаль не ясно, что тут плохо читается.

AVK>Ерунда. Тем более что as в 90% случаев в моем коде единичный, а там экономии практически нет.


Я верю, что ты пользушся as-ом окуратно и редко. Вот только ты не один на этом свете. Примеры использования as-а вместо приведения типов встречаются постоянно. Эта конструкция в сочетании с запретом открытого использования as-а полностью устранит проблему. Собственно идея не новая. Она повзаимствована из всеми нами любимого Оберона.

AVK>Я бы еще понял если бы ты предложил аналог оператора ??.


Он тут ни каким боком не подходит. Тут именн, что нужно защита от использования типа не по назначению. Сочетание if-а, декларации переменной и as-а. Собственно сам синтаксис можно обсуждать, но принцип как бы даже обсуждать нечего.

VD>>Но главное избавление от использования as в качестве опретатора приведения типов (без проверки на null).


AVK>Только оно какое то странное.


Вот тут могу воспользоваться твоими словами "просто ты не привык".

AVK>Одно то, что нужно аж 2 новых ключевых слова для простейшей вобщем то штуки пугает.


Где ты хоть одно новое ключевое слово увидел? if был и раньше, as тоже. var — ключевое слово вводимое в Линке. О том, что мои предложения базируются именно на Линке я сказал в самом начале. Так что ни одного ключевого слова. А var я и в других местах использовал.

AVK>В некоторых случаях на больших свитчах компилятор шарпа if использует вперемешку с вычислением, как в обычном свитче.


Пример, таких случаев, плиз.

Компилятор шарпа вообще не делает тут ничего умного. Он выделяет диапазоны идущие рядом и делает для каждого из них вызов МСИЛ-овского свитча. В реальном коде это все превращается в очень эффективне структры. Создать что-то эффективнее свитсча практически не возможно.

VD>>Если идентификаторы будут целочисленные, то свитчь и так справится.


AVK>Ну GUID вобщем то можно назвать целочисленным. Type.GUID, кстати, на этапе компиляции обязательно известен, потому что он протаптывается в сборку в обязательном порядке.


Я задолбался повторять.
1. GUID невозмжожно использовать в свитче на сегодны. В конце концов GUID — это структора, что означает, что это а) он ен межет быть константой, б) он больше самого большого встроенног типа данных (long).
2. GUID типа нельзя получить во время компиялции, так что даже если изменить C# так чтобы он поддерживал GUID-ы в свитчах, то все равно ими нельзя будет проинициализировать case-ы.

Так что все твои слова теория не имеющая ничего общего с практикой. А то о чем я говорю нужно именно на практике.

AVK>Как минимум то, что наследование от параметра дженерика невозможно принципиально.


Это не так. Запрет на наслодование от параметра — волевое решение. Кто-то из команды CLR говорил, что в будущем они возможно разрешат это чтобы сделать миксины. Именно по этому я и выбрал такой вариант. Хотя как это будет конкретно мне по фигу. Главное, чтобы не сложнее того что получилось у меня.

VD>>Чтобы отличать это дело от случая когда кто-то забыл влепить ключевое слово abstract. Как бы приказ компилятору породить переменную.


AVK>ИМХО это уже перебор.


Нет. Не нужно вставлять грабли в свободный от них язык. Даже если это мелкие грабли. Нет никаких проблем избежать случайных ошибок. Значит это нужно сделать. Экономия в таких делах неуместна.

VD>> Ну, и получается унифицировано со вторым вариантом (в тотором свойство реализует толко get, а переменная доступна).


AVK>Зато неунифицированно с другими синтаксическими конструкциями шарпа.


Невижу никаких противоречий. Мы объявляем сразу две сущности. Свойство и поле. Как-то об этом нужно сказать. И лучше это сделать явно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.05 10:41
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Как тебе такой вариант:

LCR>
LCR>if (var b = a as B)
LCR>    b.A_Method();
LCR>

LCR>(Чуть логичнее, имхо.)

Можно и так. Хотя к этом варианту тоже можно докапаться. Ведь по идее тут получается обычный if в котором объявляется переменная. Не совсем логично.

В общем, над конкретной реализацией еще можно подумать. Но подобная конструкция была бы очень кстати.

Жаль, что надеяться на ее появление порактически не приходится. Ведь без запрета на использование as она бессмысленна. А на подобный запрет никто не пойдет, так как нарушится обратная совместимость.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.05 10:41
Оценка:
Здравствуйте, GlebZ, Вы писали:

VD>>5. Ввести у объектов идентификатор типа чтобы были возможно использовать их в switch:

VD>>
VD>>switch (someObj.TypeId)
VD>>{
VD>>    case typeof(A).TypeId: ... break;
VD>>    case typeof(C).TypeId: ... break;
VD>>    case typeof(D).TypeId: ... break;
VD>>    case typeof(E).TypeId: ... break;
VD>>}
VD>>

GZ>Слишком нетривиально и неоднозначно. Учитывая версии различных сборок которые могут подгружаться.

Итересно, с typeof(E) проблем нет, а тут вдруг возникнут? Такой свитчь должен инициализироваться при джит-компиляции метода где он объялвен. При этом нужно просто втупую получить информацию о типе классов A, C, D, Е, что приведет к загрузке соотвествующих сборок. После этого подменить сборки будет уже нельзя, так что проблем не будет.

VD>>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".

GZ>Может тогда уж лучше нормальный pattern matching?

Это тут не причем. Одно другому не мешает.

GZ>Эээ. У меня есть подозрение что такое может выполняться только на уровне CLR и при компиляции такого в runtime — JIT просто ляжет.


Наоборот. Такое может выполяняться только на начальных стадиях парсинга в компиляторе C#. Ведь тут говорится об изменении синтаксиса языка. И джит тут совсем не причем. Джит получит скопилированный код.

GZ>Я бы сюда добавил бы friends на уровне классов. Все таки иногда очень хочется. Только не в сишном варианте.


Может быть. Но тут врзникают проблемы идеологического плана в CLR.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.12.05 11:38
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Все равно в твоем варианте все очень нетривиально и плохо читаемо. Я скорее против такой фичи, нежели за.


VD>Очень аргументировано. Жаль не ясно, что тут плохо читается.


Тем не менее лично я очень долго не мог понять при взгляде на твой пример что он делает и нафига нужен. ИМХО читаемость от таких конструкций страдает очень сильно.

VD>Я верю, что ты пользушся as-ом окуратно и редко. Вот только ты не один на этом свете. Примеры использования as-а вместо приведения типов встречаются постоянно. Эта конструкция в сочетании с запретом открытого использования as-а полностью устранит проблему.


Но создаст другую — непрозрачность кода. И я не уверен которая из этих проблем лучше. Возможно, если просто изменить ключевые слова как нибудь так:
object x = ...;
object y = ...;
cast (SomeClass scx from x)
cast (SomeClass scy from y)
{
    scx.SomeClassMethod();
    scy.SomeClassMethod();
}

, то будет лучше. Вобщем этот вопрос надо обдумывать.

VD> Тут именн, что нужно защита от использования типа не по назначению. Сочетание if-а, декларации переменной и as-а. Собственно сам синтаксис можно обсуждать, но принцип как бы даже обсуждать нечего.


А с принципом я и не спорю.

VD>Я задолбался повторять.

VD>1. GUID невозмжожно использовать в свитче на сегодны. В конце концов GUID — это структора, что означает, что это а) он ен межет быть константой, б) он больше самого большого встроенног типа данных (long).

А Long тебе по любому не хватит, потому что тогда невозможно гарантировать уникальность TypeId.

VD>2. GUID типа нельзя получить во время компиялции,


Почему?

VD>Так что все твои слова теория не имеющая ничего общего с практикой.


Твои, что характерно, тоже.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[4]: Чего не хватает в C#?
От: Воронков Василий Россия  
Дата: 21.12.05 23:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Зачем? Проблема (A)b в том, что это ужасный синтаксис и кривизна при парсинге.


А вариант по типу A(b) напоминает о чем угодно вплоть до создания инстанса, но только не о приведении. Уж лучше по аналогии с С++: cast<Type>(obj)
Re[2]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 01:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>3. Замена приведений типов с С-стиля на функциональный стиль. Например, вместо:

VD>
VD>A a = (A)b;
VD>

VD>будет писаться:
VD>
VD>A a = A(b);
VD>


А смысл? Визуально похоже на конструктор и приходится искать глазами — а не затаился ли рядом оператор new

VD>4. Устранение оператора "as" и введение конструкции "var if" выглядящей следующим образом:

VD>
VD>var if (b = a as B)
VD>{
VD>    b.A_Method();
VD>}
VD>

VD>или
VD>
VD>var if (b = a as B)
VD>    b.A_Method();
VD>

VD>смысл таков. Если "a" в данной точке приводится к типу "B", то в рамках блока идущего за закрывающей скобокй в будет интерпретироваться как "a" привденная к типу "B". Если приведение невозможно, то управление не должно передаваться внутрь вложенного блока.
VD>Как развитие оператора можно добавить к нему конструкцию "else":
VD>
VD>var if (b = a as B)
VD>    b.A_Method();
VD>else var if (c = a as С)
VD>    c.A_Method();
VD>else 
VD>    throw new MyException(...);
VD>


Зачем было вводить новое слово я не понял. проще разрешить объявление перемнной в if так же как это уже делается в for и foreach.
if ((B b = a as B) != null)
{
    b.A_Method();
}

Ну или оператор запятая пригодится.
if (B b = a as B, b != null)
{
    b.A_Method();
}


VD>5. Ввести у объектов идентификатор типа чтобы были возможно использовать их в switch:

VD>
VD>switch (someObj.TypeId)
VD>{
VD>    case typeof(A).TypeId: ... break;
VD>    case typeof(C).TypeId: ... break;
VD>    case typeof(D).TypeId: ... break;
VD>    case typeof(E).TypeId: ... break;
VD>}
VD>


Зачем ещё один идентификатор? Думаю так в самый раз

VD>
VD>switch (typeof(someObj).AssemblyQualifiedName)
VD>{
VD>    case typeof(A).AssemblyQualifiedName: ... break;
VD>    case typeof(C).AssemblyQualifiedName: ... break;
VD>    case typeof(D).AssemblyQualifiedName: ... break;
VD>    case typeof(E).AssemblyQualifiedName: ... break;
VD>}
VD>


Да, ещё хорошо бы чтоб typeof можно было делать и над объектами

VD>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".


А вот это уже плохая идея. Объекты должны реализовывать не ==, а <, иначе switch ничем не будет отличаться от последовательности if

VD>8. Добавление реализации (миксины, трэтсы).


Ещё неплохо бы уметь указывать не необходимы к реализации интерфейс, а сигнатуры методов. Хотя бы операторов.

VD>10. Ввести в язык некие синтаксические макросы позволяющие заниматься метапрограммированием и переписать весь синтаксический сахар них.


Это будет тихий ужас. Ты когда нибудь генерировал на ASP/PHP JavaScript код? Лучше и не пытайся
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[8]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 08:48
Оценка:
Здравствуйте, Belsen, Вы писали:

B>В случаях, когда кастится не выражение, а локальная переменная или параметр, что мешает дать им просто более строгий compile-time тип внутри cast'а?

B>[c#]
B>object pack = ....
B>ifcast (pack to IEnumerable)
B>{
B> foreach (object item in pack)

Я думал о таком варианте. ИМХО плохо — читаемость страдает очень сильно (тип одной и той же переменной зависит от контекста)
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[8]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 08:48
Оценка:
Здравствуйте, IT, Вы писали:

IT>Всё что надо сделать — это разрешить объявлять переменные в if. Тогда уж я как-нибудь и сам справлюсь:


IT>
IT>if ((MyType myType = myParameter as MyType) != null)
IT>{
IT>    myType.BlahBlahBlah();
IT>}
IT>


Не, ты идеи Влада не понял. Там смысл не в сокращении количества строчек.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[3]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 08:59
Оценка:
Здравствуйте, adontz, Вы писали:

A>Да, ещё хорошо бы чтоб typeof можно было делать и над объектами


Над экземплярами? А чем GetType() не устраивает?

VD>>8. Добавление реализации (миксины, трэтсы).


A>Ещё неплохо бы уметь указывать не необходимы к реализации интерфейс, а сигнатуры методов. Хотя бы операторов.


Это уже обсуждалось. Ищи по словам duck typing.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[4]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 12:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Над экземплярами? А чем GetType() не устраивает?


Единообразия нет

A>>Ещё неплохо бы уметь указывать не необходимы к реализации интерфейс, а сигнатуры методов. Хотя бы операторов.


AVK>Это уже обсуждалось. Ищи по словам duck typing.


Нашёл это http://en.wikipedia.org/wiki/Duck_typing Не очень понял зачем такое в C#
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Чего не хватает в C#?
От: IT Россия linq2db.com
Дата: 22.12.05 12:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не, ты идеи Влада не понял. Там смысл не в сокращении количества строчек.


А в чём? В лишнем преобразовании?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 14:50
Оценка:
Здравствуйте, IT, Вы писали:

AVK>>Не, ты идеи Влада не понял. Там смысл не в сокращении количества строчек.


IT>А в чём? В лишнем преобразовании?


В том чтобы невозможно было написать код вроде:
SomeClass sc = obj as SomeClass;
sc.Method();
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[5]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 14:50
Оценка:
Здравствуйте, adontz, Вы писали:

AVK>>Над экземплярами? А чем GetType() не устраивает?


A>Единообразия нет


А оно в данном случае нужно?

A>>>Ещё неплохо бы уметь указывать не необходимы к реализации интерфейс, а сигнатуры методов. Хотя бы операторов.


AVK>>Это уже обсуждалось. Ищи по словам duck typing.


A>Нашёл это http://en.wikipedia.org/wiki/Duck_typing


Я имел ввиду в этом форуме

A> Не очень понял зачем такое в C#


Это у тебя надо спросить, ты же его предлагаешь в C# добавить.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[6]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 15:15
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Это у тебя надо спросить, ты же его предлагаешь в C# добавить.


Так, как я понял, всё в рантайме. Я же предлагаю решение этой проблемы http://www.rsdn.ru/Forum/Message.aspx?mid=1548538
Автор: adontz
Дата: 19.12.05
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[7]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 15:35
Оценка:
Здравствуйте, adontz, Вы писали:

AVK>>Это у тебя надо спросить, ты же его предлагаешь в C# добавить.


A>Так, как я понял, всё в рантайме.


А в компайл-тайме есть делегаты.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[9]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.12.05 22:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Главное — не надо ударяться в крайности. Я сторонник золотой середины, т.е. вполне допускаю варианты, когда вероятность ошибки незначительна, а набирать и читать проще.


Ты проводил исследование по поводу того насколько незначительны будут проблемы связанные с этим делом? Я думаю — нет. Тогда и не нужно приводить это дело в качестве аргумента.
В общем, лучше вообще не создавать грабли, чем анализировать их опасность.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Чего не хватает в C#?
От: Belsen  
Дата: 22.12.05 22:59
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Я думал о таком варианте. ИМХО плохо — читаемость страдает очень сильно (тип одной и той же переменной зависит от контекста)

Увы — есть такое. Хотя возможно, что вопрос привычки.

Так а как насчет варианта с экстеншеном As<T> в Linq?

foreach (var food in item.As<IEatable>())
{
    ....
}


где As<T>:
public static IEnumerable<T> As<T>(this object o)
{
    if (o is T)
        yield return (T) o;
}


Вполне NullReferenceException- и TypeCastException-безопасно
I might be wrong...
Re[3]: Чего не хватает в C#?
От: Павел Кузнецов  
Дата: 23.12.05 04:55
Оценка:
Lazy Cjow Rhrr,

>
> if (var b = a as B)
>     b.A_Method();
>

> (Чуть логичнее, имхо.)

Уже есть в подобном виде в C++:
if (B* b = dynamic_cast<B*>(a))
   b->A_Method();
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[5]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 23.12.05 07:58
Оценка:
Здравствуйте, AndrewVK, Вы писали:

мне больше нравилось другое предложение насчте св-в, по-моему от xvost

типа так:
int Property1 {
  int _prop1;

  get { return _prop1; }
  set { _prop1 = value; }
}


Эдакое основательно защищенное даже от самого класса значение св-ва.
Re[4]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 23.12.05 08:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Lazy Cjow Rhrr, Вы писали:


LCR>>Как тебе такой вариант:

LCR>>
LCR>>if (var b = a as B)
LCR>>    b.A_Method();
LCR>>

LCR>>(Чуть логичнее, имхо.)

VD>Можно и так. Хотя к этом варианту тоже можно докапаться. Ведь по идее тут получается обычный if в котором объявляется переменная. Не совсем логично.


VD>В общем, над конкретной реализацией еще можно подумать. Но подобная конструкция была бы очень кстати.


Дык, я же тоже самое предложил. Достаточно, чтобы if проверял на null. В С++ эта конструкция прекрасно работает.


VD>Жаль, что надеяться на ее появление порактически не приходится. Ведь без запрета на использование as она бессмысленна. А на подобный запрет никто не пойдет, так как нарушится обратная совместимость.


Неплохо смотрится вариант ifcast().

Вообще, почему бы не подобавлять в язык краткие синонимы наиболее встречающихся последовательностей вокруг if:

— ifcast(exp to Type1)
— ifnull(exp)
— ifvalue(exp)/ifnotnull()
— ifzero(exp)

На многих функциональных языках легко делать подобные расширители синтаксиса (и на Лисп в т.ч.) Оттого и запись зачастую компактнее и нагляднее.
Re[10]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.12.05 09:14
Оценка:
Здравствуйте, Belsen, Вы писали:

B>Так а как насчет варианта с экстеншеном As<T> в Linq?


Нормально, но неуниверсально.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[10]: Чего не хватает в C#?
От: Roman Rumin Россия http://www.radio-taxi.ru/
Дата: 23.12.05 16:40
Оценка:
Здравствуйте, All.

Я на 1,0.
Объясните плз, смысл угловых скобок
Такси ст
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Главное — не надо ударяться в крайности. Я сторонник золотой середины, т.е. вполне допускаю варианты, когда вероятность ошибки незначительна, а набирать и читать проще.


VD>>Ты проводил исследование по поводу того насколько незначительны будут проблемы связанные с этим делом? Я думаю — нет. Тогда и не нужно приводить это дело в качестве аргумента.


AVK>А ты проводил?


Я не делаю утверждений о значимости или не значимости.
На вопрос ты, кстати, не ответил.

VD>>В общем, лучше вообще не создавать грабли, чем анализировать их опасность.


AVK>Грабли тут с двух сторон. Осталось определить с какой стороны зубья короче.


Грабли тут привносит твое предложение. Никаких других сторон тут нет.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>в хорошем коде должно быть как можно меньше приведений типов. Так что чем больше усложняется написание грязных конструкций, тем лучше


Зашибись! Ну, то есть если мне нужно обработать событие которое не по моей воле во фрэймворке передает ссылку на object, то я должен наблюдать горы грязи?

В общем, нет никакой корелляции между утврерждением "в хорошем коде должно быть как можно меньше приведений типов" (с которым я собственно согласен) и "чем больше усложняется написание грязных конструкций, тем лучше".

Д>да. но и со скобками их ведь не пишут


То есть вопрос только в скобках? Нет проблем!
void yield()
{
    yield();
}


VD>>Еще раз повторюсь. Нет никакой разницы между методом преобразующим один тип в другой и оператором. Это все надоуманные догмы связанные с тем что ты привык к С-шному синтаксису. Те кто пишет на языках с функциональным приведением типов не испытывают комплексов по этому поводу.


Д>а откуда ты знаешь, к какому синтаксису я привык?


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

VD>>Везде где есть привдение типов. В общем, как только начинашь проектировать код в понятих типов, то и приведения получаются и операторы.


Д>пример операторов неявной конверсии типов — в студию!


Не понял.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>я говорил о характере самой операции, а ты зачем-то завел речь об оптимизации

Д>неважно, что в некоторых случаях можно обойтись без использования отражения — потому что в общем случае, такая проверка нужна

Напомню контекст:

Д>и каким интересно образом он приведет от Object к Control без проверки?

Про анализ потоков данных слышал? У джита есть все возможности для этого.


Устранение приведений типов — это оптимизация которую может выполнять джит или преджит.

VD>>И что? Тебе там код кто-то даст? И вообще, ты хорошо понимашь где и как делаются подобные оптимизации? Это же делает джит или пре-джит. Им до до лампочки наличие или отсуствие кода.


Д>а при чем тут вообще джит? читай выше


Может лучше тебе выше почитать? Это вообще-то о твоих словах:

А куда ты перейдешь, если код функции тебе не доступен?...


Д>это все хорошо, но какое отношение оно имеет к cast? для него вообще грамматика LL(1) легко строится хотя конечно интересно.


Вопрос был в замене С-шного стиля приведения типов на функциональный. Твой cast<> — это тоже функциональный стиль, только обладающий явной избыточностью.

Д> Не думал, что у них парсер настолько черех ж%;у сделан

Д>почему бы не сделать чистый КС-парсер, который будет проверять язык на соответствие некоторому КС-надмножеству языка, а разрешение неоднозначных конструкций сделать вторым этапом, когда уже есть точная информация об имеющихся в наличии типах?

Потому что значение конструкции в скобках зависит от ее семантики, а зависимость от семантики означает, что язык не является контексно-свободным. Чтобы язык остался контекстно-свободным были введены эвристики повзволяющие решить проблемы. Вот только если бы чуть исправить граматику, то проблема бы отпала сама собой.

Д>а еще хорошо бы, чтобы парсер умел сам заглядывать вперед и перебирать возможные ветки разбора для неоднозначных мест в грамматике (если уж мечтать, так по полной программе )


Это как раз плохо, так как усложняет парсер. В данном случае и так приходится заглядывать вперед по самое нехочу. И вообще, это особенность языка, а не парсера. Эвристики прописаны в спецификации. Цель как раз была упростить построение парсера. Если бы небыло эвристик, то была бы такая же задница как в С++ (когда построить корректный парсер могут только еденицы во всем мире).

Д>да я его и не защищаю (С-шное соглашение, то есть)


Мне казалось, что защищашь.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


VD>>Зачем? Проблема (A)b в том, что это ужасный синтаксис и кривизна при парсинге.


ВВ>А вариант по типу A(b) напоминает о чем угодно вплоть до создания инстанса, но только не о приведении. Уж лучше по аналогии с С++: cast<Type>(obj)


Я незнаю, что тебе там напоминает. Но без new экземпляра не создать. Так что об этом можно уже перестать разговаривать.
В С++ нет никаких cast<Type>(obj). В нем есть разные static_cast<Type>() и т.п., что есть не что иное как применение того самого функционанльного стиля в сочетании с шаблонами. Xxx<Y>() в С++ — это синтаксис вызова функции. static_cast и т.п. были введены в язык исключительно из-за того, что переусложненная семантика языка требовала введения разных вариантов приведения типов.

Что касается "напоминаний". Да недолжны приведения типов ничего напоминать. Приведение типов есть функция из одного типа в другой. И нечего странного если она и выглядит как функция.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Тем не менее лично я очень долго не мог понять при взгляде на твой пример что он делает и нафига нужен. ИМХО читаемость от таких конструкций страдает очень сильно.


Вот и хотелось бы услышать аргументы.

AVK>Но создаст другую — непрозрачность кода. И я не уверен которая из этих проблем лучше. Возможно, если просто изменить ключевые слова как нибудь так:

AVK>
AVK>object x = ...;
AVK>object y = ...;
AVK>cast (SomeClass scx from x)
AVK>cast (SomeClass scy from y)
AVK>{
AVK>    scx.SomeClassMethod();
AVK>    scy.SomeClassMethod();
AVK>}
AVK>

AVK>, то будет лучше. Вобщем этот вопрос надо обдумывать.

Обдумывать конечно нужно. Однако в твоем варианте введено действительно два новых ключевых слова. Если "from" МС вроде как использует, то cast — это уже точно перебор. Да и не подходит оно тут. Тут скорее нужно слово "protect" или "declade if".

AVK>А с принципом я и не спорю.


Ну, так, так и надо говорить. А то же неясно, что тебе ненравится.

Хотя конечно — это все незбыточные мечты. На разрыв обратной совместимости МС явно не пойдет. Это так и останется ошибкой дизайна языка.

VD>>Я задолбался повторять.

VD>>1. GUID невозмжожно использовать в свитче на сегодны. В конце концов GUID — это структора, что означает, что это а) он ен межет быть константой, б) он больше самого большого встроенног типа данных (long).

AVK>А Long тебе по любому не хватит, потому что тогда невозможно гарантировать уникальность TypeId.


Да причем тут long? Блин, ты вообще пыташся понять о чем я говорю? Еще раз, последний. Мне нужен идентификатор типа который я смог бы использовать в свитчах. Все!

VD>>2. GUID типа нельзя получить во время компиялции,


AVK>Почему?


Блин, спроси в МС. По факту — нельзя!

VD>>Так что все твои слова теория не имеющая ничего общего с практикой.


AVK>Твои, что характерно, тоже.


Мои — есть требования отвечающие на вопрос "что бы я добавил/изменил в C#". Ты же говоришь, что что-то есть и при этом основываешь свои суждения на том, что не существует в природе. Разницу улавливашь?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, Roman Rumin, Вы писали:

RR>Я на 1,0.

RR>Объясните плз, смысл угловых скобок

http://rsdn.ru/article/csharp/newincsharp.xml
Автор(ы): Владислав Чистяков (VladD2)
Дата: 24.06.2004
В статье рассказывается о новшествах, которые должны появиться в новой версии языка C#

... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, IT, Вы писали:

IT>Всё что надо сделать — это разрешить объявлять переменные в if. Тогда уж я как-нибудь и сам справлюсь:


IT>
IT>if ((MyType myType = myParameter as MyType) != null)
IT>{
IT>    myType.BlahBlahBlah();
IT>}
IT>

IT>Причём объявлять переменные уже можно внутри using, у foreach синтаксис тоже близкий, так что разногласий с линией партии не будет.

В принципе неплохое решение. Только нужно еще добавить провекрку на то, что после применения оператора as должна быть обязательная проверка на [не] равенство null. Ну, хотя бы чтобы варнинг бросался. Тогда и обратная совместимость останется.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, vdimas, Вы писали:

V>мне больше нравилось другое предложение насчте св-в, по-моему от xvost


V>типа так:

V>
V>int Property1 {
V>  int _prop1;

V>  get { return _prop1; }
V>  set { _prop1 = value; }
V>}
V>


V>Эдакое основательно защищенное даже от самого класса значение св-ва.


Это просто бессмысленное решение.
1. Синтаксический оверхэд не исчезает.
2. Переменная не дотсупна извне, так что в случае со свойством у которого нет сеттера вообще получается бред.

Еще раз. Одно из проблем свойств — слишком большой синтаксический оверхэд. Ну, а проблему дополнительной локализации лучше решать введением областей видимости, о чем я уже говорил.

Уж лучше как-то так:
property int Property { get; set; } // свойство доступное на запись и чтение
property int Property { get; private set; } // свойство везеде доступное на чтение и только внутри класса на чтение.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Дык, я же тоже самое предложил. Достаточно, чтобы if проверял на null. В С++ эта конструкция прекрасно работает.


Мля, это одни из нериятнейших граблей плюсов которые избежали при проектировании Шарпа! Это не просто разрешение проверки на нул. Это резрешение приведения типа указатель к булевому типу! И это не типобезопасно!

Так что это идея неприемлемая.

V>Неплохо смотрится вариант ifcast().


Лишнее клчевое слово и не ясное поведение переменной.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, adontz, Вы писали:

A>А смысл? Визуально похоже на конструктор и приходится искать глазами — а не затаился ли рядом оператор new


Только для тех кто сильно переписал на С++ (без обид). Для остальных похоже на вызов функции, что совершенно нормально.

A>Зачем было вводить новое слово я не понял.


Слово ввели без меня.

A> проще разрешить объявление перемнной в if так же как это уже делается в for и foreach.

A>
A>if ((B b = a as B) != null)
A>{
A>    b.A_Method();
A>}
A>


Ну, возможно ты и прав.

A>Ну или оператор запятая пригодится.

A>
A>if (B b = a as B, b != null)
A>{
A>    b.A_Method();
A>}
A>


Только запятые явно лишние. Уж лучше было бы услоиться, что при объявлении переменной if проверяет ее на null.

A>Зачем ещё один идентификатор? Думаю так в самый раз


VD>>
VD>>switch (typeof(someObj).AssemblyQualifiedName)
VD>>{
VD>>    case typeof(A).AssemblyQualifiedName: ... break;
VD>>    case typeof(C).AssemblyQualifiedName: ... break;
VD>>    case typeof(D).AssemblyQualifiedName: ... break;
VD>>    case typeof(E).AssemblyQualifiedName: ... break;
VD>>}
VD>>


Сложновато, длинновато и не эффективно.

A>Да, ещё хорошо бы чтоб typeof можно было делать и над объектами


Это не требуется. Есть метод GetType().

VD>>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".


A>А вот это уже плохая идея. Объекты должны реализовывать не ==, а <, иначе switch ничем не будет отличаться от последовательности if


В таких случаях используется хэш-таблица. Собственно так делается когда ты используешь строки в switch-е. Сравнение в сочетании с GetHashCode() (который и так есть у каждого объекта) позволяет использовать объект в хэш-таблице. Так что switch будет просто синтаксическим сахаром к ней.

VD>>8. Добавление реализации (миксины, трэтсы).


A>Ещё неплохо бы уметь указывать не необходимы к реализации интерфейс, а сигнатуры методов. Хотя бы операторов.


Об этом я уже сказал когда говорил о констрэйнах.

VD>>10. Ввести в язык некие синтаксические макросы позволяющие заниматься метапрограммированием и переписать весь синтаксический сахар них.


A>Это будет тихий ужас. Ты когда нибудь генерировал на ASP/PHP JavaScript код? Лучше и не пытайся


Все будет ОК. Тут императивное ASP не причем. Тут скорее с Лиспом нужно аналогии проводить.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 01:06
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Гм. Тут дело на самом деле не в С++. Синтаксис сам по себе похож на вызов конструктора. Например, если предположить что я забыл указать new, то компилятор даже попробует собрать что-нибудь такое:


ВВ>A a = A(b);


ВВ>и очень может быть что это ему удастся


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

ВВ>В С# тоже


Да, и зачем приписывать совершенно не значащий префикс удлинняющий выражения?

ВВ>Чем мне нравится подобный синтаксис — тем что он заметен, бросается в глаза.


А зачем ему быть более заметным? И чем это будет заметнее нежели некий cost<Type>(obj)?

В среде разработки типы у тебя будут подсвечиваться отдельным цветом и ты никогда не перепуташь приведение типа и вызов отдельной фукнции. Хот ничего страншого в этом нет. Приведение и есть функция.

ВВ> Типа "ахтунг, здесь приведение!". А со всякими (B)a, B(a) глаз просто замыливается. В твоем случае будет даже хуже. Глядя на какое-нибудь навороченное выражение вообще будет сложновато определить, где вызов метода, где приведение..


А ненужно это определять!!! (Хотя это и так будет видно очень не плохо.)
Ну, не нужно! Нет семантической разницы, значит и нет смысла выделять. Даже наоборот. Может быть кто-то задумается над тем, что приведение типа столь же сложная операция, что и вызов функции и не станет ее применять без надобности.

VD>>Что касается "напоминаний". Да недолжны приведения типов ничего напоминать. Приведение типов есть функция из одного типа в другой. И нечего странного если она и выглядит как функция.


ВВ>Правильно. Так как Xxx<Y>() в С# — это синтаксис вызова функции пускай она так и выглядит.


Это необоснованно удленненный синтаксис.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 01:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Только для тех кто сильно переписал на С++ (без обид). Для остальных похоже на вызов функции, что совершенно нормально.


На самом деле плохо. Если забыть new то можем получить теже грабли, что и с =/== в Си++. Вариант с cast<A>(b) мне тоже больше нравиться.

VD>>>
VD>>>switch (typeof(someObj).AssemblyQualifiedName)
VD>>>{
VD>>>    case typeof(A).AssemblyQualifiedName: ... break;
VD>>>    case typeof(C).AssemblyQualifiedName: ... break;
VD>>>    case typeof(D).AssemblyQualifiedName: ... break;
VD>>>    case typeof(E).AssemblyQualifiedName: ... break;
VD>>>}
VD>>>

VD>Сложновато, длинновато и не эффективно.

Это вопрос реализации. Если ввести typeid аналогичный плюсовому с релизацией типа typeid(A) == typeof(A).AssemblyQualifiedName то всё будет ОК. Значения строк известны на момент компиляции, будет
switch (typeid(someObj))
{
    case typeid(A): ... break;
    case typeid(C): ... break;
    case typeid(D): ... break;
    case typeid(E): ... break;
}

Коротко и понятно. А насчёт неэффективности это ты не прав — будет обычный switch по строкам.

A>>Да, ещё хорошо бы чтоб typeof можно было делать и над объектами

VD>Это не требуется. Есть метод GetType().

См выше про switch. Для единообразия пригодится.

VD>В таких случаях используется хэш-таблица. Собственно так делается когда ты используешь строки в switch-е. Сравнение в сочетании с GetHashCode() (который и так есть у каждого объекта) позволяет использовать объект в хэш-таблице. Так что switch будет просто синтаксическим сахаром к ней.


Тут есть разница. Для многих типов нормальная реализация GetHashCode() головная боль, а "operator <" совсем нет.

VD>Все будет ОК. Тут императивное ASP не причем. Тут скорее с Лиспом нужно аналогии проводить.


О да Давно я не слышал о хорошей поддерживаемости Лисп кода.
Малейшая ошибка в реализации этой фичи породит кучу малопонятных загогулинок с которыми потом ещё и совместимость придётся поддерживать. А если перестраховатся её назовут бесполезной. Как ни крути будешь виноват
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 04:32
Оценка:
Здравствуйте, adontz, Вы писали:


...
B b = new B(3);
A a = new A(b);


A>Если в последней строке забыть new то вместо создания нового типа получим приведение типа. Естественно что это может приводить в разным последствиям, например, сохранению связи между объектами, когда изменение a будет влиять и на b. Говоря попросту очередные грабли от которых в проекте наступает полная Ж.


Ну, а теперь внимательно погляди на код и объясни какая разница будет между "new A(b)" и "A(b)"? Что то, что это выполняет одну и ту же операцию. Преобразует б в А. Любой грамотный программист или вообще создаст возможность сделать это двумя путями, или обеспечит сементическую эквивалентность. Например, int к IntPtr можно привести как оператором, так и через конструктор:
IntPtr intPtr = new IntPtr(123);
IntPtr intPtr = (IntPtr)123;

Или другой пример... с делегатами. В C# 2.0 нет разницы между:
SomeDelegate del = SomeFuncName;
SomeDelegate del = (SomeDelegate)SomeFuncName;
SomeDelegate del = new SomeDelegate(SomeFuncName);

И это правильно!

Надо учитывать, что просто так конструкторы с параметрами других типов не появляются. И приведения типов тоже от сырости не заводятся. Так что на прктике таких ошибок небудет вовсе. Я писал на нескольких языках с функциональным приведением типов и не испытывал проблем.

Так что никаких граблей здесь нет и в помине. Эдак можно за грабли посчитать возможность создания фунций с разными именами .
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 04:37
Оценка:
Здравствуйте, adontz, Вы писали:

A>На самом деле плохо. Если забыть new то можем получить теже грабли, что и с =/== в Си++. Вариант с cast<A>(b) мне тоже больше нравиться.


На это я уже ответил рядом.

A>Тут есть разница. Для многих типов нормальная реализация GetHashCode() головная боль, а "operator <" совсем нет.


Глупости не говори. Это как раз сравнение на больше меньеш невозможно для обень большого количества классов. Например, сравни на больше меньше те же типы (System.Type). А вот как раз сравение на эквивалентность и хэш-код можно создать для любого объекта если он имеет состояние (а другие в свитче и не нужны). Именно по этому любой объект имеет вирутальные функции:
bool Equals(object obj);
и:
int GetHashCode();
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: WolfHound  
Дата: 24.12.05 11:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Мля, это одни из нериятнейших граблей плюсов которые избежали при проектировании Шарпа! Это не просто разрешение проверки на нул. Это резрешение приведения типа указатель к булевому типу! И это не типобезопасно!

VD>Так что это идея неприемлемая.
Ну почемуже? ИМХО вполне безопасно если ограничить это привидение только случаем когда в if'е объявляется переменная.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Чего не хватает в C#?
От: WolfHound  
Дата: 24.12.05 11:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А что плюсы позволяют объявлять переменые внутри скобок if-а?

Да. Кстати неплохо экономит строки кода.
    ref<Type1> item1 = GetSome();
    if (item1)
    {
        ref<Type2> item2 = item1->GetSome();
        if (item2)
        {
            ref<Type3> item3 = item2->GetSome();
            if (item3)
            {
                //Тут все проверено на null
            }
        }
    }

    if (ref<Type1> item1 = GetSome())
    if (ref<Type2> item2 = item1->GetSome())
    if (ref<Type3> item3 = item2->GetSome())
    {
        //Тут все проверено на null
    }
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 24.12.05 12:24
Оценка:
Здравствуйте, VladD2, Вы писали:

V>>Дык, я же тоже самое предложил. Достаточно, чтобы if проверял на null. В С++ эта конструкция прекрасно работает.


VD>Мля, это одни из нериятнейших граблей плюсов которые избежали при проектировании Шарпа! Это не просто разрешение проверки на нул. Это резрешение приведения типа указатель к булевому типу!


Я там ниже предложил более явные варианты ifnull и пр. Реакции не увидел.

VD>И это не типобезопасно!


При чем тут типобезопасно? Вот кусок из моей мини-реализации Лиспа под .Net:
public class Bool : Obj {
    ...

    public static bool implicit(Bool b) {
        return (b==null)?false:true;
    }    


    public static Bool implicit(bool b) {
        return b?Lang.T:null /*NIL*/;
    }    
}


Все типобезопасно, а грабли на месте.

Потому как грабли не в типобезопасности, а в смешении семантик. Т.е. в C# никак не перепутаешь присвоение для ЛЮБОГО типа (не только ссылочного) со сравнением. Банальная защита от частовстречающейся ошибки "=" вместо "==".


V>>Неплохо смотрится вариант ifcast().


VD>Лишнее клчевое слово и не ясное поведение переменной.


Что за боязнь лишних ключевых слов? В чем проблема? Если они позволяют более кратко описать самые частовстречающиеся сценарии, то они должны быть, ИМХО.

Насчет неясного поведения переменной — не понял. Я там exp написал. Если тебе нужна переменная после приведения, то нужно лишь допустить объявление переменной в конструкции:
ifcast(arg1 to IComparable cm) {
   return cm.CompareTo(arg2);
}
Re[5]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 24.12.05 12:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Павел Кузнецов, Вы писали:


ПК>>Уже есть в подобном виде в C++:

ПК>>
ПК>>if (B* b = dynamic_cast<B*>(a))
   b->>>A_Method();
ПК>>


VD>А что плюсы позволяют объявлять переменые внутри скобок if-а?


И не только if-а.
Re[11]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.12.05 18:23
Оценка:
Здравствуйте, adontz, Вы писали:

A>Конкретных реализация две — замена на последовательность if выстроенную в двоичное дерево поиска и таблица преходов. Всё остальное не так эффективно на практике.


На всякий случай.
Итак — свитч по строкам шарпа:
string x = "A";
switch (x)
{
    case "A" : break;
    case "B" : break;
    case "C" : break;
    case "D" : break;
    case "E" : break;
    case "F" : break;
    case "G" : break;
    case "H" : break;
}

Компилируется в такой IL (комментарии на русском мои)
// Загружаем статическое поле с хеш-таблицей типа Dictionary<string, int>, которая инициализируется при первом обращении.
// Ключ - строковая константа, значение - порядковый номер соотв. case.
IL_0087:  ldsfld     class [mscorlib]System.Collections.Generic.Dictionary`2<string,int32> '<PrivateImplementationDetails>{239ED911-1286-4F02-9339-7050238A9B72}'::'$$method0x6000001-1'
// Загружаем в стек значение в switch. В локальной переменной V_2 соотв индекс (просто порядковый номер case).
IL_008c:  ldloc.1
IL_008d:  ldloca.s   V_2
// Ищем строку в хеш-таблице
IL_008f:  call       instance bool class [mscorlib]System.Collections.Generic.Dictionary`2<string,int32>::TryGetValue(!0,
                                                                                                                                                                                                                                            !1&)
// Если null то switch пропускаем
IL_0094:  brfalse.s  IL_00ce
// Загружаем в стек найденный индекс
IL_0096:  ldloc.2
// И вызываем стандартный switch CLR
IL_0097:  switch     ( 
                                            IL_00be,
                                            IL_00c0,
                                            IL_00c2,
                                            IL_00c4,
                                            IL_00c6,
                                            IL_00c8,
                                            IL_00ca,
                                            IL_00cc)
// Бряки
IL_00bc:  br.s       IL_00ce
IL_00be:  br.s       IL_00ce
IL_00c0:  br.s       IL_00ce
IL_00c2:  br.s       IL_00ce
IL_00c4:  br.s       IL_00ce
IL_00c6:  br.s       IL_00ce
IL_00c8:  br.s       IL_00ce
IL_00ca:  br.s       IL_00ce
IL_00cc:  br.s       IL_00ce
IL_00ce:  ret
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[12]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 19:32
Оценка:
Здравствуйте, AndrewVK, Вы писали:

A>>Конкретных реализация две — замена на последовательность if выстроенную в двоичное дерево поиска и таблица преходов. Всё остальное не так эффективно на практике.


AVK>На всякий случай.

AVK>Итак — свитч по строкам шарпа:

Это всё правильно, но только для строк. Из приведённого кода ясно видно, что для разных строк хеш гарантированно разный. Далеко не все хеш-функции могут этим похвастаться.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Чего не хватает в C#?
От: Mab Россия http://shade.msu.ru/~mab
Дата: 24.12.05 19:35
Оценка:
Здравствуйте, adontz, Вы писали:
A>Из приведённого кода ясно видно, что для разных строк хеш гарантированно разный.
Это не верно. Хеш строк может быть одинаковый. Если посмотреть внимательно, то switch делается по индексу, который уникален. Так что никакой специфики в строках здесь нет.
Re[14]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 19:41
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>Это не верно. Хеш строк может быть одинаковый. Если посмотреть внимательно, то switch делается по индексу, который уникален. Так что никакой специфики в строках здесь нет.


А да. Виноват В IL не силён Ну по крайней мере можно надеяться что хеш строки вычисляется по-умному
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.12.05 20:00
Оценка:
Здравствуйте, adontz, Вы писали:

AVK>>На всякий случай.

AVK>>Итак — свитч по строкам шарпа:

A>Это всё правильно, но только для строк.


Для типов ситуация не хуже.

A>Из приведённого кода ясно видно, что для разных строк хеш гарантированно разный.


??? Собственно почему ты так решил?
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[14]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 20:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

A>>Это всё правильно, но только для строк.

AVK>Для типов ситуация не хуже.

Это кажется в другой ветке было. Тут мы обсуждаем switch по объектам произвольного типа.

A>>Из приведённого кода ясно видно, что для разных строк хеш гарантированно разный.

AVK>??? Собственно почему ты так решил?

Это я лажанулся, уже поправили
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Чего не хватает в C#?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.12.05 20:22
Оценка:
Здравствуйте, adontz, Вы писали:

A>Это кажется в другой ветке было. Тут мы обсуждаем switch по объектам произвольного типа.


А с объектами произвольного типа уже сейчас надо думать о семантике сравнения. В большинстве случаев хватает базовой реализации, ну а в тех редких ситуациях, когда это ссылочный тип и может быть несколько экземпляров, описывающих одну сущность можно и реализовать Equals и GetHashCode, что, как тут справедливо заметили, не так уж и сложно.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[7]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 03:38
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Ну почемуже? ИМХО вполне безопасно если ограничить это привидение только случаем когда в if'е объявляется переменная.


Специальная семантика именно для описания переменной? Ну, может быть. Это нужно серьезно обдумать.

В Шарпе переменную можно создать только в виде statment-а, т.е. не expression-а. И к чему приведет изменение этого правила еще неизвестно. Ведь язык это целостная система. Изменение одного аспекта легко может развалить ее.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 25.12.05 04:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Конечно любая такая функция может делать все что угодно. В плоть до создания побочных эффектов.


Только не "создания", а "не удаления".

VD>Более того они должны быть максимально прозрачн. Я, как пользователь, должен получить из объекта А объект Б и не более того.


Да, только вот что будет с объектом А, когда ты меняешь объект Б это implementation defined. И лучше предполагать, что связь между ними сохраняется и перестраховаться, чем априори говорить что связи нету и получить по лбу.

VD>Посему твои предположения лучше исключить из рассмотрения.


Долго что-то говорил, потом сделал "вывод". Никаких предпосылок к этой фразе в предыдущем тексте не было.

VD>Иначе мы вынуждены будем признать, что ЯП вообще не имеют право на существования, так как любая функция может нести в себе все что угодно и полагаться на нее нельзя.


Ой понесло... Даже не интересно уже

A>> Если тебе почему-либо всё ещё не понятно, то вот другой пример — тут уже разница есть и она огромная...

VD>Примеров подтасавывающих результаты можно придумть очень много. Думаю не стоит тратить времени на их анализ.

С каких это пор копирование ссылок это подтасовка результатов?

A>>И не надо говорить, что это пример надуманный.

VD>Конечно не надо. Ты и сам это знашь.

Я как раз считаю, что вполне реальный. Есть куча классов, которым в конструктор передаётся параметр и уточнение, что с ним делать.

A>> Преобразование типа это не создание нового объекта. Это просто another view for the same content.

VD>Это догмы человека который не хочет сбросить шоры и посмотреть на мир проще.

Это не догма. Это то правило, которое позволяет избегать граблей.

VD>Между тем приведение типа не определяет семантики.


В общем случае нет, но лучше считать, что она такая, чем надеяться, что всё обойдётся.

VD>Заметь! Один из примеров! А другой преобразование строки в массив символов. Почему при этом не порадить новый массив?


Потому что не нужно.

A>>Влад, это грабли хотя бы потому что есть альтернативное мнение.

VD>Это проблемы косности мышления. Смотри на проблему шире.

Я то предположим посмотрю. Каждого будешь уговаривать персонально?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 05:39
Оценка:
Здравствуйте, adontz, Вы писали:

Откровенно говоря переубеждать тебя нет ни времени, ни желания. Так что давай завязывать.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Чего не хватает в C#?
От: WolfHound  
Дата: 25.12.05 09:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Специальная семантика именно для описания переменной? Ну, может быть. Это нужно серьезно обдумать.

VD>В Шарпе переменную можно создать только в виде statment-а, т.е. не expression-а. И к чему приведет изменение этого правила еще неизвестно. Ведь язык это целостная система. Изменение одного аспекта легко может развалить ее.
Описывать переменную в expression не надо. Нужно просто ввести еще одну форму if'а и while'а в которой в место expression будет объявление переменной ссылочного типа.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 14:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Описывать переменную в expression не надо. Нужно просто ввести еще одну форму if'а и while'а в которой в место expression будет объявление переменной ссылочного типа.


Собственно я изначально и предложил это сделать.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 26.12.05 09:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Может лучше тебе выше почитать? Это вообще-то о твоих словах:

VD>

А куда ты перейдешь, если код функции тебе не доступен?...


я говорил о том, что функция отличается от синтаксической конструкции одним фактом — для функции мы можем посмотреть ее исходный код, а для встроенной конструкции языка — нет.
объясни мне наконец, зачем ты приплел сюда джит?

VD>Вопрос был в замене С-шного стиля приведения типов на функциональный. Твой cast<> — это тоже функциональный стиль, только обладающий явной избыточностью.


может быть, начнем еще оверхедами меряться?

VD>Потому что значение конструкции в скобках зависит от ее семантики, а зависимость от семантики означает, что язык не является контексно-свободным. Чтобы язык остался контекстно-свободным были введены эвристики повзволяющие решить проблемы. Вот только если бы чуть исправить граматику, то проблема бы отпала сама собой.


ни один современный императивный язык не является контекстно-свободным. КС может быть только надмножество программ языка, которое нужно сужать с помощью дополнительных проверок. ИМХО, эти дополнительные проверки надо бы выполнять после предварительного парсинга, когда уже есть информация об имеющихся в наличии типах. И никакие неудобоваримые эвристики не понадобятся.

VD>Это как раз плохо, так как усложняет парсер. В данном случае и так приходится заглядывать вперед по самое нехочу. И вообще, это особенность языка, а не парсера. Эвристики прописаны в спецификации.


это усложняет не парсер, а генератор парсеров. Но его можно написать один раз, а потом пользоваться. Без необходимости каждый раз потрясать бубном и приносить в жертву девственного юзера, чтобы грамматика заработала как надо
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[18]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 26.12.05 09:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Зашибись! Ну, то есть если мне нужно обработать событие которое не по моей воле во фрэймворке передает ссылку на object, то я должен наблюдать горы грязи?


почему бы не использовать визитор?
еще лучше, конечно, мультиметоды. Можно и о них заодно помечтать
то же самое, кстати, можно сказать про жуткие конструкции наподобие вот этих:
var if (b = a as B)
    b.A_Method();
else var if (c = a as С)
    c.A_Method();
else 
    throw new MyException(...);
 

5. Ввести у объектов идентификатор типа чтобы были возможно использовать их в switch:
switch (someObj.TypeId)
{
    case typeof(A).TypeId: ... break;
    case typeof(C).TypeId: ... break;
    case typeof(D).TypeId: ... break;
    case typeof(E).TypeId: ... break;
}


VD>То есть вопрос только в скобках? Нет проблем!

VD>
VD>void yield()
VD>{
VD>    yield();
VD>}
VD>


и что ты этим хочешь доказать? что писать yield() вместо yield будет проще и нагляднее?

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


наработался по самое не хочу. Проблему — вижу. Может быть именно потому, что наработался?

Д>>пример операторов неявной конверсии типов — в студию!


VD>Не понял.


ты сказал, что регулярно видишь в коде операторы неявной конверсии типов. Мне захотелось увидеть хотя бы один, который применяется правильно и уместно. Могу я иметь такое желание, правда ведь?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[4]: Чего не хватает в C#?
От: GlebZ Россия  
Дата: 26.12.05 10:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>6. Позволить использовать в switch любые объекты которые реализующие интерфейс IEquatable<T> или оператор "==".

GZ>>Может тогда уж лучше нормальный pattern matching?
VD>Это тут не причем. Одно другому не мешает.
В случае паттерн матчинга — это особо мешать не будет. А строиться программы будут значительно удобней(учитывая что нет установки значений параметров по умолчанию).

GZ>>Эээ. У меня есть подозрение что такое может выполняться только на уровне CLR и при компиляции такого в runtime — JIT просто ляжет.

VD>Наоборот. Такое может выполяняться только на начальных стадиях парсинга в компиляторе C#. Ведь тут говорится об изменении синтаксиса языка. И джит тут совсем не причем. Джит получит скопилированный код.
Maybe.

GZ>>Я бы сюда добавил бы friends на уровне классов. Все таки иногда очень хочется. Только не в сишном варианте.

VD>Может быть. Но тут врзникают проблемы идеологического плана в CLR.
А в чем? Ну допустим объект хочет нарушить свою инкапсуляцию предоставляя права другому объекту(но не наоборот). internal очень часто не хватает. Хочется более гибкого в границах компонента.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Чего не хватает в C#?
От: Joker6413  
Дата: 26.12.05 12:38
Оценка:
Здравствуйте, xvost, Вы писали:

X>Здравствуйте, Кирилл Осенков, Вы писали:


КО>>Извините, если уже было. Просто наболело. Если есть чем поделиться — присоединяйтесь!


X>Лично мне очень не хватает маленького синтаксического сахара — еще одного уровня вложенности. Т.е. хочется чтобы можно было объявлять методы и поля внутри пропертей с видимостью "private", и чтобы к ним никто не имел доступа извне проперти.


X>Наиболее частый юзкейс:



X>
X>public int P
X>{
X>  private int field;
X>  get{return field;}
X>  set {field = value;}
X>}  
X>


X>Цель — чтобы никто не мог даже изнутри класса достучатся до поля минуя сеттер/геттер проперти



Имхо вернее что-то типа этого:


        const string csCurrentUnitIdPropName = "CurrentUnitIdPropName";
        public int CurrentUnitId
        {
            get
            {
                if (ViewState[csCurrentUnitIdPropName] == null)
                {
                    ViewState[csCurrentUnitIdPropName] = 0;
                }

                return (int) ViewState[csCurrentUnitIdPropName];
            }

            set
            {
                ViewState[csCurrentUnitIdPropName] = value;
            }
        }
Re[19]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.05 23:52
Оценка:
Здравствуйте, Дарней, Вы писали:

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


VD>>Зашибись! Ну, то есть если мне нужно обработать событие которое не по моей воле во фрэймворке передает ссылку на object, то я должен наблюдать горы грязи?


Д>почему бы не использовать визитор?


Потому-что это банально долго.

Д>еще лучше, конечно, мультиметоды. Можно и о них заодно помечтать



Против мультиметодов я тоже ничего не имею, но попять же городить кучу методов и раносить логику на них когда мне нужно просто сделать выбор на основании набора объектов — это зачастую перебор.

Д>и что ты этим хочешь доказать? что писать yield() вместо yield будет проще и нагляднее?


Нет. Я хоучу сказать, что апелляции к аргументам вроде "это ключевое слово" не очень то корректны относительно C# 2.0.

Д>наработался по самое не хочу. Проблему — вижу. Может быть именно потому, что наработался?


Вряд ли. Кстати, можно поинтересоваться что в тебе порадило такую ненависть к функциям?

Д>ты сказал, что регулярно видишь в коде операторы неявной конверсии типов. Мне захотелось увидеть хотя бы один, который применяется правильно и уместно. Могу я иметь такое желание, правда ведь?


Они как бы по коду разбросаны. Тебе просто нужно пример реализации оператора?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.05 23:52
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>я говорил о том, что функция отличается от синтаксической конструкции одним фактом — для функции мы можем посмотреть ее исходный код, а для встроенной конструкции языка — нет.


Вот я тебе и говорю. Посмотри исходный код для Sin() из FCL и т.п.

Д>объясни мне наконец, зачем ты приплел сюда джит?


Когда посмотришь, то сам поймешь.

VD>>Вопрос был в замене С-шного стиля приведения типов на функциональный. Твой cast<> — это тоже функциональный стиль, только обладающий явной избыточностью.


Д>может быть, начнем еще оверхедами меряться?




Д>ни один современный императивный язык не является контекстно-свободным. КС может быть только надмножество программ языка, которое нужно сужать с помощью дополнительных проверок. ИМХО, эти дополнительные проверки надо бы выполнять после предварительного парсинга, когда уже есть информация об имеющихся в наличии типах. И никакие неудобоваримые эвристики не понадобятся.


Так и делается. Сначала строется AST, а уж по нему идет семантика. Только вот чтобы распарсить код приведения типов в AST нужно определить приведение ли это типа или нет. Вот в С++ типы распознаются параллельно с парсингом. Это накладывает ограничения вроде того, что все в С++ должно быть объявлено до использования. От сюда необходимость предварительных деклараций и необходимость разбивать класс на декларцию и реализацию. В Шарпе же решили такой фигней не заниматься. Это привело к тому, что в процессе парсинга невозможно точно установить является ли идентификатор типом или нет (да и вообще чем он является). Отсюда должны быть строгие парвила где идентификатор нужно интерпретировать как тип, а где нет. И без эвристик здесь не выйдет. А вот в Дельфи все ОК, так как нет С-ишного приведения типов.

Д>это усложняет не парсер, а генератор парсеров.


Не. Это услажняет парсер и предявляет большие требования к построителю и/или программисту.

Д> Но его можно написать один раз, а потом пользоваться.


Не совсем. Это еще приходится читать. Да и парсинг от этого становится мдленее. А учитывая то, что каждая новая версия Шарпа порождает новые проблемы...
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 27.12.05 02:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Потому-что это банально долго.

VD>Против мультиметодов я тоже ничего не имею, но попять же городить кучу методов и раносить логику на них когда мне нужно просто сделать выбор на основании набора объектов — это зачастую перебор.

это верно. эмуляция мультиметодов через двойную диспетчеризацию требует немало кода
но никто ведь не мешает встроить поддержку в язык?
и вообще, даже в рамках существующего CLI эту проблему можно решить намного удобнее, чем кодированием вручную. Я сейчас как раз над этим работаю

VD>Нет. Я хоучу сказать, что апелляции к аргументам вроде "это ключевое слово" не очень то корректны относительно C# 2.0.


почему — некорректны?

VD>Вряд ли. Кстати, можно поинтересоваться что в тебе порадило такую ненависть к функциям?


ничего не имею против функций, когда они применяются по назначению

VD>Они как бы по коду разбросаны. Тебе просто нужно пример реализации оператора?


мне просто интересно, для чего они там применяются
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[14]: Чего не хватает в C#?
От: Дарней Россия  
Дата: 27.12.05 02:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вот я тебе и говорю. Посмотри исходный код для Sin() из FCL и т.п.


ну хорошо. Для некоторых функций исходный код получить нельзя. Но это не меняет сути самих функций, как внешних сущностей по отношению к языку.

VD>Так и делается. Сначала строется AST, а уж по нему идет семантика. Только вот чтобы распарсить код приведения типов в AST нужно определить приведение ли это типа или нет. Вот в С++ типы распознаются параллельно с парсингом. Это накладывает ограничения вроде того, что все в С++ должно быть объявлено до использования. От сюда необходимость предварительных деклараций и необходимость разбивать класс на декларцию и реализацию. В Шарпе же решили такой фигней не заниматься. Это привело к тому, что в процессе парсинга невозможно точно установить является ли идентификатор типом или нет (да и вообще чем он является). Отсюда должны быть строгие парвила где идентификатор нужно интерпретировать как тип, а где нет. И без эвристик здесь не выйдет. А вот в Дельфи все ОК, так как нет С-ишного приведения типов.


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

VD>Не. Это услажняет парсер и предявляет большие требования к построителю и/или программисту.


если генератор парсеров будет помогать программисту, автоматически решая некоторые неясности в грамматике, почему это должно предъявлять к программисту более высокие требования?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[12]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 27.12.05 04:48
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ты теперь пытаешься отличать глубину копирования, основываясь на наличии слова new.


Правильно ли я понял — ты утверждаешь, что "A a = new A(b)" и "A a = (A)b" это всегда идентичные операции?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Чего не хватает в C#?
От: WolfHound  
Дата: 27.12.05 06:16
Оценка:
Здравствуйте, VladD2, Вы писали:

WH>>Описывать переменную в expression не надо. Нужно просто ввести еще одну форму if'а и while'а в которой в место expression будет объявление переменной ссылочного типа.

VD>Собственно я изначально и предложил это сделать.
Только сделать это не явно те без слова var пуред if'ом ибо оно там ни к чему.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.12.05 07:39
Оценка:
Здравствуйте, adontz, Вы писали:

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


S>>Ты теперь пытаешься отличать глубину копирования, основываясь на наличии слова new.


A>Правильно ли я понял — ты утверждаешь, что "A a = new A(b)" и "A a = (A)b" это всегда идентичные операции?

Нет, неправильно. Я говорю о том, что семантика "A a = new A(b)" и "A a = (A)b" отличается, но как именно она отличается, сказать невозможно без заглядывания в документацию/исходники.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Чего не хватает в C#?
От: GlebZ Россия  
Дата: 27.12.05 11:25
Оценка:
Здравствуйте, IT, Вы писали:

IT>Вот ещё бы чего хотелось. Впрочем, это не C#, а сам фреймворк. Причём сделать это можно за пару минут. Рехтуем класс Activator.

И так не быстро. Если бы такие вещи поддерживались JIT'ом через new — было бы круто. А через Activator — можно написать и свой wrapper.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 27.12.05 12:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

A>>Правильно ли я понял — ты утверждаешь, что "A a = new A(b)" и "A a = (A)b" это всегда идентичные операции?

S>Нет, неправильно. Я говорю о том, что семантика "A a = new A(b)" и "A a = (A)b" отличается, но как именно она отличается, сказать невозможно без заглядывания в документацию/исходники.

А с чём ты тогда споришь и за что минусуешь? Я и не утверждаю, что семантика всегда одинаковая, я о другом говорил — если семантика разная, то сейчас забытый new приводит к ошибке компиляции, а после внедрения предложения Влада будет приводить к компилирущейся программе, которая работает не так.
Если p вероятность того, что человек забывает написать new (на глазок пара процентов), а q вероятность того что семантики конструктора и оператора приведения типа различаются настолько, что замена одного другим менят поведение программы (на глазок 50 на 50), то p*q вероятность трудноуловимых граблей. Если тебе не нравяться мои p и q, то подставь свои, а потом умножь на количество вызов конструкторов вида A(B b) когда есть и преобразование B::operator A(). Получишь оценочное количество граблей. Для справки, сейчас оно равно нулю, потому что не комплируется.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[14]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.05 00:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Нет, неправильно. Я говорю о том, что семантика "A a = new A(b)" и "A a = (A)b" отличается, но как именно она отличается, сказать невозможно без заглядывания в документацию/исходники.


Правильно будет сказать "возможно отличается". А еще правильнее сказать, что синтаксические конструеции ее не поределяют. Важно тут только одно объект типа Б преобразуется в объект типа А. И в этом эти конструкции схожи.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 28.12.05 02:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Правильно будет сказать "возможно отличается".


+1

Только сейчас их нельзя перепутать забыв написать new, а после внедрения твоего предложения будет можно.

А если ты считаешь, что нельзя забыть написать new в выражении конструирования объекта, то и = в операторе == тоже нельзя забыть.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.12.05 04:28
Оценка:
Здравствуйте, adontz, Вы писали:

A>А с чём ты тогда споришь и за что минусуешь? Я и не утверждаю, что семантика всегда одинаковая, я о другом говорил — если семантика разная, то сейчас забытый new приводит к ошибке компиляции, а после внедрения предложения Влада будет приводить к компилирущейся программе, которая работает не так.

A>Если p вероятность того, что человек забывает написать new (на глазок пара процентов), а q вероятность того что семантики конструктора и оператора приведения типа различаются настолько, что замена одного другим менят поведение программы (на глазок 50 на 50), то p*q вероятность трудноуловимых граблей. Если тебе не нравяться мои p и q, то подставь свои, а потом умножь на количество вызов конструкторов вида A(B b) когда есть и преобразование B::operator A(). Получишь оценочное количество граблей. Для справки, сейчас оно равно нулю, потому что не комплируется.
Верное замечание. Значит, в шарп никогда не введут такую возможность. Разве что запрещать компировать класс в том случае, если одновременно определен оператор явной конверсии и соответствующий конструктор. Хотя с учетом неявных преобразований аргумента, крайне сложно будет написать неконфликтующий оператор конверсии.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.12.05 11:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Только сделать это не явно те без слова var пуред if'ом ибо оно там ни к чему.


Незнаю. Пока что мне кажется, что использовать для этого просто if не лучшая идея. Хотя может это догмы...
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.12.05 11:29
Оценка:
Здравствуйте, adontz, Вы писали:

A>Только сейчас их нельзя перепутать забыв написать new, а после внедрения твоего предложения будет можно.


Еще раз. Последний. Путать попросту нечего. Ну, не должно быть у класса одновременно и конструкора преобразующего тип, и явного приведения типов.

A>А если ты считаешь, что нельзя забыть написать new в выражении конструирования объекта, то и = в операторе == тоже нельзя забыть.


У этих операторов очень разная семантика. Учитывая типобезопасность Шарпа ты ничего не забудешь. Это проблема не типобезопасных языков вроде С++.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.12.05 11:29
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Я там ниже предложил более явные варианты ifnull и пр. Реакции не увидел.


А это ничем не отличается от "var if".

V>Потому как грабли не в типобезопасности, а в смешении семантик.


Это терминалогическое жанглирование. Можно сказать и так, и так.

V> Т.е. в C# никак не перепутаешь присвоение для ЛЮБОГО типа (не только ссылочного) со сравнением. Банальная защита от частовстречающейся ошибки "=" вместо "==".


Вообще-то для bool проблем их перепутать нет. Так что все основано на недопустимости неявного приведения к bool. Ты же сам создал такое приведение внеся тем самым грабли.

V>Что за боязнь лишних ключевых слов? В чем проблема? Если они позволяют более кратко описать самые частовстречающиеся сценарии, то они должны быть, ИМХО.


Дык несовместимость с редыдущими версиями языка.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 31.12.05 11:30
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Еще раз. Последний. Путать попросту нечего. Ну, не должно быть у класса одновременно и конструкора преобразующего тип, и явного приведения типов.


Почему? Не может понадобиться или просто запретим?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[18]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.01.06 05:45
Оценка:
Здравствуйте, adontz, Вы писали:

VD>>Еще раз. Последний. Путать попросту нечего. Ну, не должно быть у класса одновременно и конструкора преобразующего тип, и явного приведения типов.


A>Почему? Не может понадобиться или просто запретим?


Не может понадобиться. Точнее не появится при правильном проектровании.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 01.01.06 12:13
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>Почему? Не может понадобиться или просто запретим?

VD>Не может понадобиться. Точнее не появится при правильном проектровании.

То есть всё таки запретим. Ну вотбщем утверждение, что не может понадобиться спорное, да и правильное проектированием не всегда встречается. Жизнь ты многим испортишь, а полезность фичи сомнительна.

P.S. С наступившим!
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[5]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 12:55
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>В случае паттерн матчинга — это особо мешать не будет. А строиться программы будут значительно удобней(учитывая что нет установки значений параметров по умолчанию).


Еще раз. Сопоставление с образцом перпендикулярно наличию у типов константных идентификаторов и возможности обработки в свитче объектов. Я не против него, но и описанные мной фичи хочу иметь.

Что же до сопоставление с образцом, то ему может помешать, то что в C# поддерживается перегрузка функций.


GZ>>>Я бы сюда добавил бы friends на уровне классов. Все таки иногда очень хочется. Только не в сишном варианте.

VD>>Может быть. Но тут врзникают проблемы идеологического плана в CLR.
GZ>А в чем? Ну допустим объект хочет нарушить свою инкапсуляцию предоставляя права другому объекту(но не наоборот). internal очень часто не хватает. Хочется более гибкого в границах компонента.

В том, что защита дотнета — это сбалансированное и сложное решение. И "нарушить свою инкапсуляцию" будет не так то просто не повредив целостность этой системы.

GZ>С уважением, Gleb.


Ты не мог бы засунуть подпись в профайл? Зачем она в каждом сообщении?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 12:55
Оценка:
Здравствуйте, adontz, Вы писали:

A>То есть всё таки запретим.


То есть просто наплюем.

A>P.S. С наступившим!


С наступившим.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, adontz, Вы писали:

A>Это всё правильно, но только для строк. Из приведённого кода ясно видно, что для разных строк хеш гарантированно разный. Далеко не все хеш-функции могут этим похвастаться.


Ром, никто никогда не гарантирует тебе, что у двух объектов хэши разные. В том числе и у строк.

В приведенном АВК коде нет рассчета на разность хэш-кодов. В хэш-таблице лежат целочисленные константы! Именно по ним и идет переход в МСИЛ-ном свитче.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, adontz, Вы писали:

A>А да. Виноват В IL не силён Ну по крайней мере можно надеяться что хеш строки вычисляется по-умному


Я тебе где-то рядом приводил декомпиляцию в C#. Ты ее смело проигнорировал.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 02.01.06 15:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я тебе где-то рядом приводил декомпиляцию в C#. Ты ее смело проигнорировал.


Там баыло вычисление хеша?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[17]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 15:12
Оценка:
Здравствуйте, adontz, Вы писали:

VD>>Я тебе где-то рядом приводил декомпиляцию в C#. Ты ее смело проигнорировал.


A>Там баыло вычисление хеша?


Тут тоже нет.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Чего не хватает в C#?
От: GlebZ Россия  
Дата: 03.01.06 23:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что же до сопоставление с образцом, то ему может помешать, то что в C# поддерживается перегрузка функций.

Не вижу помех. При наличии одной и той же сигнатуры — должна быть такая же ошибка как и обычно.


GZ>>>>Я бы сюда добавил бы friends на уровне классов. Все таки иногда очень хочется. Только не в сишном варианте.

VD>>>Может быть. Но тут врзникают проблемы идеологического плана в CLR.
GZ>>А в чем? Ну допустим объект хочет нарушить свою инкапсуляцию предоставляя права другому объекту(но не наоборот). internal очень часто не хватает. Хочется более гибкого в границах компонента.
VD>В том, что защита дотнета — это сбалансированное и сложное решение. И "нарушить свою инкапсуляцию" будет не так то просто не повредив целостность этой системы.
Сомневаюсь. friend в данном случае — частный случай internal который предоставляет доступ конкретным классам в рамках компонента.

GZ>>С уважением, Gleb.


VD>Ты не мог бы засунуть подпись в профайл?

Ты о профайле RSDN или Janus?
VD>Зачем она в каждом сообщении?
Воспитывает себя и собеседника.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.06 10:57
Оценка:
Здравствуйте, GlebZ, Вы писали:

VD>>Что же до сопоставление с образцом, то ему может помешать, то что в C# поддерживается перегрузка функций.

GZ>Не вижу помех.

А зря. Прегрузка и сопоставление с образцом конфликтуют. Языки с последним обычно не поддерживают пергрузку в том виде в каком это реализуется в языках линейки Паскаль/С++.

GZ> При наличии одной и той же сигнатуры — должна быть такая же ошибка как и обычно.


Усложняется анализ. Появляется куча конфликтов. При наличии пререгрузки сопоставление с образцом может оакзатья недоступен, а ведь это совсем разные механизмы. Перегрузка — это статический полиморфизм, а сопоставление с образцом — это замена if/switch.

GZ>Сомневаюсь. friend в данном случае — частный случай internal который предоставляет доступ конкретным классам в рамках компонента.


Не. internal работает на уровне сборки. В общем, это потребовало бы усложнения CLR. Хотя конечно сделать это возможно.

VD>>Ты не мог бы засунуть подпись в профайл?

GZ>Ты о профайле RSDN или Janus?

РСДН-а. Янус тоже берет данные от туда. Мой слоник лежит именно там.

VD>>Зачем она в каждом сообщении?

GZ>Воспитывает себя и собеседника.

Дык, пусть воспитывает в подписи из профайла. А то каждый раз удалять эту подпись уже задолбало. Да и зачем БД пергружать. Хватит нам оверквотинга.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Чего не хватает в C#?
От: GlebZ Россия  
Дата: 04.01.06 21:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Усложняется анализ. Появляется куча конфликтов. При наличии пререгрузки сопоставление с образцом может оакзатья недоступен, а ведь это совсем разные механизмы. Перегрузка — это статический полиморфизм, а сопоставление с образцом — это замена if/switch.

Maybe

VD>Не. internal работает на уровне сборки. В общем, это потребовало бы усложнения CLR. Хотя конечно сделать это возможно.

Лично для меня — это было бы полезно.

VD>>>Зачем она в каждом сообщении?

GZ>>Воспитывает себя и собеседника.
VD>Дык, пусть воспитывает в подписи из профайла. А то каждый раз удалять эту подпись уже задолбало. Да и зачем БД пергружать. Хватит нам оверквотинга.
Сделал. Хотя иногда подписываясь, переделываю наиболее "наездные" места в менее одиозные. Помогало.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.01.06 13:47
Оценка:
Здравствуйте, GlebZ, Вы писали:

VD>>Дык, пусть воспитывает в подписи из профайла. А то каждый раз удалять эту подпись уже задолбало. Да и зачем БД пергружать. Хватит нам оверквотинга.

GZ>Сделал. Хотя иногда подписываясь, переделываю наиболее "наездные" места в менее одиозные. Помогало.

Большое спасибо!
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Чего не хватает в C#?
От: vdimas Россия  
Дата: 05.01.06 20:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык несовместимость с редыдущими версиями языка.




Прикалываешься все... Особенно на фоне отличий грядущего 3.0 от 1.0
Re[19]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.01.06 23:26
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>Почему? Не может понадобиться или просто запретим?

VD>Не может понадобиться. Точнее не появится при правильном проектровании.

Я уже забыл про сей спор, но вот 5 минут тому наза набрал кое-какой код и меня осенило как же ты был неправ (код поцокан, чтобы была видна суть)

public class SecureStream : IDataStream
{
    #region SecureStream
    
    private IDataStream _dataStreamUnderlying;

    public SecureStream(IDataStream dataStreamUnderlying)
    {
        _dataStreamUnderlying = dataStreamUnderlying;
    }
        
    #endregion
        
    #region IDataStream

    public int Read(byte[] buffer, int indexFrom, int indexTo);
    public int Write(byte[] buffer, int indexFrom, int indexTo);
    public void Close();

    #endregion

}

Имеются как преобразование SecureStream::operator IDataStream() в виде обычного downcast, так и конструктор SecureStream(IDataStream). Думаю это типичный случай для любого вида обёрток. А обёртки сами по себе вообще довольно типичный случай.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[20]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.01.06 04:36
Оценка:
Здравствуйте, adontz, Вы писали:
A>Имеются как преобразование SecureStream::operator IDataStream() в виде обычного downcast, так и конструктор SecureStream(IDataStream). Думаю это типичный случай для любого вида обёрток. А обёртки сами по себе вообще довольно типичный случай.
А где здесь явное приведение типа? Или тебе вдруг захотелось добавить public static explicit operator SecureStream(IDataStream source)?
Напомню, что ты споришь с

Еще раз. Последний. Путать попросту нечего. Ну, не должно быть у класса одновременно и конструкора преобразующего тип, и явного приведения типов.

1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Чего не хватает в C#?
От: adontz Грузия http://adontz.wordpress.com/
Дата: 06.01.06 07:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А где здесь явное приведение типа?


А зачем явное?

S>[q]Еще раз. Последний. Путать попросту нечего. Ну, не должно быть у класса одновременно и конструкора преобразующего тип, и явного приведения типов.



Что-то я не понял. Разве предлагаемый синтаксис T(a) должен работать только я для явного преведения типов? Я думал он должен вообще заменить (T)a
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[22]: Чего не хватает в C#?
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.01.06 14:49
Оценка:
Здравствуйте, adontz, Вы писали:


A>Что-то я не понял. Разве предлагаемый синтаксис T(a) должен работать только я для явного преведения типов? Я думал он должен вообще заменить (T)a

Хм. Для неявного приведения вроде как редко используется явное приведение. Только в случаях устранения неоднозначности при вызове метода. А там можно и оставить легаси способ.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Чего не хватает в C#?
От: pvgoran Россия  
Дата: 07.01.06 04:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А зря. Прегрузка и сопоставление с образцом конфликтуют.


Интересно... А в чем именно конфликт?
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[9]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.01.06 12:07
Оценка:
Здравствуйте, pvgoran, Вы писали:

VD>>А зря. Прегрузка и сопоставление с образцом конфликтуют.


P>Интересно... А в чем именно конфликт?


А ты представь себе, что у тебя есть метод кторый конролирует сопоставление с образом, ну, предположим проверяет не является ли параметр больше 0 и одновременно имеются еще два метода перегруженные по типу:
void Method(long  x){ ... }
void Method(float x){ ... }
void Method(x)
    match x > 0
{ ... }

как компилятор будет выходить из положения? Ведь при этом резко идут все возможности по приведению типов, появляется куча коныликтов и т.п.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Чего не хватает в C#?
От: pvgoran Россия  
Дата: 07.01.06 12:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>А зря. Прегрузка и сопоставление с образцом конфликтуют.


P>>Интересно... А в чем именно конфликт?


VD>А ты представь себе, что у тебя есть метод кторый конролирует сопоставление с образом, ну, предположим проверяет не является ли параметр больше 0 и одновременно имеются еще два метода перегруженные по типу:

VD>
VD>void Method(long  x){ ... }
VD>void Method(float x){ ... }
VD>void Method(x)
VD>    match x > 0
VD>{ ... }
VD>

VD>как компилятор будет выходить из положения? Ведь при этом резко идут все возможности по приведению типов, появляется куча коныликтов и т.п.

Подразумевается язык с выводом типов, так?

Если оператор '<' полиморфный (например как в Haskell — определен для типов класса Ord), то, при отсутствии других ограничений, третья функция будет полиморфной, с тем же ограничением на тип. Первые две будут мономорфными. Для аргументов типа long или float нужно вызвать мономорфную функцию, для аргументов других типов (поддерживающих оператор '<') — полиморфную. Все, конфликты разрулены?

В том же C++ уже есть шаблоны со специализацией, есть и конкретные правила выбора функции — и все при наличии приведений типов и т.п.. Так что пока что проблема не прояснилась.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[11]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.01.06 12:54
Оценка:
Здравствуйте, pvgoran, Вы писали:

P>Если оператор '<' полиморфный (например как в Haskell — определен для типов класса Ord), то, при отсутствии других ограничений, третья функция будет полиморфной, с тем же ограничением на тип. Первые две будут мономорфными. Для аргументов типа long или float нужно вызвать мономорфную функцию, для аргументов других типов (поддерживающих оператор '<') — полиморфную. Все, конфликты разрулены?


Почти, так как сопоставление с образцом работать не будет. Ты ведь поставил перегрузке более высокий приоритет. По жизни тут получается конфликт. Правда можно и аргументу третьей фукнции дать конкретный тип (например, int), но боюсь, что в итоге будет стольк случаностей, что мало не покажется.

P>В том же C++ уже есть шаблоны со специализацией, есть и конкретные правила выбора функции — и все при наличии приведений типов и т.п.. Так что пока что проблема не прояснилась.


Ага. То в нем нет сопсотавления с образцом. Кстати, правила выбора функций в С++ далеки от идеала. Меня, вот всегда озадачивало, что вот такое:
struct A
{
    void Method(int x) { }
};

struct B public A
{
    void Method(char x) { }
};

приводит к перекрытию метода. Ведь по сути это разные методы, так как у них разные типы аргмунтов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Чего не хватает в C#?
От: pvgoran Россия  
Дата: 08.01.06 08:22
Оценка:
Здравствуйте, VladD2, Вы писали:

P>>Если оператор '<' полиморфный (например как в Haskell — определен для типов класса Ord), то, при отсутствии других ограничений, третья функция будет полиморфной, с тем же ограничением на тип. Первые две будут мономорфными. Для аргументов типа long или float нужно вызвать мономорфную функцию, для аргументов других типов (поддерживающих оператор '<') — полиморфную. Все, конфликты разрулены?


VD>Почти, так как сопоставление с образцом работать не будет.


Почему не будет? Будет. Хотя перегрузка будет вносить определенные коррективы/искажения.

VD> Ты ведь поставил перегрузке более высокий приоритет. По жизни тут получается конфликт.


В чем конфликт? Именно в необходимости иметь приоритеты?

Вообще, лично я пока что вижу больше пользы от сопоставления с образцом не для простых типов (int и т.п.) "по условию" (x>0), а для вариантных (вроде так) типов — т.е. для сложных типов вида

Tree a = Leaf a | Branch (Tree a) (Tree a)


(для которых значением может быть либо Leaf, либо Branch).

Если есть функция, принимающая значения такого сложного типа

size Leaf x       = 1
size Branch t1 t2 = size t1 + size t2


то я не вижу никаких проблем в том, чтобы перегрузить ее для какого-нибудь другого типа. Правда, если сделать такую перегрузку, станет невозможным вывод типов без дополнительных "подсказок" со стороны программиста...

P>>В том же C++ уже есть шаблоны со специализацией, есть и конкретные правила выбора функции — и все при наличии приведений типов и т.п.. Так что пока что проблема не прояснилась.


VD>Ага. То в нем нет сопсотавления с образцом.


Зато есть статический полиморфизм, который, как и в случае сопоставления с образцом, вынуждает расставлять приоритеты.

VD> Кстати, правила выбора функций в С++ далеки от идеала.


Далеки — не далеки, но они есть... Хотя, конечно, весьма непростые.

VD> Меня, вот всегда озадачивало, что вот такое:

VD>
VD>struct A
VD>{
VD>    void Method(int x) { }
VD>};

VD>struct B public A
VD>{
VD>    void Method(char x) { }
VD>};
VD>

VD>приводит к перекрытию метода. Ведь по сути это разные методы, так как у них разные типы аргмунтов.

Ну, даже есть считать это недостатком — это непринципиально; так, мелкая фича. И к тому же применимо это только при наследовании — т.е. к делу (перегрузка & сопоставление & статический полиморфизм) относится довольно-таки косвенно.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[13]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.01.06 13:17
Оценка:
Здравствуйте, pvgoran, Вы писали:

P>Вообще, лично я пока что вижу больше пользы от сопоставления с образцом не для простых типов (int и т.п.) "по условию" (x>0), а для вариантных (вроде так) типов — т.е. для сложных типов вида


P>
P>Tree a = Leaf a | Branch (Tree a) (Tree a)
P>


P>(для которых значением может быть либо Leaf, либо Branch).


P>Если есть функция, принимающая значения такого сложного типа


P>
P>size Leaf x       = 1
P>size Branch t1 t2 = size t1 + size t2
P>


А зачем нужны такие извращения? Шарп — это ООЯ. Нафига нужно воодить еще один вид описания полиморфных методов? Я и так могу объявить виртуальный метод и переопределить его в классах.

Сопоставление с образцом в данном случае в общем-то не причем. Это запаскированный под него полиморфизм.

Я не спорю, что сопоставление с образцом было бы полезно. Но обычное. Та самая замена if-ам.

А что до полиморфизма, так как я уже говорил, для языка типа Шарпа куда полезнее возможность использовать объкты в switch-е. Это бы позволило бы и аналог сопоставление с образцом по типам реализовать.
P>Ну, даже есть считать это недостатком — это непринципиально; так, мелкая фича. И к тому же применимо это только при наследовании — т.е. к делу (перегрузка & сопоставление & статический полиморфизм) относится довольно-таки косвенно.

Не, батенька. Если ты говоришь о полиморфном сопоставление с образцом, то наследование и перегрузка тут первые конфликтующие сторны.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Чего не хватает в C#?
От: pvgoran Россия  
Дата: 09.01.06 05:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А зачем нужны такие извращения? Шарп — это ООЯ. Нафига нужно воодить еще один вид описания полиморфных методов? Я и так могу объявить виртуальный метод и переопределить его в классах.


А причем здесь C#? Я так понял, ты имел в виду принципиальную несовместимость перегрузки и pattern matching'а, безотносительно языка. Я был неправ?

VD>Сопоставление с образцом в данном случае в общем-то не причем. Это запаскированный под него полиморфизм.


Ну, на это можно по-разному смотреть... Можно сказать, что на C# вариантные типы можно эмулировать полиморфизмом; а можно сказать, что вариантные типы в языках, их поддерживающих — это ограниченная замена динамического (времени исполнения) полиморфизма.

VD>Я не спорю, что сопоставление с образцом было бы полезно. Но обычное. Та самая замена if-ам.


Ну, не знаю... По-моему, if'ы (или их замену) сопоставлением с образцом назвать можно только с большой натяжкой. Где в этом (и аналогичных) определениях образец?

void Method(x)
    match x > 0
{ ... }


По сравнению с "нормальным" pattern matching'ом, в котором есть образец и назначение имен компонентам образца, ценность "if-сопоставления" выглядит не особенно большой.

VD> [ специфичные для C# аспекты пропущены ]
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[16]: Чего не хватает в C#?
От: pvgoran Россия  
Дата: 10.01.06 07:00
Оценка:
Здравствуйте, VladD2, Вы писали:

P>>А причем здесь C#?


VD>Понятно. Ты голову подними и название темы прочти.


(Ты мог бы выразиться и корректнее.)

Твой тезис, который меня изначально заинтересовал, был сформулирован так:

Прегрузка и сопоставление с образцом конфликтуют. Языки с последним обычно не поддерживают пергрузку в том виде в каком это реализуется в языках линейки Паскаль/С++.


Здесь явно говорится о разных языках (не только о C#), в частности, о "языках, которые поддерживают сопоставление с образцом".

P>>Ну, не знаю... По-моему, if'ы (или их замену) сопоставлением с образцом назвать можно только с большой натяжкой. Где в этом (и аналогичных) определениях образец?


VD>if-ы не аналогичны. if-ы выполняют ту же роль. Ветвления выполнения по некоторому условию.


Не понял, к чему это... Ну ладно.

И все же — где образец в рассматриваемом тобой варианте pattern matching'а?

P>>По сравнению с "нормальным" pattern matching'ом, в котором есть образец и назначение имен компонентам образца, ценность "if-сопоставления" выглядит не особенно большой.


VD>Я не понимаю что такое "нормальным pattern matching".


Я уже приводил примеры с деревом. Ниже попробую пояснить еще раз.

VD> Мы уже вроде бы договорились, что полиморфизм отделяем.


Что значит "отделяем"? И какой именно полиморфизм имеется в виду (ну там, ad hoc/parametric, статический/динамический)?

VD>Вот и попробуй объяснить, что же такое в этом случае "нормальнымый pattern matching"?


Попробую. (Хотя пока и непонятно, что значит твое "в этом случае".) Сугубо на примере C++-подобных языков.

Определения (pattern — ключевое слово):

class Shape
    {
public:
    pattern virtual bool EmptyShape();
    
    // ...
    };
    
class Triangle : public Shape
    {
public:
    pattern bool RegularTriangle(Point &pt1, Point &pt2, Point &pt3);
    pattern bool DegenerateTriangle(Point &pt1, Point &pt2, Point &pt3);
    
    // ...
    };
    
class Rectangle : public Shape
    {
public:
    pattern bool Rectangle(Point &ptBottomLeft, Point &ptTopRight);
    
    // ...
    };
    
class Circle : public Shape
    {
    // ...
    };


Соответственно, использование:

void doSomething(Shape &shape)
    {
    match(shape)
        {
        pattern EmptyShape()
            {
            // do nothing
            }
        pattern RegularTriangle(Point pt1, Point pt2, Point pt3)
            {
            doSomethingUnusual(pt1);
            }
        pattern DegenerateTriangle(Point, Point, Point)
          {
            throw std::exception("Degenerate triangles are not supported");
            }
        pattern Rectangle(Point ptBottomLeft, Point ptTopRight)
            {
            doSomethingWeird(ptBottomLeft - ptTopRight);
            }
        pattern (Circle &circle) // встроенный - что-то вроде dynamic_cast
            {
            doSomethingWithCircle(circle);
            }
        default
            {
            throw std::exception("Shape not supported");
            }
        }
    }
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[17]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.01.06 11:35
Оценка:
Здравствуйте, pvgoran, Вы писали:

P>(Ты мог бы выразиться и корректнее.)


Боюсь это могло показаться грубым.

P>Твой тезис, который меня изначально заинтересовал, был сформулирован так:


P>

P>Прегрузка и сопоставление с образцом конфликтуют. Языки с последним обычно не поддерживают пергрузку в том виде в каком это реализуется в языках линейки Паскаль/С++.


P>Здесь явно говорится о разных языках (не только о C#), в частности, о "языках, которые поддерживают сопоставление с образцом".


Конфликт есть везеде. Понятно, что в некоторых случаях его можно разрешить выбрав приоритеты и т.п. Но мы то говорим о языке с уже устаявшимися приоритетами! Всовывая в него что папало очень легко привести язык к несбалансированности.

VD>>if-ы не аналогичны. if-ы выполняют ту же роль. Ветвления выполнения по некоторому условию.


P>Не понял, к чему это... Ну ладно.


Ты сказал, что я сказал, что "сопоставление с образцом аналогично if-ам". Я же уточнил, что не аналогичны, а выполняют ту же функцию "вервление логики программы".

P>И все же — где образец в рассматриваемом тобой варианте pattern matching'а?


Сразу за процедурой. Это даже больше чем образец. Можно было бы конечно ограничиться отдельными условиями "образцом". Но это было бы менее гибко. А в итогде все равно компилятор подставил бы нечто вроде if-а.

P>Я уже приводил примеры с деревом. Ниже попробую пояснить еще раз.


Пример с деревом был банальным динамическим или статическим полиморфизмом (в зависимости от того известен ли тип переменной на этапе компиляции). Это уже есть в C#.

VD>> Мы уже вроде бы договорились, что полиморфизм отделяем.


P>Что значит "отделяем"? И какой именно полиморфизм имеется в виду (ну там, ad hoc/parametric, статический/динамический)?


Откровенно говоря до меня так и не дошло значение термина "ad hoc". Был бы признателен если бы ты на пальцах объяснил.

Что же касается твоего вопроса, то любой. Любой полиморфизм. Как я уже сказал раньше, полиморфизм уже поддерживается ООЯ. Максимум чем бы я расширил C# — это добавлением поддержики мультиметодов.

P>Попробую. (Хотя пока и непонятно, что значит твое "в этом случае".) Сугубо на примере C++-подобных языков.


P>Определения (pattern — ключевое слово):


P>
P>class Shape
P>    {
P>public:
P>    pattern virtual bool EmptyShape();
    
P>    // ...
P>    };
    
P>class Triangle : public Shape
P>    {
P>public:
P>    pattern bool RegularTriangle(Point &pt1, Point &pt2, Point &pt3);
P>    pattern bool DegenerateTriangle(Point &pt1, Point &pt2, Point &pt3);
    
P>    // ...
P>    };
    
P>class Rectangle : public Shape
P>    {
P>public:
P>    pattern bool Rectangle(Point &ptBottomLeft, Point &ptTopRight);
    
P>    // ...
P>    };
    
P>class Circle : public Shape
P>    {
P>    // ...
P>    };
P>


P>Соответственно, использование:


P>
P>void doSomething(Shape &shape)
P>    {
P>    match(shape)
P>        {
P>        pattern EmptyShape()
P>            {
P>            // do nothing
P>            }
P>        pattern RegularTriangle(Point pt1, Point pt2, Point pt3)
P>            {
P>            doSomethingUnusual(pt1);
P>            }
P>        pattern DegenerateTriangle(Point, Point, Point)
P>          {
P>            throw std::exception("Degenerate triangles are not supported");
P>            }
P>        pattern Rectangle(Point ptBottomLeft, Point ptTopRight)
P>            {
P>            doSomethingWeird(ptBottomLeft - ptTopRight);
P>            }
P>        pattern (Circle &circle) // встроенный - что-то вроде dynamic_cast
P>            {
P>            doSomethingWithCircle(circle);
P>            }
P>        default
P>            {
P>            throw std::exception("Shape not supported");
P>            }
P>        }
P>    }
P>


И какой у этого принцип действия? Что-то я не понимаю.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Чего не хватает в C#?
От: Fert Россия  
Дата: 10.01.06 13:36
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

Попутный вопросик, есть ли возможность моделировать подобные расширения C#?
Учить Кнут'ом и Вирт'ом.
Re: Чего не хватает в C#?
От: Udjine  
Дата: 10.01.06 17:11
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

КО>делегатов, указывающих на свойства (property delegates)


Не могли бы Вы как-нибудь поконкретнее обьяснить, как использовать делегаты "указывающие на свойства"? Просто интересно очень
Re[2]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.01.06 20:35
Оценка:
Здравствуйте, Udjine, Вы писали:

U>Не могли бы Вы как-нибудь поконкретнее обьяснить, как использовать делегаты "указывающие на свойства"? Просто интересно очень


Разбирайся: http://rsdn.ru/Forum/Message.aspx?mid=1560494&amp;only=1
Автор: VladD2
Дата: 24.12.05
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Чего не хватает в C#?
От: pvgoran Россия  
Дата: 20.01.06 06:31
Оценка:
(Наконец добрался до Janus'а...)

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

P>>Твой тезис, который меня изначально заинтересовал, был сформулирован так:


P>>

P>>Прегрузка и сопоставление с образцом конфликтуют. Языки с последним обычно не поддерживают пергрузку в том виде в каком это реализуется в языках линейки Паскаль/С++.


P>>Здесь явно говорится о разных языках (не только о C#), в частности, о "языках, которые поддерживают сопоставление с образцом".


VD>Конфликт есть везеде. Понятно, что в некоторых случаях его можно разрешить выбрав приоритеты и т.п. Но мы то говорим о языке с уже устаявшимися приоритетами! Всовывая в него что папало очень легко привести язык к несбалансированности.


Т.е. проблема не в каком-то теоретическом конфликте между pattern matching'ом и перегрузкой, а в том, что введение pattern matching'а в C# (и подобные ему языки) может привести к несбалансированности?

VD>Ты сказал, что я сказал, что "сопоставление с образцом аналогично if-ам". Я же уточнил, что не аналогичны, а выполняют ту же функцию "вервление логики программы".


"Ветвление логики программы" — это очень распространенная функция, ее выполняют многие программные конструкции, различные по виду, сложности, удобстве и т.п., так что в высказывании "сопоставление с образцом выполняет ту же функцию, что и if" информации не так уж много.

В данном случае важно, что в твоем примере pattern matching выполняет ветвление по явно прописанному программистом условию (и он аналогичен if'у именно в этом), а в ФЯ проверка явно прописанного условия — это лишь одна, и не самая важная, возможность pattern matching'а.

P>>И все же — где образец в рассматриваемом тобой варианте pattern matching'а?


VD>Сразу за процедурой.


А конкретнее — что является образцом? Идентификатор x?

VD> Это даже больше чем образец. Можно было бы конечно ограничиться отдельными условиями "образцом".


Непонятно...

VD> Но это было бы менее гибко. А в итогде все равно компилятор подставил бы нечто вроде if-а.


P>>Я уже приводил примеры с деревом. Ниже попробую пояснить еще раз.


VD>Пример с деревом был банальным динамическим или статическим полиморфизмом (в зависимости от того известен ли тип переменной на этапе компиляции). Это уже есть в C#.


Значения Leaf x и Branch t1 t2 из моего примера — одного типа, так что про полиморфизм тут говорить вроде неуместно...

В C++-подобных языках такой код можно было бы переписать с использованием полиморфизма (да и то, в общем случае понадобился бы какой-нибудь Visitor). Однако, если pattern matching внести внутри функции

someFunction (t::Tree a) =
    -- какой-то код
    -- ...
    -- где-то внутри:
    case t of
        Leaf x -> 1
        Branch t1 t2 -> 321


ситуация станет хуже: придется выносить "ветки" case'а в функции.

VD>>> Мы уже вроде бы договорились, что полиморфизм отделяем.


P>>Что значит "отделяем"? И какой именно полиморфизм имеется в виду (ну там, ad hoc/parametric, статический/динамический)?


VD>Откровенно говоря до меня так и не дошло значение термина "ad hoc". Был бы признателен если бы ты на пальцах объяснил.


Моя (несколько вольная) интерпретация того, что написано в Википедии, такова: ad hoc полиморфизм — это способность программной системы (или, можно сказать, языка программирования) один и тот же вызов [метода] понимать/интерпретировать/исполнять по-разному, в зависимости от типов участвующих в вызове объектов/значений, причем эти разные интерпретации явно задаются программистом.

В контексте C++-подобных языков это сводится к виртуальным вызовам (в run-time) и перегрузке функций/операций (в compile-time).

VD>Что же касается твоего вопроса, то любой. Любой полиморфизм.


Какой там полиморфизм — это, в общем-то, дело десятое. Мне просто был совершенно непонятен смысл выражения "полиморфизм отделяем".

VD>И какой у этого принцип действия? Что-то я не понимаю.


Принцип примерно такой: выбирается первый pattern, для которого в классе, которому принадлежит аргумент match, есть pattern-метод, совпадающий по имени и по сигнатуре и возвращающий true. При этом переменные (например, pt1, pt2, pt3 во втором pattern'е конструкции match) получают значения, записанные pattern-методом в его параметрами-ссылки.

Класс аргумента match определяется, естественно, динамически.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[19]: Чего не хватает в C#?
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.01.06 09:50
Оценка:
Здравствуйте, pvgoran, Вы писали:

P>Т.е. проблема не в каком-то теоретическом конфликте между pattern matching'ом и перегрузкой, а в том, что введение pattern matching'а в C# (и подобные ему языки) может привести к несбалансированности?


Можно сказать и так. Обрати внимание, что языки с Шапроподобной организацией зачастую не выносят паттерн-матчинг на уровень функций, а обходятся специальными операторами.

VD>>Ты сказал, что я сказал, что "сопоставление с образцом аналогично if-ам". Я же уточнил, что не аналогичны, а выполняют ту же функцию "вервление логики программы".


P>"Ветвление логики программы" — это очень распространенная функция, ее выполняют многие программные конструкции, различные по виду, сложности, удобстве и т.п., так что в высказывании "сопоставление с образцом выполняет ту же функцию, что и if" информации не так уж много.


Много, не много. Не надо приписывать мне слов которые я не говорил.

P>В данном случае важно, что в твоем примере pattern matching выполняет ветвление по явно прописанному программистом условию (и он аналогичен if'у именно в этом), а в ФЯ проверка явно прописанного условия — это лишь одна, и не самая важная, возможность pattern matching'а.


Давай так. Ты мне приведешь код использующий паттерн-матчинг (ПМ) (с объяснением), а я перепешу его на if-ах. Если не смогу, то соглашусь, с тобой, что ПМ дает языку новые возможности, а не является приятным синтаксическим сахаром.

P>А конкретнее — что является образцом? Идентификатор x?


В первую очередь. "> ..." можешь рассматривать как защищающее условие.

VD>> Это даже больше чем образец. Можно было бы конечно ограничиться отдельными условиями "образцом".


P>Непонятно...


В большистве систем ПМ кроме собственно образца еще имееются защищающие условия. Без них ПМ или является заменой виртуальным функциям, или провекам на ==.

P>Значения Leaf x и Branch t1 t2 из моего примера — одного типа, так что про полиморфизм тут говорить вроде неуместно...


Это не так. Они виртуально одного типа. Компилятор скрывает от тебы особенности реализации. А реально создается иерархия наследования и получаются два разных типа.

Я согласен, что концепция алгебраических типов красива и иногда может существенно сжать код. Но чудес не бывает. И на физически это ни чем не отличается от банального наследования в сочетании с витруальными методамии или проверками в стиле
if (a is SomeType)
    ...


P>В C++-подобных языках такой код можно было бы переписать с использованием полиморфизма (да и то, в общем случае понадобился бы какой-нибудь Visitor). Однако, если pattern matching внести внутри функции


В С++ есть dynamic_cast<>() позволяющий, в сочетани с if-ами, точно так же "матчить" по типам. Ну, а "матчить" по значениям можно с помощью оператора == и &&/||.

P>
P>someFunction (t::Tree a) =
P>    -- какой-то код
P>    -- ...
P>    -- где-то внутри:
P>    case t of
P>        Leaf x -> 1
P>        Branch t1 t2 -> 321
P>


P>ситуация станет хуже: придется выносить "ветки" case'а в функции.


См. выше.
Leaf leaf = dynamic_cast<Leaf>(node);

if (leaf != null)
    ...

Что до Посететелей, то это паттерн хорош в некоторых случаях. И ПМ ему не замена. Хотя снова оговорюсь, что это неплохой сахар. Вот только не во все языки он может бесшевно вписаться на уровне функций. А на уровне оператора — без проблем. Только это будет скорее разновидность switch-я для С++.

P>Моя (несколько вольная) интерпретация того, что написано в Википедии, такова: ad hoc полиморфизм — это способность программной системы (или, можно сказать, языка программирования) один и тот же вызов [метода] понимать/интерпретировать/исполнять по-разному, в зависимости от типов участвующих в вызове объектов/значений, причем эти разные интерпретации явно задаются программистом.


Опять же очень расплывчато. Я и в Википедии нихрена не понял в свое времи.

P>В контексте C++-подобных языков это сводится к виртуальным вызовам (в run-time) и перегрузке функций/операций (в compile-time).

а
Тогда может проще называть это динамическим полиморфизмом?

P>Какой там полиморфизм — это, в общем-то, дело десятое. Мне просто был совершенно непонятен смысл выражения "полиморфизм отделяем".


Смысл очень простой. Я уже устал повторять, что ПМ на самом деле не одна технология, а две. Он 1) позволяет отделить объекты по типам, что есть полиморфизм (точнее ветвление управления на основании полиморфизма), 2) отделить объекты по значениям, что есть просто ветвление управления. Первое в ООЯ реализуется наследованием плюс виртуальные функции или операторы проверки типа. А второе просто if-ами.

VD>>И какой у этого принцип действия? Что-то я не понимаю.


P>Принцип примерно такой: выбирается первый pattern, для которого в классе, которому принадлежит аргумент match, есть pattern-метод, совпадающий по имени и по сигнатуре и возвращающий true. При этом переменные (например, pt1, pt2, pt3 во втором pattern'е конструкции match) получают значения, записанные pattern-методом в его параметрами-ссылки.


P>Класс аргумента match определяется, естественно, динамически.


Мне кажется ты погряз в интерпретации которую пытаются навязать приверженцы ФЯ и из-за этого не можешь увидить простой сути.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 21.03.07 16:20
Оценка:
Товарищи, свершилось!

В Оркасе свойства можно будет для краткости записывать так:

public class Person
{
    public string FirstName { get; set; }
    public string LastName  { get; set; }        
    public int    Age       { get; set; }
}


Компилятор автоматически сгенерирует приватное поле.

здесь
Re[2]: Чего не хватает в C#?
От: Кирилл Осенков Украина
Дата: 21.03.07 16:24
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

КО>В Оркасе свойства можно будет для краткости записывать так:


Виноват, баян. АВК уже писал об этом здесь
Автор: AndrewVK
Дата: 15.03.07
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.