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

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

А>>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.
AVK>А как же его методы AddXXX?

Это-то есть. Но хотелось типа такого:
DateTime d;
d.Day = 1;
d.Year = 2002;

А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.

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

SS>>>obj.Method(param);
SS>>>[/ccode]
А>>Так не получится — не скомпиляется.
SS>obj.Method(param); — Я имел ввиду, если поддержку на уровне языка сделать.

А смысл ? Тогда придется вводить ключевое слово, помечающее класс, типа dynamic, отключающее проверки на этапе компиляции


А>> Но вот типа такого — реально:
А>>obj.Methods["Method"](param);

SS>Да наверное можно сделать класс оболочку более менее юзабельную не меняя языка, если еще использовать передачу переменного числа параметров

А>>Так вперед, в чем проблема ? Я уже давно примерно такое експлуатирую. Компилятор для этого не нужно менять :)
А>>Достаточно написать класс, который расковыривает в реатайме любой тип.

SS> :( Жалко в библиотеке нет такого класса, каждый теперь будет пользоваться самоделками.

Можно сообча создать хорошую библиотеку, выложить ее на рсдэне, чтобы все пользовались. Наработки уже есть :)

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

VD>Здравствуйте IVaNС, Вы писали:
VD>Вообще-то это реализовано. Я, напримен, пароль каждый раз не заполняю. Слышал, что такая проблема есть при использовании RSDN Desktop, но вроде он пока не доступен открыто. :???: Так, что общайся с IT сам.

Не, никакого десктопа я не юзаю. Оби,свяжусь с ним как-нить.

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

VD>>Здравствуйте IVaNС, Вы писали:
VD>>Вообще-то это реализовано. Я, напримен, пароль каждый раз не заполняю. Слышал, что такая проблема есть при использовании RSDN Desktop, но вроде он пока не доступен открыто. Так, что общайся с IT сам.

IVNС>Не, никакого десктопа я не юзаю. Оби,свяжусь с ним как-нить.
А ты cookies разрешил принимать browser'у.

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

VD>Во-первых, агрегация круче.

В чем же преимущества ?
Я согласен, что иногда динамическая имплементация может быть полезна. Но ! Во-первых, это несколько другая фича, чем множ. наследование, во-вторых, то, что ты предлагаешь, реализуется в компиляторе как частный случай множественного наследования.
Так что, наш спор, наверное, не по существу :)

Чем тебе не нравится множ насл ? Геморрой может возникнуть, когда наследуешься от нескольких классов, имеющих общих предков. Но и тут — объяви себе базовый класс виртуальным — и чики-пуки :)
А вообще никто тебя и не заставляет такое делать :) Подобные трюки не являются необходимостью, но иногда полезны. Ничто не должно ограничивать полет фантазии программиста !

VD>Думаю агрегации и шаблонов будет достаточно.

Начать с чего-то надо. Хотя бы с шаблонов и дефолтных параметров функций !!!

VD>К тому же, множественное наследование не поддерживается CLR-ом.

не поддерживается CLR-ом, но эмулируется с проблемами, но однозначно.

VD>Реальное МН видимо так и останется только в С++
Это от нас зависит ! :)

А>>По-моему, это тупиковый путь. во-первых, отсутствуют проверки на этапе компиляции.
VD>Это ж почему? На этапе компиляции будет проверяться, что агрегируемый класс реализует интерфейс. Этого более чем достаточно.
Все равно, компилер придется доделывать. Ты начинаешь чувствовать, что предлагаешь всего лишь _нестандартный_вариант_ множ наследования ??? :)

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

VD>Задача реализуемая причем реализуемая в рамках сегодняшнего MSIL-а и CLR-а (по крайней мере мне так кажется).

Да, теоретически это возможно.

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

А>> Это жутко геморройно и некрасиво, а ведь наша задача — получить красивую реализацию !

VD>Что геморройно? Что некрасиво?
Я имею в виду, что если не изменять компилятор, придется лепить кучу лишнего, некрасивого кода, а это никуда не годится. А если уж изменять компилятор, нужно уже реализовать _стандартное_, обкатанное еще в прошлом тысячелетии множ. наследование !!!

А>>Уж лучше использовать обычную агрегацию, так хоть, напремер, не вызовешь метод, которого нет :) — не скомпиляется.

VD>Оооочень интересно, что ты понимаешь под "обычной агрегацией"?
Обычная агрегация — то, что было до кома :) Класс-агрегат содержит в себе переменные, содержащие экземпляры других классов, и не более того :)))

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

VD>После того как о шаблонах заговорили в Sun, я думаю, что у MS просто не будет выбора.

Они даже читать не будут :( Мой приятель заботает в фирме-подписчике МСДН. Он несколько раз высказывал M$ конструктивные предложения, на которые они благополучно наплевали.

А>>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН.

VD>Ну, это ерунда... приводишь его к double, а там обычные арефметические операции. К тому же здесь речь шла бы о банальном расширении путем наследования.

Да, расширении. Вроде, обычное применение наследования :) А приводить каждый раз к доубель-неудобно. Я написал враппер, который непосредственно приводится к датетиме.

А>>Или вот обычные массивы. Чтобы добавить/удалить элементик, приходится использовать нетипизированный и тормозной ArrayList

VD>Вот об этом и речь. Только, я бы сформулировал так: Динамические массивы доступны только для общего класса object, что рпиводит к тормозам при использовании value-типов и невозможности проверок на стадии компиляции из-за ненужного здесь полиморфизма.

Хорошо это более правильно, с дополнением: arraylist — все-таки список, и работает медленнее, и, к тому же, при приобразовании в массив производится ненужное поэлементное копирование.

А>>, а потом конвертить его обратно в System.Array. Куда это годится ? Почему они забыли про обычный realloc() ?

VD>Потому, что в природе не существует алгоритмов realloc-а. При realloc-е просто занимается новый массив, данные копируются, а старый освобождается. Такой realloc я и сам за пять минут сворганю. Только он будет еще более медленный чем ArrayList (при условии частого изменения размера массива).

Заметь одну вещь: копирование производится только тогда, когда винда не может увеличить размер блока памяти при оставлении его непрерывным. А умные реализации эффективных динамических массивов — дело хитрое, но разрешимое. Например, такая: выделяешь динамически массив с запасом. При его заполнении проверяется свободное место, и при достижении % заполненности этот массив ресайзится, добавляя блок пустых элементов. Если примерно знать число элементов и интенсивность добавления, производительность получается очень высокой. С удалением — хуже, но и тут есть трюки, чтоб копирование участков памяти производить не сразу, а при выполнении опред. условий. Также приходится создавать спец. итераторы.
Какая выгода от такого массива ? Во-первых, если тебе не нужно добавлять/убирать элементы, то производительность ТАКАЯ ЖЕ, как у обычного массива. Во-вторых, во многих задачах требуется добавление элементов, а удаление вообще не используется. Если много удалений — конечно, лучше аррэйлист, тем более, что адреса элементов там кешируются (нет поиска при обращении к элементу, ф смотрел в исходниках)
В-третьих, System.Array реализован с использованием ComArray, который, естественно, создается динамически.
Так что ты согласен, что разумно было бы сделать такой массив системным ?

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

SS>Здравствуйте IVaNС, Вы писали:

VD>>>Здравствуйте IVaNС, Вы писали:
VD>>>Вообще-то это реализовано. Я, напримен, пароль каждый раз не заполняю. Слышал, что такая проблема есть при использовании RSDN Desktop, но вроде он пока не доступен открыто. :???: Так, что общайся с IT сам.

IVNС>>Не, никакого десктопа я не юзаю. Оби,свяжусь с ним как-нить.
SS>А ты cookies разрешил принимать browser'у.

Ясное дело, стоит на аксепт олл кукиз.

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

IVNС>Эт точно. Хотя мсдн на высоте, лучше миксософта док никто не пишет !
Скажем так — ты не совсем прав.

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

IVNС>Глюки- не глюки — это одно, а вот такие нехорошие ограничения — другое. Если я хочу наследоваться, зачем мне это запрещать ?
Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться. Так что все претензии не к языку, а к писателю библиотеки.

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

А>>>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.
AVK>>А как же его методы AddXXX?

IVNС>Это-то есть. Но хотелось типа такого:
IVNС>DateTime d;
IVNС>d.Day = 1;
IVNС>d.Year = 2002;

IVNС>А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.
И здесь ты не до конца разобрался

DateTime Constructor (Int32, Int32, Int32)

Initializes a new instance of the DateTime structure to the specified year, month, and day.

[Serializable]
public DateTime(
   int year,
   int month,
   int day
);

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

IVNС>Можно сообча создать хорошую библиотеку, выложить ее на рсдэне, чтобы все пользовались. Наработки уже есть :)
Я давно предлагал организовать проект вроде RXLib на Дельфи. Уж больно многого не хватает.

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


А>Если много удалений — конечно, лучше аррэйлист
Если много удалений лучше написать свой связанный список. Быстрее будет раз в 10.

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

IVNС>>А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.
AVK>И здесь ты не до конца разобрался
AVK>[ccode]
AVK>DateTime Constructor (Int32, Int32, Int32)

Да нет, я до конца разобрался, ты не понял, что я хочу сказать :) Что такое конструктор, я вроде как знаю. Я имел в виду чтоб можно было устанавливать Day, Year, Month _по отдельности_.

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

AVK>Здравствуйте IVaNС, Вы писали:

IVNС>>Глюки- не глюки — это одно, а вот такие нехорошие ограничения — другое. Если я хочу наследоваться, зачем мне это запрещать ?
AVK>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться. Так что все претензии не к языку, а к писателю библиотеки.

Именно к языку, поскольку это позволяет ограничивать программиста !

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

AVK>Здравствуйте IVaNС, Вы писали:

IVNС>>Эт точно. Хотя мсдн на высоте, лучше миксософта док никто не пишет !
AVK>Скажем так — ты не совсем прав.
Почему ? Как по информативности, так и по удобству микрософт впереди. Если ты видел, с переходом на новый стандарт hxi/hxs, им удалось на 3 копмакта уместить то, что раньше было на 5 :) А апрельском 2002 они вообще напихали, что только могли :)

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

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

IVNС>>>А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.
AVK>>И здесь ты не до конца разобрался
AVK>>

AVK>>DateTime Constructor (Int32, Int32, Int32)

IVNС>Да нет, я до конца разобрался, ты не понял, что я хочу сказать Что такое конструктор, я вроде как знаю. Я имел в виду чтоб можно было устанавливать Day, Year, Month _по отдельности_.
Ты специально издеваешся?

 DateTime data1 = ...;
 DateTime data2 = new DateTime(1,date1.Month,date1.Year-1);

И никаких строковых парсеров не надо

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

AVK>>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться. Так что все претензии не к языку, а к писателю библиотеки.

IVNС>Именно к языку, поскольку это позволяет ограничивать программиста !
Ну хорошо, давай твою идею, так сказать разовьем. private,protected,internal мешает программисту? Мешает. Убиваем нафик. Проверка на возврат значение мешает? Проверка на инициализацию мешает? GC мешает? Необходимость обязательной имплементации объявленных интерфейсов мешает? Мешает. Удаляем.

Дальше продолжать?

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

А>Почему ? Как по информативности, так и по удобству микрософт впереди.
Впереди планеты всей? А много ли ты видел не MS документации?

А> Если ты видел, с переходом на новый стандарт hxi/hxs, им удалось на 3 копмакта уместить то, что раньше было на 5 А апрельском 2002 они вообще напихали, что только могли
На начхать на формат документации. Главное содержимое. А содерживое MS'овской документации иногда хромает. Я тут где то месяц назад кида пример из доки. Мне удалось уменьшить его раза так в три, при увеличении его понятности.

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

AVK>Здравствуйте IVaNС, Вы писали:

AVK>>>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться. Так что все претензии не к языку, а к писателю библиотеки.

IVNС>>Именно к языку, поскольку это позволяет ограничивать программиста !
AVK>Ну хорошо, давай твою идею, так сказать разовьем. private,protected,internal мешает программисту? Мешает. Убиваем нафик. Проверка на возврат значение мешает? Проверка на инициализацию мешает? GC мешает? Необходимость обязательной имплементации объявленных интерфейсов мешает? Мешает. Удаляем.

Все-таки лучше было сделать protected & private (особенно private) не жесткими ограничениями, а просто предупреждениями, т.к. я еще не встречал ни одного класса, у которого нельзя было немного расширить функциональность.

Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу.

Тоже самое можно сделать и с остальными вещами, т.е. если программись явно написал, что он хочет извратнутся, то пусть извращается.

Что-то такое, синтаксис, конечно, можно сделать более удобным

class A
{
private void Method ();
};

A.<public>Method(); //в этом случае, я беру на себя все проблемы по использованию protected Method-а

//или
class B:
  public A
{
  void Method ()
  {
    A.<public>Method();
  }
};

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

DG>Все-таки лучше было сделать protected & private (особенно private) не жесткими ограничениями, а просто предупреждениями, т.к. я еще не встречал ни одного класса, у которого нельзя было немного расширить функциональность.

DG>Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу.
Лично я считаю что то что я могу полагаться что никто снаружи не доступится к классу это очень хорошо. А сделать возможность доступа к закрытым полям не так то просто. Очень многое в фреймворке на это заточено. К примеру тот же ремоутинг — в прокси включаются только публичные поля. Вызвать private метод нельзя просто потому что он физически отсутствует в метаданных. И и т.д.