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

ГВ>>> А ещё лучше — объясни, почему приняты те или иные решения. В лес посылать мы все тут умеем.
AVK>>Это не лес. Я тебе привел конкретный факт — ToString() в реальном приложении применяется очень широко, следовательно твои выводы о ненужности ToString() не верны.
ГВ>Ошибка. Снова апеллируешь к коллективу.

Не к коллективу, а к своей собственной практике.

ГВ> "Применяется широко" вовсе не означает, что "нужен в общем базовом объекте". Разницу сечёшь?

Применяется широко означает что не вносит каких то проблем. Разницу сечешь?

ГВ>>>Возможно. История, вроде, знавала такие приколы. В IT-индустрии вообще, что ни день, то новое помешательство.
AVK>>С верой спорить бессмысленно.
ГВ>Угу. С любой. С верой в миллион леммингов — тоже.

А я в них и не верю, я верю в то что код лично мне писать на дотнете проще, нежели на С++ или Дельфи, в том числе и благодаря тому что у любого объекта есть виртуальный ToString()

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

ГВ>Ну, поздравляю тебя с первым разом. На самом деле апеллировать к чему-либо, принятому "везде" имеет смысл только тогда, когда целью спора является нахождение того или иного компромисса с общепринятой практикой. Если уж мы о принципах, то никаких апелляций к "общепринятости".

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

Что же касается опеляции к чужому мнению, то это совершенно нормальное явление. Особенно когда речь идет о предпочтениях.

ГВ>Апелляции к "коллективу", к "массе", к чему-либо "общепринятому" и просто ко "всем современным ООЯ" онтологически эквивалентны.

Ага. Языки могут иметь свое мнение. 5 балов.

В общем, заканчивай этот опус. Все что не противоречит логике примемлемо в обсуждении. Даже аналогии в качестве иллюстраций.

ГВ>Вобщем-то, эффективной мерой против подобной демагогии

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

ГВ> может служить утверждение "глупцов в мире — 99%, но мы-то с тобой из 1% оставшихся!" или "а насекомых на Земле на порядки больше, чем млекопитающих, но мы-то с тобой — люди!". Это, правда, обычно сваливает дискуссию в штопор демагогии, и одной из сторон остаётся в конце концов только умыть руки. Но обрати внимание, Влад, первым шаг в этот водоворот сделал не я.

Господи какой ... кхе-кхе.

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

Я правильно понимаю, что данное передергивание моно рассматривать как полное признение отсуствия у себя аргументации?

VD>> Довольно характерно, дизайнеры этих языков все как один выбрали "порочный" путь.
ГВ>Ышшо бы! Я бы очень удивился, если бы MS после Sun выбрала на роль нынешнего C# какой-нить LISP-образный или Smalltalk-подобный язык.

Уход от темы и передергиваение. Мы тут обсуждаем принципы ООП. ФЯ тут ни к селу, ни г городу.

ГВ>Сила Java — в переносимости (довольно приличной), поддержке Sun-ом и IBM, а отнюдь не в языке.

Голословные утверждения неимеющие ничего общего с действительностью.

ГВ> Слабость C++ опять таки, не в языке, а в том, что подавляющее большинство "программистов C++" таковыми на самом деле не являются, но очень много орут о недостатках C++.

Гы-гы.

ГВ> Ну не заточены у них мозги на ранний просчёт опасностей. Ну не заточены — и всё тут. Отсюда и довольно рспространённое признание "негативного опыта C++".

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

Лично моя версия такая. С++ плохо спроектированный переходной язык. Его цель была перевести программистов из мира структурного программирования на С, в мир объектно ориентированного программирования. С этой задачей язык справился успешно. Но количество проблем имеющихся в языке и тяжелое наследие непозволяют назвать его современным. Он или уйдет на второй план, или изменится. Пока что мне кажется первый вариант более реален. Уж больно создатели языка сильно цепляются за совместимость и не желают его развивать.

Что же до 'большинство "программистов C++" таковыми на самом деле не являются', дык... А. Язык нужен тому самому большинству, так что ему точно не жить если оно от него отвернется. Б. От С++ уходят, и совершенно оснознанно, многие высококвалифицированные специалисы (да и вообще талантливые люди). Так что это просто очередная попытка выдать желаемое за дейсвтиельное.

ГВ>>>С точки зрения OCP это — ошибка,
VD>>Точки зрения идут лесом если они не подтверждаются реальной практикой.
ГВ>Отнюдь. Как раз практика и послужила базисом для формулирования LSP, OCP, DIP и других xxP.

Думаю, что скорее теория, не в этом дело. Я говорю, о другом. Я говорю, что есть удобные вещи которым никакие теорие не требуеются. Не, не требуется, например, никаких теорий для того чтобы понять, что спать лучше на мягкой кравати под одеялом. Достаточно попробовать. Точно так же не требуется никаких умных слов в пользу удобства ToString()/to_s. Люди однажды попробовавшие это находят это чертовски удобным.

ГВ>Например, нарушение LSP приводит к одним и тем же последствиям, независимо от количества людей, которые его (не)соблюдают, поскольку LSP сформулирован в таких понятиях, как "зависимость" и "количественное измерение трудоёмкости модификации".

Сдается мне, что на лицо неврная оценка предпосылок, и как следствие неверная трактовка в общем-то разумных приципов. В народе это называется "доводить до маразма".

Ну, нет никаких проблем с модификацией классов у которых реализован метод ToString(). Ни одногой! Ты или вообще забываешь про начие этого метода, или реализуешь его так как тебе надо.

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


VD>>А реальная практика подтверждает только то, что такой подход резко увеличивает уровень языка и простуту создания кода не нем.
ГВ>На самом деле, это не столько подход, сколько деталь базового класса. И единственное, что он делает лучше всего — это сбивает с толку проектировщиков, поскольку ставит разработчика перед сложным выбором между неудачным, но готовым решением, и удачным, но которое ещё нужно "делать". К сожалению, эту дилемму легко свести к демагогическому "воспользоваться готовым или изобрести велосипед", и на первых порах "готовое" даже сработает. А потом... потом сработает второй закон термодинамики... т.е. — наступят следствия нарушения OCP и частично — LSP.

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

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

Нет уж. Я лучше пойду еще съем. А ты можешь продолжать спорить о вкусе устриц на основании своего опыта поедания крабовых палочек.

VD>> ToSting() в Яве и дотнете, а так же разные to_i в Руби используются постоянно, очень часто и невороятно элегантно. Более того к специальному форматированию приходится прибегать крайне редко
ГВ>Это всего лишь означает, что часть требований пользователя игнорируется или метод преобразования в строку используется во врапперах представления или в чём-то подобном. Причины я описал несколько выше.

Требованиями пользователя чаще пренибригают в программх написаннх на С++. И этому есть банальное объяснение. Писать на этом язые очень сложно, а столо быть мдленно. Библиотеки у него скудные. В итоге программист жертвует в первую очередь функциональностью и удобством.

Разоворы же о жертвах при программировании на современных языках типа Шарпа являются банальной непрадой.

VD>> и оно опять же делается через ОО-механизмы (например, через ту же перегрузку ToString()).
ГВ>Чем и нарушается OCP, ибо такой подход не позволит выводить данные одного и того же объекта в разном виде.

Наличие одного метода не запрещает наличия другого. А вот замена банальной логики верой в разные ОСР то действительно уже смешно.

ГВ>Давай возьмём простейшие примеры.

ГВ>1. Бухгалтеры иногда хотят видеть некоторые числа представленными с разной точностью в разных местах: не то два, не то четыре знака после запятой.

О! Мы перешли к реальному миру? Ну, тогда вот примеры:

const float sum = 123.4567F;

// Первый вариант.
result = sum.ToString("0.00");
Console.WriteLine("Summa is: " + result);

// Второй вариант. Здесь в {0:0.00} 0 - это номер аргумента, а 0.00 формат.
string result = string.Format("Summa is: {0:0.00}", sum);
Console.WriteLine(result);

// А в зачастую это все не нужно...
Console.WriteLine("Summa is: {0:0.00}", sum);

Давай, вываливай как выглядит аналогичный код в твоих программах.

Остальные примеры к делу не относятся.

ГВ>2. Выводим массив (список, стек и прочее — по вкусу). Разделить элементы нужно пробелами, или точками с запятой, или запятыми.

Специальной функции для этого нет. Это частная задча.
Вот пример из рельной жизни. В R# этой функцией выводится список аргументов:

/// Выводит список элементов типа AstNode разделяя их строкой 
/// перадаваемой в парамтре separator.
/// </summary>
/// <param name="list">Список элементов которые нужно вывести.</param>
/// <param name="separator">Строка разделяющая элементы.</param>
void PrintSeparatedList(IList list, string separator)
{
    int i = 0, count = list.Count;
    foreach (AstNode node in list)
    {
        if (i != 0)
            _sb.Append(separator);

        node.AcceptVisitor(this);
    
        i++;
    }
}

ГВ>3. Выводим строку (class String). Строку иногда нужно закавычить в одинарные или двойные кавычки.

И причем тут все эти частности? Ну:

string str1 = "некоторый текст";
str1 = '"' + str.Replace("\"", "\"\"") + '"';

string str2 = "некоторый текст \"{0}\" другой тест".Format("вставляемый текст");

ГВ>4. Строкове представление объекта выстреливается в лог-файл (группа значимых полей) и на экран (та же группа, но по-другому упорядоченная).

Вообще проблемы логфайла.

ГВ>Ну-с. Ваши предложения? Да, условие: вывод оформлять через toString().

А зачем? Это преобразования одной строки в другую. Зачем тут вообще ToString()? В общем, не притягивай ничего за уши.

ГВ>Когда предложишь решения, welcome с контрпримерами.

Это такой способ доказать что с помощью ToString() нельзя забивать гвозди? Ну, ты бы спросил. Я тебе и так скажу что нельзя. К делу относился только первый пример.

ГВ>ИМХО, это только доказывает, что сейчас принято любой ценой избегать попадания в сложные ситуации

Только критины стремятся попасть в сложне ситуации. Разумные люди пытаются максимально упростить себе жизнь. Это сложно сделать просто, а просто очень не просто.

ГВ>удовлетворения разнородных требований клиентов, концентрируясь на простейших.

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

ГВ> Но способ избегания тут по большому счёту один — сказать клиенту, что очередное требование удовлетворить невозможно, потому как "слишком сложно" или "на фига оно вам надо". В противном случае, не было бы тезиса о 90% и "большинстве". Возможно также, что речь идёт попросту о не слишком требовательных клиентах. Или же, высказывание сделано не к месту и не ковремени. Последнее — вероятнее всего.

И все это потому-что мы не удовлетворили требованиям ХЗЧ и выбрали неправильно спроектированный C#. Нью Васюки отдыхают.

ГВ>В любом случае, такое построение уместно назвать ошибкой неправомерного обобщения. Очень часто этим грешат начинающие проектировщики. Тебя я таковым не считаю, но ИМХО, ...

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

ГВ>ты несколько оторвался от реальности и заигрался с маркетинговыми лозунгами. Уж извини за прямоту.

Это ты оторвался от реальности. А я то как раз очень адекватно смотрю на жизнь в целом и на программирование в частности.

VD>>Опять же OPC нидает никаких приемуществ по управлению форматом.
ГВ>Странно, но именно в методике построения форматтеров, предлагаемой .Net как раз таки OCP до некоторой степени и учтён. Кривовато, но учтён. Иначе бы не появилось IFormatProvider и того, что с ним.

Кривовато, если ни сказать больше, это сделано в С++. А вот в дотнете все сделно очень даже прямо. IFormatProvider никакого отношения к ОРС не имеет. Это средство обобщения понятия форматирования. Причем компонентно-ориентированное, а значит позволяющее расширять возможности среды прямо в рантайме. На форумах уже были реализации IFormatProvider для представления числе прописью (по русски).

VD>>По факту формарировать преобразование в текст в дотнете и Яве на порядки проще чем в С++ и иже с ним. Но это уже конечно не заслуга языка, а общая заточенность архитектуры на человека.
ГВ>Здесь не в архитектуре дело, разумеется,

Именно в ней родимой, разумется.

ГВ>а в богатстве библиотеки .Net/Java.

Это часть архитектуры. Общая идея — все должно быть просто и легко.

ГВ> Так что, давай ты будешь называть вещи своими именами.

О форматировании заговорил ты. Так что называй своими именами все сам. Я это и так делаю.

ГВ> А то очень много сил уходит на согласование очередного выкрутаса менеджерски-маркетологического новояза с программистским.

Еще одна попытка наклеить ярлычек. Чудненько. Это хорошее доказательство отсуствия аргументации.

VD>>Это означет только то что вы с ПК не хатите признать очевидно. Нет ни единой причины по которй ToString нужно было бы вынести из object-а.
ГВ>Разумеется! Она там лежит себе, есть не просит. Просто более или менее грамотные проектировщики пользуются ею крайне осторожно.

Проктировцики функциями вообще пользоваться не должны. Не их это задача. Прикажут вы... А вот очередная ассоциация всех кто использует ToString() c множеством безграмотности тут налицо. Примемчик тоже скажем прямо третисортный.

ГВ>Кстати, причину ты совершенно верно назвал чуть ниже:
ГВ>

ГВ>ToString не единственный способ работы со строками

Вот это причина! А?! Кто бы мог подумать?

ГВ>Именно! Поскольку метод преобразования объекта в строку — инваринат по отношению к содержимому объекта! Следовательно, toString в базовом классе не нужна! Ну может быть, в виде toDebugString() её ещё можно оставить. Это сейчас просто мода такая пошла — совать в базовый объект всё, что можно и не можно.

Собственно снова вместо доказательсва вреда или демонстрации оного на примерах из жизни начинается старая песня про инваринты. Чушь это все. В программировании хорошо то что удобно, и не вызвает проблем. И ToString() — это очень удобно и не вызывает проблем.

VD>>И есть море приемуществ которые появлются в слудствии этого подхода.
ГВ>Море или не море, а я вижу помощь только в одном — слабать что-то по-быстрому.

Ага. Если убрать намеренную попытку унизить эту идею, то окажется — что это единственная цель которой стремятся все разнаботчики ЯП. Быстрое создание качественного ПО. Очень достоийная цель. А вот попытки прилепить сюда слова типа "слобать" нужны только чтобы дискредитировать хорошее начинание. Эдак можно сказать, что с твоим подходом можно только лишь слабать какую нибудь лажу по медленее.

ГВ> Вобщем-то, это популистский приём.

Это ты про лабать? Несомненно.

ГВ> Кстати, тоже своего рода демагогия.

Согласен.

ГВ> Аналогичная не помню уже где встречавшейся: "Если на C++ у вас лес деревьев, то в Java у вас есть одно стройное дерево объектов". Или там за .Net речь шла — не помню. Суть, надеюсь, ясна?

Ясна, ясна. Бобьба за приципы ради приципов. А реально борьба за замшелое болото. Попытки выставить все новое в неприглядом свете. Обяснить всем аппонентоам, что ни неумеют ничего делать и вообще дауны.

VD>> ToString не единственный способ работы со строками. Есть еще один ненравящийся консервативно настроенным личностям подход.
ГВ>В том-то и дело, что не единственный! Повторюсь: именно потому она и не нужна в базовом классе. Разве только — как источник данных для stack-trace.

Так где связь между тем что "способ не единственный", и тем что "именно потому она и не нужна в базовом классе"? Ну, хоть раз попробуй таки доказать именно эту связь. При этому не ссылаясь на крутые теории. Просто объяснит где здесь проблема? Почему наличие еще 100 методов может повредить?

VD>> Все типы поддерживающие преобразования реализуют интерфейс IConvertible. В нем каждый метод получает ссылку на IFormatProvider, который обеспечивает управление форматированием и расширение форматирования для внешних типов.
ГВ>И какое это отношение имеет к обсуждению метода toString общего базового класса?

IConvertible так же реализован в базовом классе, а не является независимой функцией или классом-сотелитом.

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

AVK>Открой к примеру исходники януса и посмотри где и в каком количестве применяется ToString(). Да, в дотнете ToString() в стектрейсе практически не используется .

250 раз в одном только проекте Janus (по сведениям запроса //MemberName[@VariableName = 'ToString'] в R#-е ). Еще оголо 70 вызвов string.Format. А сколько неявного использования, вообще никто сказать не может. Ведь даже конкатинация чего-то к строкам и та вызвает ToString. Так что:

string str = 1 + " 2 " + 3.0 + " " + DateTime.Now;

Это:

string str = 1.ToString() + " 2 " + (3.0).ToString() + " " + DateTime.Now.ToString();

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

Да их же ламеры делают. Вот спросили бы наших гуру, так они бы всему миру обяснили, что делать нужно С++.

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

ГВ>Угу, а кто его серебряной пулей называет?

Ты и ПК. И на этом основании запретили добавлять в классы все что не относитс к эксесорам данных.

ГВ>Лучше сам расскажи. А ещё лучше — объясни, почему приняты те или иные решения. В лес посылать мы все тут умеем.

Удбно, логично, практично. Что еще нужно?

AndrewVK:

> ПК> но для сложных приложений, где в каждом окошке может быть своя локаль (а то и в каждой части одного окошка), такой подход не пройдет.

> Это что же за приложения такие, тренировочные пособия для полиглотов что ли?

Например, web browser.

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

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

Здравствуйте, Павел Кузнецов, Вы писали:

>> Это что же за приложения такие, тренировочные пособия для полиглотов что ли?

ПК>Например, web browser.

Что webg browser? Ты где то в IE видел возможность одновременного использования нескольких локалей? Впрочем неважно — ведь браузер это то самое приложение, которое приходится писать практически каждому программисту .

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

ПК, ты действительно не знаешь как такая ситуация разруливается, или прикидываешься? Проблем с локалями там нет.

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

VD>Я не понял про оппеляцию

Влад, я тебя умоляю — аппеляция и оппонент, а не наоборот.

VD>Лично моя версия такая. С++ плохо спроектированный переходной язык. Его цель была перевести программистов из мира структурного программирования на С, в мир объектно ориентированного программирования. С этой задачей язык справился успешно. Но количество проблем имеющихся в языке и тяжелое наследие непозволяют назвать его современным. Он или уйдет на второй план, или изменится. Пока что мне кажется первый вариант более реален. Уж больно создатели языка сильно цепляются за совместимость и не желают его развивать.

Забавная прорисовывается аналогия между С-С++-Java/C# и Win3.1-Win95-WinNT . Даже основные критерии те же — скорость vs надежность vs совместимость со старым

ГВ>> А то очень много сил уходит на согласование очередного выкрутаса менеджерски-маркетологического новояза с программистским.

VD>Еще одна попытка наклеить ярлычек. Чудненько. Это хорошее доказательство отсуствия аргументации.

+1

VD>Ага. Если убрать намеренную попытку унизить эту идею, то окажется — что это единственная цель которой стремятся все разнаботчики ЯП. Быстрое создание качественного ПО. Очень достоийная цель. А вот попытки прилепить сюда слова типа "слобать" нужны только чтобы дискредитировать хорошее начинание. Эдак можно сказать, что с твоим подходом можно только лишь слабать какую нибудь лажу по медленее.

+1

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

AVK>Влад, я тебя умоляю — аппеляция и оппонент, а не наоборот.

Да какая разница? Тут народ иногда такое заворчивает, что уши трещат.

AVK>Забавная прорисовывается аналогия между С-С++-Java/C# и Win3.1-Win95-WinNT .

Дык и то, и то проявление эволюции в разных областях. Так что вполне объяснимо.

AVK> Даже основные критерии те же — скорость vs надежность vs совместимость со старым

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

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

AVK>"Антология демагогии".

А это где-то в Интернете валяется?

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

AVK>>"Антология демагогии".

VD>А это где-то в Интернете валяется?

http://mailx.finec.ru/~katia/demagogia.htm
И да пребудет с тобой Гугл.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>http://mailx.finec.ru/~katia/demagogia.htm
ЗХ>И да пребудет с тобой Гугл.

Сенкс.

...а про мух не будем.

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

ГВ>>Давай возьмём простейшие примеры.
ГВ>>1. Бухгалтеры иногда хотят видеть некоторые числа представленными с разной точностью в разных местах: не то два, не то четыре знака после запятой.

VD>О! Мы перешли к реальному миру? Ну, тогда вот примеры:
Отлично! Разберёмся. Притом учтём, что java.lang.Object, равно как и System.Object содержат метод toString() в его безаргументой версии. Все версии с дополнительными аргументами добавляются в производных классах. Отмечу также, что когда я имею ввиду метод toString без аргументов, то так и пишу: toString(), если имеются ввиду какие-то аргументы, то как минимум обозначаю это как toString(...). Возможно, что я не очень ясно выразился, ну да не суть.

Некоторые дефиниции.
В случае задачи форматирования можно выделить такие сущности: исходные данные, метод форматирования, параметры метода форматирования, результат форматирования (строка). Метод форматирования и его параметры определяют конечный вид результата: в каком порядке будут расположены изображения элементарных данных (если на входе — сложная структура), как будут изображаться сами элементарные данные и т.п. Сами данные определяют только допустимые модификации метода.

Очевидно, что если метод форматирования только до некоторой степени инвариантен по отношению к форматируемым данным, то параметры (конкретный их вид) — полностью инвариантны, поскольку регламентируются только используемым методом и требования к их конфигурации отличаются от требований к данным. Например, для вот такой структуры

struct X
{
  int a;
    // добавим int b;
};

добавление нового члена может и не привести к необходимости изменения параметров форматирования в клиентском коде.

Дальше в примерах я убрал знаки цитирования "VD>"

const float sum = 123.4567F;
// Первый вариант.
result = sum.ToString("0.00"); // 1.
Console.WriteLine("Summa is: " + result);
// Второй вариант. Здесь в {0:0.00} 0 - это номер аргумента, а 0.00 формат.
string result = string.Format("Summa is: {0:0.00}", sum); // 2.
Console.WriteLine(result);
// А в зачастую это все не нужно...
Console.WriteLine("Summa is: {0:0.00}", sum);

1. Данные: float sum. Инвариант: строка "0.00". Инвариант вынесен за пределы данных. Использована ToString(String, IFormatProvider).
2. Данные: float sum. Инвариант: строка "0.00", параметризующая форматирование. Инвариант вынесен за пределы данных.
В обоих случая использована IFormattable.ToString(String, IFormatProvider).

VD>Давай, вываливай как выглядит аналогичный код в твоих программах.
Примерно также. Инвариант объекта тоже вынесен за пределы самого объекта.

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

ГВ>>2. Выводим массив (список, стек и прочее — по вкусу). Разделить элементы нужно пробелами, или точками с запятой, или запятыми.
VD>Специальной функции для этого нет. Это частная задча.
Зря ты так категоричен. Эта задача может встретиться, например, при генерации SQL-предложений: элементы списка values(...) делятся запятыми, а перечисление условий отбора — пробелами.

VD>Вот пример из рельной жизни. В R# этой функцией выводится список аргументов:

/// <param name="list">Список элементов которые нужно вывести.</param>
/// <param name="separator">Строка разделяющая элементы.</param>
void PrintSeparatedList(IList list, string separator)
{
    int i = 0, count = list.Count;
    foreach (AstNode node in list)
    {
        if (i != 0)
            _sb.Append(separator);
        node.AcceptVisitor(this);
        i++;
    }
}

Данные: list. Инвариант: обход через foreach, параметр separator. Вердикт: инвариант вынесен за пределы данных.

Каюсь, что я не знаю о том, что стоит за вызовом _sb.Append(separator);, и что означает _sb — тоже. Но главное таки ясно. Сепаратор передаётся как аргумент метода PrintSeparatedList, который как раз занимается сборкой итогового представления. Инвариантом списка в данном случае является как сепаратор, так и метод (в смысле — "способ") размещения объектов в строке.

ГВ>>3. Выводим строку (class String). Строку иногда нужно закавычить в одинарные или двойные кавычки.
VD>И причем тут все эти частности? Ну:
Притом, что это тоже одна из задач, которая со свистом решается на уровне форматирования вывода.

string str1 = "некоторый текст";
str1 = '"' + str.Replace("\"", "\"\"") + '"';

//string str2 = "некоторый текст \"{0}\" другой тест".Format("вставляемый текст");
// ^ Не компилируется. (с) .Net v.1.1, правильная конструкция:
string str2 = string.Format("некоторый текст {0} другой тест", "вставляемый текст");

Данные: str1. Инвариант: обработка replace-ом и операция конкатенации с кавычками. Вердикт: инвариант вынесен за пределы данных.
Данные: "вставляемый текст". Инвариант: аргумент метода Format. Вердикт: инвариант вынесен за пределы данных.
Здесь в обоих случаях используются ToString(), но только тогда, когда можно со 100%-й гарантией предсказать результат её применения — в конкатенации.

Кстати, метод Format ещё один пример нарушения OCP — при необходимости расширения методик форматирования посыплется интерфейс System.String.

ГВ>>4. Строкове представление объекта выстреливается в лог-файл (группа значимых полей) и на экран (та же группа, но по-другому упорядоченная).
VD>Вообще проблемы логфайла.
Ну ладно, не будем, так не будем.

Итак, что получилосьв сухом остатке? А то, что во всех продемонстрированных тобой решениях инварианты данных (как минимум параметры форматирования) есть и выносятся за пределы данных. Т.е., ты обходишь использование метода ToString(), используя его разе только для копирования содержимого строки.

Ты наглядно продемонстрировал вынос инварианта за пределы обрабатываемого объекта. Просто ты не обозначал причину принятия такого решения как "соблюдение OCP", ограничившись "удобно-не удобно". А на самом деле, это и есть соблюдение Open Closed Principle — инварианты уложены вне обрабатываемого объекта. Такм образом объект закрывается для модификаций, но открывается для расширения.

Теперь то же самое в более точных терминах.

System.Object.ToString() нарушает OCP, поскольку предполагает доступ к инвариантам форматирования изнутри объекта. IFormattable, напротив, даёт возможность соблюсти OCP, но при этом отсутствует в базовом System.Object.

ГВ>>Ну-с. Ваши предложения? Да, условие: вывод оформлять через toString().
VD>А зачем? Это преобразования одной строки в другую.
Да ну? А я-то уж думал, что toString() обеспечивает некое обобщённое представление. Иначе зачем он тогда в базовом классе? Кстати, если это "просто преобразование", то почему, например, System.Object не содержит интерфейсов преобразования к int64 или float?

VD>Зачем тут вообще ToString()? В общем, не притягивай ничего за уши.
В точку! Он не только незачем, он ещё и мешается везде, кроме как в System.String. Почему мешается? Потому что у него неопределённая семантика. Например, для float он порежет незначащие нули. Т.е., лучше всего, похерить эту самую неопределённую семантику, а для случая форматирования пользоваться только IFormattable, который, повторюсь, отсутсвует в базовом классе.

С точки зрения дизайна есть и ещё одна претензия к наличию toString в базовом классе. Прежде всего, результат этого метода представлен объектом, который сам по себе является наследником базового. Т.е., нарушается ещё один принцип дизайна, конкретно — базовый объект знает о реализации своих наследников. И это, заметь, в корне иерархии!

ГВ>>Когда предложишь решения, welcome с контрпримерами.
VD>Это такой способ доказать что с помощью ToString() нельзя забивать гвозди? Ну, ты бы спросил. Я тебе и так скажу что нельзя.
Я это и сам знаю, спасибо.

VD>>>Опять же OPC нидает никаких приемуществ по управлению форматом.
ГВ>>Странно, но именно в методике построения форматтеров, предлагаемой .Net как раз таки OCP до некоторой степени и учтён. Кривовато, но учтён. Иначе бы не появилось IFormatProvider и того, что с ним.
VD>Кривовато, если ни сказать больше, это сделано в С++. А вот в дотнете все сделно очень даже прямо. IFormatProvider никакого отношения к ОРС не имеет.
Наипрямейшее отношение имеет. Как раз "вынос" функциональности форматирования в отдельный объект и приводит к соблюдению OCP. Надо же чем-то обработать параметры форматирования?

VD>Это средство обобщения понятия форматирования.
Да, именно так и есть. Однако, IFormattable не реализован в базовом классе. Не находишь это забавным?

VD>>>Это означет только то что вы с ПК не хатите признать очевидно. Нет ни единой причины по которй ToString нужно было бы вынести из object-а.
ГВ>>Разумеется! Она там лежит себе, есть не просит. Просто более или менее грамотные проектировщики пользуются ею крайне осторожно.
VD>Проктировцики функциями вообще пользоваться не должны. Не их это задача. Прикажут вы... А вот очередная ассоциация всех кто использует ToString() c множеством безграмотности тут налицо.
Странно. Только что ты подтвердил мне своими ответами, что таки да, грамотные проектировщики действительно пользуются функцией ToString() с осторожностью. Причём тут "прикажут вы..."? Прикажут — так и в System.Object.ToString() параметры нарОдятся? Так что ли, прикажешь тебя понимать?

ГВ>>Именно! Поскольку метод преобразования объекта в строку — инваринат по отношению к содержимому объекта! Следовательно, toString в базовом классе не нужна! Ну может быть, в виде toDebugString() её ещё можно оставить. Это сейчас просто мода такая пошла — совать в базовый объект всё, что можно и не можно.
VD>Собственно снова вместо доказательсва вреда или демонстрации оного на примерах из жизни начинается старая песня про инваринты. Чушь это все. В программировании хорошо то что удобно, и не вызвает проблем. И ToString() — это очень удобно и не вызывает проблем.
Нет, ты путаешь System.Object.ToString() и IFormattable.ToString(...).

VD>>>И есть море приемуществ которые появлются в слудствии этого подхода.
ГВ>>Море или не море, а я вижу помощь только в одном — слабать что-то по-быстрому.
VD>Ага. Если убрать намеренную попытку унизить эту идею, то окажется — что это единственная цель которой стремятся все разнаботчики ЯП. Быстрое создание качественного ПО. Очень достоийная цель. А вот попытки прилепить сюда слова типа "слобать" нужны только чтобы дискредитировать хорошее начинание. Эдак можно сказать, что с твоим подходом можно только лишь слабать какую нибудь лажу по медленее.
А как ещё называть решение, которое нужно перекрыть при мало-мальском изменении требований?

VD>>> ToString не единственный способ работы со строками. Есть еще один ненравящийся консервативно настроенным личностям подход.
ГВ>>В том-то и дело, что не единственный! Повторюсь: именно потому она и не нужна в базовом классе. Разве только — как источник данных для stack-trace.
VD>Так где связь между тем что "способ не единственный", и тем что "именно потому она и не нужна в базовом классе"?
Потому что безаргументный вариант toString не является на самом деле общим. Даже в простейшем частном случае параметризации формата (2 или 4 знака после запятой?) тебе придётся эту функцию перегружать версией с параметрами и писать собственную прослойку форматтеров. Но в базовом классе такой функции нет! Т.е., в конечном итоге получаем почти то же самое множественное наследование. Вобщем-то, разработчики .Net так и поступили — базовый объект содержит пустышку, возвращающую "System.Object", а уже производные реализуют более сложные методы форматирования, оформленные как подмешивание IFormattable: IFormattable.ToString(String, IFormatProvider). Чудес ведь не бывает. Что, кстати, служит подтверждением моим словам о том, что опытные разработчики пользуются ToString() довольно осторожно.

Хотя в качестве рациональной причины по которой в базовый класс внесена ToString, я могу назвать только одну: необходимость обеспечить хоть какое-то преобразование в строковое представление любого объекта программы. Но это по меньшей мере странно, поскольку framework и так имеет (или — может иметь) полное представление о структуре своих собственных объектов. А с точки зрения framework все объекты — его собственные. Так что, смысл её внесения в базовый объект остаётся тёмным.

VD> Ну, хоть раз попробуй таки доказать именно эту связь. При этому не ссылаясь на крутые теории. Просто объяснит где здесь проблема?
Проблема метода ToString() состоит в неопределённости его семантики. Что у него на выходе? Будут ли обрезаны незначащие нули у типов с плавающей точкой? С какой точностью он выведет данные? Короче, то же самое, что и спецификация %f для функции sprintf(...).

Другая проблема, как я уже говорил, в том, что ToString() на практике приходится перекрывать методами IFormattable. Разработчикам .Net от этого ни холодно ни жарко, а появись такая ситуация (метод с неопределённой семантикой) в коде, который полностью контролируется менее крупной фирмой, чем MS, это привело бы к изменению дизайна базового класса. Как следствие изначального нарушения OCP.

VD> Почему наличие еще 100 методов может повредить?
Потому что снизится стабильность интерфейса и/или будет внесена путаница в интерфейсы наследников. Т.е., упадёт устойчивость дизайна к измененям требований. А так... да без проблем вобщем-то, я же говорил, лежат, есть не просят.

VD>>> Все типы поддерживающие преобразования реализуют интерфейс IConvertible. В нем каждый метод получает ссылку на IFormatProvider, который обеспечивает управление форматированием и расширение форматирования для внешних типов.
ГВ>>И какое это отношение имеет к обсуждению метода toString общего базового класса?
VD>IConvertible так же реализован в базовом классе, а не является независимой функцией или классом-сотелитом.
В каком это базовом классе он реализован? В System.Object, что ли? Или в System.ValueType? Рассказать, какое исключение вылетит здесь:

Object o = new Object();
IConvertible p = (IConvertible)o;

Но вообще не знаю, может быть, в .Net 1.2 никакого исключения и не будет.

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

AVK>>Открой к примеру исходники януса и посмотри где и в каком количестве применяется ToString(). Да, в дотнете ToString() в стектрейсе практически не используется .
VD>250 раз в одном только проекте Janus (по сведениям запроса //MemberName[@VariableName = 'ToString'] в R#-е ). Еще оголо 70 вызвов string.Format. А сколько неявного использования, вообще никто сказать не может. Ведь даже конкатинация чего-то к строкам и та вызвает ToString. Так что:
А сколько из них именно ToString(), а не ToString с параметрами?

VD>

VD>string str = 1 + " 2 " + 3.0 + " " + DateTime.Now;
VD>

Это:

VD>string str = 1.ToString() + " 2 " + (3.0).ToString() + " " + DateTime.Now.ToString();
VD>

А что на выходе будет?
1 2 3.0 дата
или
1 2 3 дата?

VD> Вот спросили бы наших гуру, так они бы всему миру обяснили, что делать нужно С++.
C++ или не C++, сути это не меняет.

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

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

Твоя позиция — это позиция теоретика не видящего 90% предпосылок и делающего выводы. Что-же можешь вместе с ПК соблюдать правила разных ОЦП и т.п. даже во прики банальному разуму. От этого ничего ровным счетом не изменится. Люди будут выбирать интуитивные и удобные реализации. А соблюдение синтетических правил без исключений всегда будет приводить к маразму.

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

ГВ>1 2 3 дата?

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

ГВ>> "Применяется широко" вовсе не означает, что "нужен в общем базовом объекте". Разницу сечёшь?
AVK>Применяется широко означает что не вносит каких то проблем. Разницу сечешь?
Нет. Это означает только то, что "применяется широко". В качестве примера. Сколько раз твердили, что copy&past — программирование суть создание проблем самим себе? И что? Всё равно же часто применяется. Но сути-то это не меняет.

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

AVK>>Применяется широко означает что не вносит каких то проблем. Разницу сечешь?
ГВ>Нет. Это означает только то, что "применяется широко". В качестве примера. Сколько раз твердили, что copy&past — программирование суть создание проблем самим себе? И что? Всё равно же часто применяется. Но сути-то это не меняет.

Хорошо, расскажи тогда мне с какими ужасными проблемами я сталкиваюсь из-за наличия ToString()

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

AVK>>>Применяется широко означает что не вносит каких то проблем. Разницу сечешь?
ГВ>>Нет. Это означает только то, что "применяется широко". В качестве примера. Сколько раз твердили, что copy&past — программирование суть создание проблем самим себе? И что? Всё равно же часто применяется. Но сути-то это не меняет.
AVK>Хорошо, расскажи тогда мне с какими ужасными проблемами я сталкиваюсь из-за наличия ToString()

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

Ну а что до заморочек, то вот здесь

Автор: Геннадий Васильев
Дата: 08.11.04

я отвечал Владу по этому поводу. Не так, чтобы это были большие проблемы... Посмотри, если что-то непонятно или нечётко сформулировано (без этого не обошлось), спрашивай — дообъясню.

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

ГВ>>1 2 3 дата?

Это если у тебя дробная часть нулевая. А если нужно гарантировать ширину выводимого поля? ИМХО, та же самая проблема, что и при использовании спецификаций "%f" или "%n.nf".