Здравствуйте AndrewVK, Вы писали:
AVK>>>Видишь ли какое дело — дата хранится в переменной типа double и в любом случае будет меняться целиком. Ты мне объясни — чем написание собственного wrapper лучше приведенного мною способа?
А>>В long, если точнее. AVK>Да нет, именно в double. В целой части хранится дата, в дробной время.
Да нет, именно в long. В тиках. Хотя это не принципиально :) Только не надо меня бить :) :maniac:
А>> А смысл во враппере такой, что, кроме того, что по-отдельности работаю с полями, добавил во враппер методы для работы с датами — назв месяцев на нескольких языках, AVK>И это тоже можно сделать стандартными средствами. Причем на таком количестве языков что тебе ни за что самому не сделать. А>> переходы на следующие/предыдущие дни/месяца/года (хотя можно писать d = AddMonths(1), удобнее d.NextMonth()), AVK>Ни чуть не удобнее. И и мелочь все это. Не на том внимание заостряешь.
Из мелочей складывается полная картина. Если какая-то логика используется вне класса неоднократно, имеет смысл поместить ее в класс
А>>sealed здесь только помешал. AVK>Тут я тебе могу объяснить к чему sealed. Фреймворк очень сильно завязан на DateTime. И во многих случаях если ты подсунешь своего наследника это приведет к глюкам. К примеру в ADO.NET осуществляется автоматическое преобразование стандартных типов к sql типам. Представь что будет если ты впихнешь свой DateTime.
Если криво его написать, конечно. А так — все отлично конвертится.
В лучшем случае она просто выкинет исключение. А в худшем она сериализует твой объект и запихает его в блоб. И ты долго будешь глюки вылавливать. AVK>Это только один пример. Таких моментов в фреймворке масса. Поэтому все стандартные типы объявлены как sealed. Если же очень приспичило свой DateTime — используй агрегацию и реализуй IConvertible.
Да я так и сделал.
Задача решена — УРА ! — землекопа полтора !
Re[23]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
AVK>Вот как раз пользование private членами и затруднит переход на новую версию, ибо я имею полное право вобще прайват-член прибить.
Тут ты абсолютно прав !
Блин, ну что я тут основы ООП рассказываю. Вы специально издеваетесь, либо мы друг друга просто не понимаем.
AVK>Вовсе не издеваюсь. Мы ведь не просто так тут динаму крутим, а обсуждаем, что нужно для нового компилятора.
Если что-то закрыто преднамеренно, это сделано явно не просто так-это и ежу понятно. То, что новые ключевые слова нарушают все устои оопа и увеличивают вероятность глюка — факт.
Так что, если делать выводы — обойдемся без возможности отмены sealed, и, тем более, всего остального.
Оценки за ответы уже могу выставить :)
Задача решена — УРА ! — землекопа полтора !
Re[19]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
DG>>А оплачивать кто все это будет? И время откуда брать? DG>>Так берешь/покупаешь чужую реализацию, не много ее расковыриваешь, делаешь пару хелперов, несколько нашлепок на чужие классы и работаешь, потихоньку заменяя чужой код на свой или оставляя чужой, если он "достаточно хороший". AVK>О как — достаточно хороший. Так не бывает — либо хороший, либо плохой.
"Достаточно хороший"(good enough) — это не моя концепция, это концепция почти всей западной программиской тусовки. Если код/программа удовлетворяет мои 80% потребностей, оставляя 20% остальных не решенными, то это "good enough".
Нельзя же тот же Word, назвать, ни хорошим, ни плохим, он просто "good enough".
AVK>Если вы будете отменять модификаторы то такой код становится крайне плохим. Сейчас эта либа работает, потом очередная версия что то внутри себя меняет и твоя прога начинает глючить по черному, причем ошибки сыпятся внутри чужого кода (который без исходников).
Все-таки новые версии либ выходят не каждый день, а раз так в год. И я уж как-нибудь разбирусь раз в год, что надо сделать чтобы перейти на новую либу, или решу, что не надо переходить, и так уже все работает.
Инкапсуляции в ООП-е это палка о двух концах, она очень сильно мешает делать, если пользоваться терминами БД, "не заплананированные запросы", т.е. те вещи, которые разработчик либы не предусмотрел.
Нельзя сделать "вертикальную" оптимизацию, например, групповую инициализацию, групповые операции.
struct A
{
private void Method ()
{
Lock();
ChangeGlobalResource();
Unlock();
}
};
//будет только так
foreach (A a in list)
{
a.Method();
}
//А хотелось бы:
Lock();
foreach(A a in list)
{
a.MethodWithoutLock();
}
Unlock();
Re[20]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
DG>>Так главное-то не txt/html/chm, а хорошая структуризация материала, в MSDN-е я нашел через поиск что-то похожее на то, что я ищу, нажал locate и наслаждаюсь топиками, близкими к моей проблеме. AVK>Ты знаешь, лично я поиском пользуюсь крайне редко. Обычно знаю где что лежит.
Это возможно только при совпадении двух вещей: малая заинтересованность новыми(неизвестными еще) вещами и опять же, хорошей структуризации хелпа.
DG>>А том же Man-е/VB-хелпе/stl-хелпе, если я не знаю конкретно, что искать, то и не найду, т.к. это просто плоский хелп, никак не структурированный. AVK>Но ведь этими плоскими хелпами весь мир не ограничивается. Чем тебе не нравится хелп Дельфи? Или Java?
После MSDN хелп Delphi мне очень не понравился, теперь я в Builder-е/Delphi пользуюсь их хелпом, только если надо прочитать, что делает данная функция данного класса, если то же самое можно посмотреть в MSDN, то я пользуюсь MSDN-ом.
На Java-е я писал только небольшие проекты, поэтому за их Хелп ничего не скажу.
В MSDN-е для каждой темы есть разделы, "About/introduction", "Using", "Reference", остальные хелпы ограничиваются в основном только частью Reference.
Re[25]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Mishka<T>, Вы писали:
MT>>Не горячись MT>>Просто ООП — это не панацея. Вопрос в том, что если писать язык только для профессионалов, то можно сделать такие изменения в языке, если думать о том, что чайники тоже захотят пользоваться языком, то есть только два пути: первый — запретить им делать то, что делать в большинстве случаев не нужно, второй — разрешить, но повесить красную табличку: "если вы используете это, то мы не несём никакой ответсвенности". Для профи второй вариант явно лучше.
AVK>Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.
Но это уже его проблемы, и он на это сознательно шел, и ему без этого было не обойтись.
А так получается все пользователи подводятся под одну гребенку, прямо коммунизм какой-то, в самой жесткой форме его проявления (либо ты с нами, либо одно из двух).
Re[25]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
AVK>Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.
Нато профи и деньги платят, чтоб дурака не валял А так, известный же закон — за всё надо платить. С другой стороны можно сделать так, чтоб язык поддерживал два уровня: Professional и Expert.
P.S. Кстати, вспомнилось: если в С++ переменная объявлена как private, то это не означает, что её можно менять только изнутри класса. Достаточно выдать её адрес и вся ОО-эпопея закончиться.
Re[17]: Отсутствие множ. наследования и тэмплэйтов на CS
IVNС>>Просто нужно добавить ключевое слово, отменяющее действие другого. Например, злосчастного sealed. А использовать ли unsealed, или нет — личное дело. Так было бы гибче. AVK>Не, это блин маразм какой то получается. Один классы закрывает, а другой с упорством их обратно разрешает. Нафига тогда вобще sealed если его можно отменить?
Да сделать вобще наследование от sealed в виде error который в warning можно превратиь через опции компилятора. Если у него не более глубокие корни и он не произрастает от IL. Кому надо тот отключит ошибки.
AVK>Не, не понимаю я этого маниакального стремления расковыривать что то чужое. Проще все переписать.
Помнится когдато я давным давно я писал прогу на CBuilder (Delphi), это была не коробочная комерческая прога, а можно сказать для для временного использования (да на CBuilder только такие и пишут), но очень была нужна.
Так вот надо было конвертировать изображения в jpg и сохранять. В той версии VCL jpg можно было читать с помощью какого то недокументированного класса но отконвертировать в jpg не было возможности так как все нужные методы были private. Я долго тыркался ища обходные пути, а потом совершил "преступление" в *.h файлах библиотеки убрал private. И готов бы был ... :maniac: если бы мне кто-то сказал тогда что этого делать нельзя. Ну очень надо было быстро все сделать.
И мне было наплевать у кого там были руки кривые или склероз( забыли private убрать) или хотели как лучше- заботились чтобы я на глюки не напоролся. Я сэкономил кучу времени, не писать же самому конвертер jpg, когда он на диске лежит.
Под .NET все более серьезно в двоичных файлах так просто private не снимишь.
Re[15]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте IVaNС, Вы писали:
IVNС>Да нет, именно в long. В тиках. Хотя это не принципиально Только не надо меня бить
Да, здесь я наврал
AVK>>Тут я тебе могу объяснить к чему sealed. Фреймворк очень сильно завязан на DateTime. И во многих случаях если ты подсунешь своего наследника это приведет к глюкам. К примеру в ADO.NET осуществляется автоматическое преобразование стандартных типов к sql типам. Представь что будет если ты впихнешь свой DateTime.
IVNС>Если криво его написать, конечно. А так — все отлично конвертится.
Да не напишешь ты прямо просто потому что не будеш точно знать как и где он используется.
AVK>>Это только один пример. Таких моментов в фреймворке масса. Поэтому все стандартные типы объявлены как sealed. Если же очень приспичило свой DateTime — используй агрегацию и реализуй IConvertible. IVNС>Да я так и сделал.
Ну вот и молодец. Хотя я думаю что это излишне. Все что ты перечислил можно было сделать и без этого. И уж тем более без парсинга строки.
Здравствуйте DarkGray, Вы писали:
DG>Все-таки новые версии либ выходят не каждый день, а раз так в год. И я уж как-нибудь разбирусь раз в год, что надо сделать чтобы перейти на новую либу, или решу, что не надо переходить, и так уже все работает.
Тут ты совсем не прав. Мне вон к примеру апдейты 1Совских конфигураций чуть ли не каждую неделю сыпются. Ребята изначально не подумали что обновлять придется, а теперь каждое обновление, из-за того что часть конфигурации ручками писана, превращается в такой гемморой.
DG>Нельзя сделать "вертикальную" оптимизацию, например, групповую инициализацию, групповые операции.
Таки можно. Но это тема уже совсем другого разговора.
Здравствуйте DarkGray, Вы писали:
DG>После MSDN хелп Delphi мне очень не понравился, теперь я в Builder-е/Delphi пользуюсь их хелпом, только если надо прочитать, что делает данная функция данного класса, если то же самое можно посмотреть в MSDN, то я пользуюсь MSDN-ом.
А ты знаешь что хелп по платформе не Борландом писан а просто взят у MS? Так что претензии к MS.
DG>В MSDN-е для каждой темы есть разделы, "About/introduction", "Using", "Reference", остальные хелпы ограничиваются в основном только частью Reference.
Не все.
MT>Нато профи и деньги платят, чтоб дурака не валял :))) А так, известный же закон — за всё надо платить. С другой стороны можно сделать так, чтоб язык поддерживал два уровня: Professional и Expert.
Я не встал на сторону нашего оппонента AndrewVK, в чем-то он прав, в чем-то остальные, но, я думаю, сначала надо бы решить более важные проблемы, чем закрытость классов. Я думаю, к этому надо будет вернуться, когда реализуем темплейты, дефолтные параметры и наследование.
Задача решена — УРА ! — землекопа полтора !
Re[26]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте DarkGray, Вы писали:
AVK>>Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.
DG>Но это уже его проблемы, и он на это сознательно шел, и ему без этого было не обойтись.
А почему не сделать так чтобы он без них обошелся. Я думаю отмена модификаторов принесет больше вреда даже для профи. Не надо обольщатся тем что сможешь предусмотреть все нюансы внтренних алгоритмов чужой библиотеки без исходников. Это практически невозможно.
DG>А так получается все пользователи подводятся под одну гребенку, прямо коммунизм какой-то, в самой жесткой форме его проявления (либо ты с нами, либо одно из двух).
Просто акцент в языках вроде C# или Java переносится немножко на другое.
Здравствуйте Mishka<T>, Вы писали:
MT>Здравствуйте AndrewVK, Вы писали:
AVK>>Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.
MT>Нато профи и деньги платят, чтоб дурака не валял А так, известный же закон — за всё надо платить. С другой стороны можно сделать так, чтоб язык поддерживал два уровня: Professional и Expert.
Профи как раз не будет пытаться похачить чужой код без исходников. Ибо время — деньги. А то что переписать код проще чем разобраться в чужом (а у нас еще и исходников нет) — давно известный факт.
Здравствуйте Silver_s, Вы писали:
SS>Да сделать вобще наследование от sealed в виде error который в warning можно превратиь через опции компилятора. Если у него не более глубокие корни и он не произрастает от IL. Кому надо тот отключит ошибки.
Да неважно как это реализовать. Я пытаюсь доказать что отключение sealed принесет больше вреда чем пользы. Даже наикрутейшему профи.
SS>Под .NET все более серьезно в двоичных файлах так просто private не снимишь.
Ну если ну очень хочется то можно вызвать через рефлекшен, выставив в конфиге соотв. права.
Здравствуйте AndrewVK, Вы писали:
AVK>Ну так sealed как раз и делает виртуальные функции статическими.
Да? А что по твоему будет если этот метод был виртуальным в трех подклассах, а в четвертом его пометили как sealed? Что же если я приведу указатель к базовому классу и вызову метод, то виртуальность испарится и вызовется метод базового класса?
VD>>Думаю, эту пролему обойти можно. Именно потому что они виндовые. Вскгда можно забраться на системный уровень и сделать все как нужно. AVK>Не, писать нативный код это уже не то. Нехочу.
А ты что хочешь запускать WinForm-ный код на платформах отличных от Windows? А тогда о чем речь. Или ты имеешь убожество вроде Swing-а или платформно-зависимый код облаченный в обертку. Я вично не вижу проблем в том, что в библиотеках будет зашит этот код. Зато результат на порядки лучше.
VD>>Ну, а почему не сделали? Думаю они пакт с разработчиками компонентов (вроде Infragistoс) заключили. Те не пишут ОС, а MC делает недоделанные кривые компонетнты. AVK>Чем мне в свое время джава понравилась, так это тем что там возможна стандартизация сторонних библиотек. Не люблю сторонних вещей. Как показывает опыт еще по Дельфи 99.9% их весьма посредственного качества.
Ты хоть эти контролы видел? Тебе и в жизни не удастся их написать (или только этим и будеш заниматься), и Sun с MS тоже никогда подобного качества продуков не выпустят. Ява еще даже под стол пешком не ходила, а куча команд клепала VBX-ы отменного качества. Ты сталкивался с самопалами, которые действительно низкого качества. Хотя вот глянь, менюшки с табами для нет: http://www.dotnetmagic.com . Тоже самопал, но давольно высокого качества и с исходниками. Если в этом проекте не использовался бы Win32 API то их качество было бы куда ниже. Как минимум все сильно тормозило бы.
VD>>А приват и вовсе сделан по умолчанию. Один налпит другой уже ничего не исправит. Была бы моя воля я по умолчанию протектед поставил. AVK>Приват по умолчанию правильно. А под кривые руки язык затачивать не стоит.
Очень даже стоит. Их слишко много.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте VladD2, Вы писали:
AVK>>Ну так sealed как раз и делает виртуальные функции статическими. VD>Да? А что по твоему будет если этот метод был виртуальным в трех подклассах, а в четвертом его пометили как sealed? Что же если я приведу указатель к базовому классу и вызову метод, то виртуальность испарится и вызовется метод базового класса?
Не, не так. Если где то в коде я явно обращусь к sealed классу то виртуальный вызов будет заменен на статический.
VD>А ты что хочешь запускать WinForm-ный код на платформах отличных от Windows?
Думаю это пока нереально.
VD> А тогда о чем речь. Или ты имеешь убожество вроде Swing-а
В каком плане? В плане архитектуры он на порядок лучше WF. В плане быстродействия еще неизвестно с какой скоростью будут работать компоненты на этом тормозном GDI+.
VD> или платформно-зависимый код облаченный в обертку. Я вично не вижу проблем в том, что в библиотеках будет зашит этот код. Зато результат на порядки лучше.
Влад, давай не будем по новой.
VD>Очень даже стоит. Их слишко много.
Вот как раз невозможность отмены sealed и есть заточка под кривые руки. Чтобы по этим рукам надавать когда они лезут куда не следует.
Здравствуйте AndrewVK, Вы писали:
AVK>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться.
Вот еще бы компилятор при компиляции выдавал бы окошко с текстом: "А ты хорошо подумал?!".
AVK>Так что все претензии не к языку, а к писателю библиотеки.
Я бы даже сказал, к создателям библиотек. Но от этого не лугче.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
AVK>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно...
Нееее это намного лучше private. Я вон по своему опыту сужу... на сэйлед я плевался раза два, а на private все его жизнть. Так что можно сказаь, что в некотором смысле sealed является обвинительным актом к private.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Только не надо меня бить 
