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

AVK>Ну хорошо, давай твою идею, так сказать разовьем. private,protected,internal мешает программисту?

Нет. Мешает private по умолчанию. Логичнее было бы по умолчанию делать protected.

AVK>Проверка на возврат значение мешает?

Иногда. Можно добавить прагму отключающую ее и ключ компилятора.

AVK> Проверка на инициализацию мешает?

Нет. Причем никогда. Если она делается программистом, компилятор это отслеживает и все пучечком.

AVK> GC мешает?

Иногда. Но если его малость доработать, то и отключать не надо будет (как в предыдущем случае).

AVK>Необходимость обязательной имплементации объявленных интерфейсов мешает?

Мне нет. Делигаты эту проблему снимают очень красиво.

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

Давай.

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

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

Ну, это тоже перебор. Ну, еще спец опцию отменяющую (хотя это тоже...). Но вот по умолчанию стоило бы сделать protected. Тогда бы столько private по забычивости.

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

Ну, на асме (или повыпендривавшись с указателями) это и так можно. Но ооочень геморройно и дышит наладом, так как при сдвифке переменной или метода пойдут AV.

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

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

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

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

AVK>если нормально написанная либа


Во-во. Только практика показывает, что MS и Борланд нормально с первого раза писать не умеют. В Дельфи хоть все исходники были...

Здравствуйте Mishka<T>, Вы писали:

MT>...второй — разрешить, но повесить красную табличку: "если вы используете это, то мы не несём никакой ответсвенности". Для профи второй вариант явно лучше.

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

Была бы моя воля я вообще дефолты для private запретил бы. Пусть все думают, что делают!

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

AVK>А почему не сделать так чтобы он без них обошелся.

А ты знаешь как?

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

Кто же заставляет отказыватся от чего-то? Дефолты надо поправить, только и всего.

Здравствуйте Mishka<T>, Вы писали:

MT>Нато профи и деньги платят, чтоб дурака не валял А так, известный же закон — за всё надо платить. С другой стороны можно сделать так, чтоб язык поддерживал два уровня: Professional и Expert.

Нодо добавить прагму:

#pragma trust me... knowing i'm do...

Или как там по англицки?

Ну, и после этой прагмы творим что хотим.

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

AVK>Профи как раз не будет пытаться похачить чужой код без исходников. Ибо время — деньги. А то что переписать код проще чем разобраться в чужом (а у нас еще и исходников нет) — давно известный факт.

Ну, попробуй переписать тот же WinForms...

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

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

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

Так унаследуй свой класс... добавь все что считаешь нужным... напиши доку... и выкладывай на rsdn.

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

VD>>Во-первых, агрегация круче.
IVNС>В чем же преимущества ?

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

Не совсем так. Множественное наследование вещь статическая. Агрегация динамическая. Но наверное статическая реализация тоже нужно. Это ведь скорее всего окажется эффективнее. Да и можно будет реализовывать невиртуальные функции, т.е. реализация как таковая не интерфейса, а просто некой фичи.

IVNС>Так что, наш спор, наверное, не по существу

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

IVNС>Чем тебе не нравится множ насл ?

Ошибками, неоднозначностями, тем что убивает идею одного корня и тем самым делает не эффективным всю компонентную сущьность CLR.

IVNС>А вообще никто тебя и не заставляет такое делать Подобные трюки не являются необходимостью, но иногда полезны. Ничто не должно ограничивать полет фантазии программиста!

А я вообще хочу избежав трюков иметь удобный и эффективный язык.

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

Я бы остановился на шаблонах. Без дефолтных параметров функций пока можно пережить.

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

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

Эмуляция будет не полной. Доступно будет как раз только подключение реализаций. Так как их можно переключать или на vtbl или на раскрутку наследования в одиночное.

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

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

IVNС>Все равно, компилер придется доделывать.

То компилятор, а то всю CLR.

IVNС>Ты начинаешь чувствовать, что предлагаешь всего лишь _нестандартный_вариант_ множ наследования ???

Нет. Это его безопастный подвид.

VD>>Что геморройно? Что некрасиво?
IVNС>Я имею в виду, что если не изменять компилятор, придется лепить кучу лишнего, некрасивого кода, а это никуда не годится.

Так речь и шла об изменении компилятора.

IVNС>А если уж изменять компилятор, нужно уже реализовать _стандартное_, обкатанное еще в прошлом тысячелетии множ. наследование !!!

Большинство светлых умов сходится во мнении, что МН в С++ было проволом. Я так не считаю, но считаю, что если заменить его на подключение реалзиаци, то довольны будут 90% людей и можно будет избежать много геморроя. Кстати, в MC++ МН доступно и сейчас. Просто его нельзя применять для создания CLR-совместимого кода.

IVNС>Обычная агрегация — то, что было до кома Класс-агрегат содержит в себе переменные, содержащие экземпляры других классов, и не более того

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

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

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

Дык, у нас вроде были свои люди гдето там.

А>arraylist — все-таки список

Реализован он на обычном массиве, но object-ов. От того и тормозит.

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

Это ерунда по стравнению с боксингом/анбоксингом который происходит при добавлении/извлечении туда/от туда value-нипов.

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

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

А>Заметь одну вещь: копирование производится только тогда, когда винда не может увеличить размер блока памяти при оставлении его непрерывным.

Да винда может виделить память размером в 4 кила. И не фига больше. Реалоки всегда создают новый массив и копируют туда содержимое старого.

А>А умные реализации эффективных динамических массивов

А кто тебе говорит о "умных реализациях". Тот же ArrayList использует опережащющее занятие памяти. Вот тольо он с object-ами оперирует и из-за этого тормозит по страшному. А без шаблонов, ну или хотябы на худой конец #includ-а сделать реализации для каждого типа слишком сложно.

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

Да нафиг там не нужно знать ничего просто новое занчение нужно получать умножениме старого на два. 100 лет назад проверенный метод... Но это так к слову.

А>С удалением — хуже, но и тут есть трюки, чтоб копирование участков памяти производить не сразу, а при выполнении опред. условий. Также приходится создавать спец. итераторы.
А>Какая выгода от такого массива ?

Так нефига заниматься фигней. Шринк массивам вооще делать не нужно. Проще полностью очистеть и заполнить по новой.

А>Если много удалений — конечно, лучше аррэйлист, тем более, что адреса элементов там кешируются (нет поиска при обращении к элементу, ф смотрел в исходниках)

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

А>В-третьих, System.Array реализован с использованием ComArray, который, естественно, создается динамически.

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

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

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

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

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

VD>Вот еще бы компилятор при компиляции выдавал бы окошко с текстом: "А ты хорошо подумал?!".

А толку то — ты всерьез полагаешь что влазя в приватные поля чужой библиотеки, или наследуясь и подсовывая затем свой класс без ее исходных кодов ты можешь предусмотреть все возможные глюки?

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

VD>Нет. Мешает private по умолчанию. Логичнее было бы по умолчанию делать protected.
Самое интересное — в разных языках доступ по умолчанию разный. В Дельфи это паблик, в джаве интернал, в c# прайват, в С++ зависит от того class это или struct. На эту тему целое исследование написать можно.

AVK>>Проверка на возврат значение мешает?
VD>Иногда. Можно добавить прагму отключающую ее и ключ компилятора.
Зато дисциплинирует. Тут самое главное не перегнуть палку. А то вон в джаве компилятор принудительно заставляет обработать все возможные исключения. Когда пишешь первые прикидки необходимость обрабатывать все возможные ошибки просто бесит. Хотя точно не забудешь их обработать.

AVK>> GC мешает?
VD>Иногда. Но если его малость доработать, то и отключать не надо будет (как в предыдущем случае).
Я думаю дорабатывать придется совсем не малость.

AVK>>Необходимость обязательной имплементации объявленных интерфейсов мешает?
VD>Мне нет. Делигаты эту проблему снимают очень красиво.
Это как? Ты имеешь ввиду то что интерфейс можно составить из делегатов и просто не присваивать им значение?

AVK>>Дальше продолжать?
VD>Давай.
Зачем?

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

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

VD>Кто же заставляет отказыватся от чего-то? Дефолты надо поправить, только и всего.
Да нет, тут народ предлагал ввести модификаторы отмены прайват. А дефолтовый модификатор конечно поправить можно.

Здравствуйте VladD2,

VD>Нодо добавить прагму:
VD>#pragma trust me... knowing i'm do...

#pragma Take that fucking compiler away from my clumsy hands

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

VD>Дык, у нас вроде были свои люди гдето там. :)
Они так же не шевелятся.

VD>Это ерунда по стравнению с боксингом/анбоксингом который происходит при добавлении/извлечении туда/от туда value-нипов.
Да, но тут ничего не поделаешь, пока нет темплейтов.

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


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

VD>Да нафиг там не нужно знать ничего просто новое занчение нужно получать умножениме старого на два. 100 лет назад проверенный метод... Но это так к слову.

Да не, на 2 не всегда хорошо умножать. Зависит от характера использования массива. Если, конечно, хочешь_экономить память. Проверенно практикой — для экономии памяти лучше добавлять блоками динамического размера.

VD>Шринк массивам вооще делать не нужно. Проще полностью очистеть и заполнить по новой.

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

А>>В-третьих, System.Array реализован с использованием ComArray, который, естественно, создается динамически.
VD>Ты полностью неправ. Возьми исходники и убедить в своеей не правоте сам.

Смотрю.Не полностью.
Блин, ну и реализация у этого ArrayList ...
System.Array работает с использованием класса COMArrayInfo, написанного на с++. Поскольку ArrayList использует System.Array, разумно было бы предположить, что ресайз они реализовали именно в COMArrayInfo. Но ни хрена ! Они при каждой вставке тупо вызывают Array.Copy ... Ну, M$, 5 баллов. Список с кэшированием элементов, блин :maniac:
Какого они это чудо вообще списком назвали- непонятно. :(((

Как-нить портирую свой ATL-овский динамический массив и список на .НЕТ. Это будет правильно.

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

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

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

VD>Вот еще бы компилятор при компиляции выдавал бы окошко с текстом: "А ты хорошо подумал?!". :)

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

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

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

VD>Так унаследуй свой класс... добавь все что считаешь нужным... напиши доку... и выкладывай на rsdn. ;)

Дык уже есть. А доку можно сгенерить по комментам ///
Вообще, этот враппер удобства добавляет, так что смысл, есть, наверное.
А вообще, лучше бы просто изменить стандартный DateTime, и пользоваться им. Если бы микрософт еще бы слушал, что ему говорят !

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

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

VD>Не совсем так. Множественное наследование вещь статическая. Агрегация динамическая. Но наверное статическая реализация тоже нужно. Это ведь скорее всего окажется эффективнее. Да и можно будет реализовывать невиртуальные функции, т.е. реализация как таковая не интерфейса, а просто некой фичи.

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


IVNС>>Чем тебе не нравится множ насл ?

VD>Ошибками, неоднозначностями, тем что убивает идею одного корня и тем самым делает не эффективным всю компонентную сущьность CLR.
Весь смысл в том, наследование долно производиться от замкнутых классов, реализующих _разную_ функциональность. Тут все зависит от продуманности иерархии классов. Например, WTL. Как удобно там, например, получить диалог с ресайзом контролов, хостингом эктивиксов, DDX-ом, наследуя класс диалога от CDialogResize, CAxDialogImpl, CWinDataExchange. Абсолютно безглючно, удобно, а, главное, изначально не замешано в одном базовом классе. Добавляешь только то, что нужно.
Вот если ты еще отнаследуешься от CDialogImpl, который реализует то же, что CAxDialogImpl — получится черт_и_что. Ну дык кто в таком случае виноват ? :)

Причем в данном случае динамическая имплементация АБСОЛЮТНО не нужна.
И компонентная сущность CLR вовсе не пострадает, если думать, что пишешь. Тем более, что в динамической реализации нехуже напутать можно.
Так что, множ наследование нужно _однозначно_

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

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

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

VD>Нет. Иначе придется написать свою CLR. А это неподемная задача даже если весе посетители сайта будут заниматься ее решением. :( Да и нет большой необходимости. Подключение реализций меня бы устроило.

Переписывать CLR глупо — тяжело и ненужно, и обратно-несовместимо. Все, что в CRL имеется, достаточно, чтоб реализовать то, что мы хотим.

IVNС>>Ты начинаешь чувствовать, что предлагаешь всего лишь _нестандартный_вариант_ множ наследования ??? :)

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

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

AVK>А толку то — ты всерьез полагаешь что влазя в приватные поля чужой библиотеки, или наследуясь и подсовывая затем свой класс без ее исходных кодов ты можешь предусмотреть все возможные глюки?

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