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

ПК>

Есть два класса: Date и String. Методом какого класса является функции: 1) преобразования даты в строку; 2) преобразования строки в дату?
ПК>

Методом какого класса является функции преобразования: 1) целого в строку; 2) строки в целое? Есть ли какое-либо отличие этого примера от предыдущего?

Кстати, в контексте такого рассуждения интересно подумать по поводу методов toString(), распространённых как в Java, так и в .Net. Это — к вопросу об OCP.

... << RSDN@Home 1.1.3 stable >>

18.11.04 17:58: Ветка выделена из темы Мэйнстрим vs. Самосовершенствование :)))

Автор: LaptevVV
Дата: 20.10.04

— AndrewVK

Геннадий Васильев:

> ПК>

Есть два класса: Date и String. Методом какого класса является функции: 1) преобразования даты в строку; 2) преобразования строки в дату?
> ПК>

Методом какого класса является функции преобразования: 1) целого в строку; 2) строки в целое? Есть ли какое-либо отличие этого примера от предыдущего?

> Кстати, в контексте такого рассуждения интересно подумать по поводу методов toString(), распространённых как в Java, так и в .Net. Это — к вопросу об OCP.

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

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

Posted via RSDN NNTP Server 1.9 gamma

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

>> ПК>

Методом какого класса является функции преобразования: ...
>> Кстати, в контексте такого рассуждения интересно подумать по поводу методов toString(), распространённых как в Java, так и в .Net. Это — к вопросу об OCP.
ПК>Дык, чего ж тут думать: пошли, дармоеды, на поводу у жалобно плачущих пользователей, желающих по нажатию на точку получать список методов Шучу.

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

... << RSDN@Home 1.1.3 stable >>

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

ГВ>Кстати, в контексте такого рассуждения интересно подумать по поводу методов toString(), распространённых как в Java, так и в .Net. Это — к вопросу об OCP.

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

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

AVK>Оно может и неправильно с точки зрения принципов, но зато офигительно удобно.
Это уж точно — а то можно и совсем в дебри залезть:

ObjectFactory f = Context.ObjectFactory[typeof(TypeConverter)];
TypeConverter itoa  = f.CreateConverter(typeof(IntConverter));
MethodInvocator i = Context.GetMethodInvocator(new Type[]{typeof(string)});
MethodDescriptor toString = f.GetDescriptorFor(itoa, "convert");
i.AttachSecurityCertificate(Context.DefaultCertificate, MethodRights.Invoke | MethodRights.SpecifyParams | MethodRights.GetResult );
toString.AddParameter(i.CreateIntParameter("from").SetValue(4));
string s;
i.SetReturnValue(i.CreateStringParameter()).BindReference(s);
i.CallBehavior = CallBehaviour.Virtual;
i.Invoke(toString);

Это в смысле вместо

string s = 4.toString();

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

ГВ>Кстати, в контексте такого рассуждения интересно подумать по поводу методов toString(), распространённых как в Java, так и в .Net. Это — к вопросу об OCP.

+ Руби и Питон. Да все современные ООЯ имеют подобный метод. Вещь крайне удобная и очень часто испоьзуемая. В Руби она называется инспектор (inspect), но суть та же.

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

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

Я бы даже сказал гнусно наплевали на СТЛ и пошли на поводу ООП. Даже виртуальным этот метод сделали. И предлагают переопределять его где попало.

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

Мягко коворя, неправда. Объекты которые предпологают форматированный вывод реализуют перегруженную версию ToString(). Например, список реализаций у Int32:

Converts the numeric value of this instance to its equivalent string representation.

[C#] public override string ToString();
Converts the numeric value of this instance to its equivalent string representation using the specified culture-specific format information.

[C#] public virtual string ToString(IFormatProvider);
Converts the numeric value of this instance to its equivalent string representation, using the specified format.

[C#] public string ToString(string);
Converts the numeric value of this instance to its equivalent string representation using the specified format and culture-specific format information.

[C#] public virtual string ToString(string, IFormatProvider);

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

В общем, как в том анкдоте... Обосновал, но припохабно...

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

AVK>Оно может и неправильно с точки зрения принципов, но зато офигительно удобно.

Да все оно правильно. А принципы ради принципов — это маразм.

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

ГВ>>Кстати, в контексте такого рассуждения интересно подумать по поводу методов toString(), распространённых как в Java, так и в .Net. Это — к вопросу об OCP.
VD>+ Руби и Питон. Да все современные ООЯ имеют подобный метод. Вещь крайне удобная и очень часто испоьзуемая. В Руби она называется инспектор (inspect), но суть та же.

Влад, знаешь такой постулат о некорректности апелляции к коллективу в споре? Как раз твой случай. Тот факт, что такой метод есть в <нужное вписать> ровным счётом ничего не означает.

С точки зрения OCP это — ошибка, поскольку толком его использовать можно только в stack-trace (где вобщем-то, особых требований к формату вывода не предъявляется). С другой стороны это также может означть, что в некоторых случаях приходиться поступаться пожеланиями к строковому представлению в угоду уже имеющейся реализации. Только-то и всего.

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

VD>>+ Руби и Питон. Да все современные ООЯ имеют подобный метод. Вещь крайне удобная и очень часто испоьзуемая. В Руби она называется инспектор (inspect), но суть та же.

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

В первые слышу.

ГВ> Как раз твой случай. Тот факт, что такой метод есть в <нужное вписать> ровным счётом ничего не означает.

С каких пор коллектив стал состоять из объектов, а не субъктов. Я привел список современных языков которые по мнению очень большого количества народа считаются очень стройно спроектированными и я даже сказал бы лидерами отросли. Довольно характерно, дизайнеры этих языков все как один выбрали "порочный" путь. И довольно характерно, что результат значительно превосходит предшественников. Люди создававшие все эти языки сделали свой выбор совершенно осознанно. Опты того же С++ ими учитывался. И к сожалению для С++ во многом опыт С++ был признан негативным.

ГВ>С точки зрения OCP это — ошибка,

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

ГВ>поскольку толком его использовать можно только в stack-trace

Ну, давай осбуждать вкус устриц с теми кто их ел. ToSting() в Яве и дотнете, а так же разные to_i в Руби используются постоянно, очень часто и невороятно элегантно. Более того к специальному форматированию приходится прибегать крайне редко и оно опять же делается через ОО-механизмы (например, через ту же перегрузку ToString()). И вообще, строки на столько часто используются в программах, что грех не выделить их в привелегерованный класс.

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

Они в 90% случаев не предявляются. В ОС есть настройки приемлемого для текущего пользователя форматирования которых бывает достаточно в большинстве случаев. Опять же OPC нидает никаких приемуществ по управлению форматом. По факту формарировать преобразование в текст в дотнете и Яве на порядки проще чем в С++ и иже с ним. Но это уже конечно не заслуга языка, а общая заточенность архитектуры на человека.

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

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

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

VD>>>+ Руби и Питон. Да все современные ООЯ имеют подобный метод. Вещь крайне удобная и очень часто испоьзуемая. В Руби она называется инспектор (inspect), но суть та же.
ГВ>>Влад, знаешь такой постулат о некорректности апелляции к коллективу в споре?
VD>В первые слышу.

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

ГВ>> Как раз твой случай. Тот факт, что такой метод есть в <нужное вписать> ровным счётом ничего не означает.
VD>С каких пор коллектив стал состоять из объектов, а не субъктов.
Апелляции к "коллективу", к "массе", к чему-либо "общепринятому" и просто ко "всем современным ООЯ" онтологически эквивалентны. Во всех случаях вместо оценки качеств решения А прибегают к упоминанию количеств использований решения Б. Собственно говоря, чуть ниже ты продемонстрировал подобное демагогическое развитие рассуждения, перейдя к упоминанию "очень большого количества народа", "лидеров отрасли", "дизайнеров языков". Логически, ты сказал примерно следующее: "Миллион леммингов не могут ошибаться".

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

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

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

VD>И довольно характерно, что результат значительно превосходит предшественников. Люди создававшие все эти языки сделали свой выбор совершенно осознанно. Опты того же С++ ими учитывался. И к сожалению для С++ во многом опыт С++ был признан негативным.
Сила Java — в переносимости (довольно приличной), поддержке Sun-ом и IBM, а отнюдь не в языке. Слабость C++ опять таки, не в языке, а в том, что подавляющее большинство "программистов C++" таковыми на самом деле не являются, но очень много орут о недостатках C++. Ну не заточены у них мозги на ранний просчёт опасностей. Ну не заточены — и всё тут. Отсюда и довольно рспространённое признание "негативного опыта C++".

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

Например, нарушение LSP приводит к одним и тем же последствиям, независимо от количества людей, которые его (не)соблюдают, поскольку LSP сформулирован в таких понятиях, как "зависимость" и "количественное измерение трудоёмкости модификации". И от того, что конкретный язык/система и т.п. несколько снижает общую трудоёмкость разработки ПО соотношение этих величин для тех или иных дизайнерских решений, попавших под модификации, не изменится. Т.е., LSP (как и остальные xxP, я сознательно здесь обобщаю) разумеется, можно послать подальше, прицепившись к фразе собеседника, содержащей выражение "точка зрения"; можно говорить, что современные средства позволяют без проблем обойти ограничение, и что, в конце концов, работы будет +/- пару часов... Да много ещё чего можно сказать, но суть проблемы от этого не изменится. Это как закон всемирного тяготения. В него можо верить, а можно не верить — проявления не изменятся.

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

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

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

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

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

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

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

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

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

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

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

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

ГВ>> (где вобщем-то, особых требований к формату вывода не предъявляется).
VD>Они в 90% случаев не предявляются. В ОС есть настройки приемлемого для текущего пользователя форматирования которых бывает достаточно в большинстве случаев.
ИМХО, это только доказывает, что сейчас принято любой ценой избегать попадания в сложные ситуации удовлетворения разнородных требований клиентов, концентрируясь на простейших. Но способ избегания тут по большому счёту один — сказать клиенту, что очередное требование удовлетворить невозможно, потому как "слишком сложно" или "на фига оно вам надо". В противном случае, не было бы тезиса о 90% и "большинстве". Возможно также, что речь идёт попросту о не слишком требовательных клиентах. Или же, высказывание сделано не к месту и не ковремени. Последнее — вероятнее всего.

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

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

VD>По факту формарировать преобразование в текст в дотнете и Яве на порядки проще чем в С++ и иже с ним. Но это уже конечно не заслуга языка, а общая заточенность архитектуры на человека.
Здесь не в архитектуре дело, разумеется, а в богатстве библиотеки .Net/Java. Так что, давай ты будешь называть вещи своими именами. А то очень много сил уходит на согласование очередного выкрутаса менеджерски-маркетологического новояза с программистским.

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

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

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

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

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

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

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

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

Именно так они и работают. Да, контекст не глобальный, а в стеке потока.

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

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

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

ГВ>С точки зрения OCP это — ошибка,

Знаешь из этого какой вывод — ОСР это не серебрянная пуля, и надо думать головой каждый раз.

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

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

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

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

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

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

О да, теория глобального заговора не менее эффективный прием, нежели тот что применил Влад.

ГВ>Сила Java — в переносимости (довольно приличной), поддержке Sun-ом и IBM, а отнюдь не в языке. Слабость C++ опять таки, не в языке, а в том, что подавляющее большинство "программистов C++" таковыми на самом деле не являются, но очень много орут о недостатках C++. Ну не заточены у них мозги на ранний просчёт опасностей. Ну не заточены — и всё тут. Отсюда и довольно рспространённое признание "негативного опыта C++".

Все вокруг в навозе, один я в белом фраке. Очередная демагогия.

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

Т.е. серебрянная пули ака правила без исключений таки существуют? Забавно, до сих пор я считал что нет.

ГВ>Да много ещё чего можно сказать, но суть проблемы от этого не изменится. Это как закон всемирного тяготения. В него можо верить, а можно не верить — проявления не изменятся.

Ага. И пофигу что на орбите он не действует. Мы все равно будем считать что он там есть, а то что космонавтам неудобно кушать суп ложкой, так это ничего, переживут. Ради принципов на многое можно закрыть глаза

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

Демагогия.

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

VD>>> Довольно характерно, дизайнеры этих языков все как один выбрали "порочный" путь.
ГВ>>Ышшо бы! Я бы очень удивился, если бы MS после Sun выбрала на роль нынешнего C# какой-нить LISP-образный или Smalltalk-подобный язык.
AVK>О да, теория глобального заговора не менее эффективный прием, нежели тот что применил Влад.
В отпуск! Я имею ввиду, что MS было бы труднее раскручивать свою платформу, если бы вместо C# был LISP. Только и всего. А ты что подумал? Чтоя подозреваю кого-то во всемирном заговоре против C++?

ГВ>>Сила Java — в переносимости (довольно приличной), поддержке Sun-ом и IBM, а отнюдь не в языке. Слабость C++ опять таки, не в языке, а в том, что подавляющее большинство "программистов C++" таковыми на самом деле не являются, но очень много орут о недостатках C++. Ну не заточены у них мозги на ранний просчёт опасностей. Ну не заточены — и всё тут. Отсюда и довольно рспространённое признание "негативного опыта C++".
AVK>Все вокруг в навозе, один я в белом фраке. Очередная демагогия.
Да не, не в навозе. Что же, раз под C++ не заточены, то сразу "в навозе"? Ну вот, не заточены просто и всё тут. Ничего плохого в этом нет. Я вот VB и Java не люблю. Но я же не ору, что VB must die и Java must die!

VD>>>Точки зрения идут лесом если они не подтверждаются реальной практикой.
ГВ>>Отнюдь. Как раз практика и послужила базисом для формулирования LSP, OCP, DIP и других xxP. Правда, при упоминании этих принципов кроме прилагательных "общепринятые", "гуруистские" и т.п., часто забывают о такой характеристике, как "экономичные".
AVK>Т.е. серебрянная пули ака правила без исключений таки существуют? Забавно, до сих пор я считал что нет.
Бывают. Правила. С объективными законами сложнее. Обычно можно просто свести последствия их игнорирования к минимуму. Например — не прыгать с высоты более 1 метра. Или нарушать LSP в рамках 10-кбайтной программы. И не более 2-х раз.

ГВ>>Да много ещё чего можно сказать, но суть проблемы от этого не изменится. Это как закон всемирного тяготения. В него можо верить, а можно не верить — проявления не изменятся.
AVK>Ага. И пофигу что на орбите он не действует.
Двойка. Иди учить физику. Только благодаря закону всемирного тяготения орбита как таковая и существует. Иначе всё летело бы равномерно и поступательно в одном направлении.

AVK>Мы все равно будем считать что он там есть, а то что космонавтам неудобно кушать суп ложкой, так это ничего, переживут. Ради принципов на многое можно закрыть глаза
А вот воздействие земной гравитации компенсируется центробежной силой, действющей на тело, которое движется по орбите. Так что, космонавтам таки суп ложкой кушать неудобно, поскольку суп летит по орбите с той же скоростью, что и корабль.

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

А по существу тебе сказать нечего?

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

ГВ>>С точки зрения OCP это — ошибка,
AVK>Знаешь из этого какой вывод — ОСР это не серебрянная пуля, и надо думать головой каждый раз.
Угу, а кто его серебряной пулей называет?

ГВ>> поскольку толком его использовать можно только в stack-trace (где вобщем-то, особых требований к формату вывода не предъявляется).
AVK>Открой к примеру исходники януса и посмотри где и в каком количестве применяется ToString(). Да, в дотнете ToString() в стектрейсе практически не используется .

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

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

AVK> и морально-программистская безпринципность.
не уверен.

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

ГВ>В отпуск! Я имею ввиду, что MS было бы труднее раскручивать свою платформу, если бы вместо C# был LISP.

DВот я и говорю — сплошная конспирология.

ГВ>>>Сила Java — в переносимости (довольно приличной), поддержке Sun-ом и IBM, а отнюдь не в языке. Слабость C++ опять таки, не в языке, а в том, что подавляющее большинство "программистов C++" таковыми на самом деле не являются, но очень много орут о недостатках C++. Ну не заточены у них мозги на ранний просчёт опасностей. Ну не заточены — и всё тут. Отсюда и довольно рспространённое признание "негативного опыта C++".
AVK>>Все вокруг в навозе, один я в белом фраке. Очередная демагогия.
ГВ>Да не, не в навозе.

Ну как же, "подавляющее большинство "программистов C++" таковыми на самом деле не являются" это и есть "все вокруг в навозе", только несколько другими словами.

4. Безадресная брань
Классический пример безадресной брани – когда человек поскользнулся, упал и громко воскликнул «Черт побери!» К сожалению, некоторые люди порой разражаются такими тирадами, рядом с которыми «Черт побери!» кажется райской музыкой… При этом они, с одной стороны, не хотят обидеть никого специально, а с другой – оскорбляют всех, кто оказался в пределах слышимости. Принять ругательство на свой счет может любой, оказавшийся рядом, и случается, что именно так вспыхивают «совершенно беспричинные» драки на улицах.

...

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

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

ГВ> Что же, раз под C++ не заточены, то сразу "в навозе"?

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

AVK>>Т.е. серебрянная пули ака правила без исключений таки существуют? Забавно, до сих пор я считал что нет.
ГВ>Бывают.

А, ну тогда понятно. Удачи.

ГВ>>>Да много ещё чего можно сказать, но суть проблемы от этого не изменится. Это как закон всемирного тяготения. В него можо верить, а можно не верить — проявления не изменятся.
AVK>>Ага. И пофигу что на орбите он не действует.
ГВ>Двойка. Иди учить физику. Только благодаря закону всемирного тяготения орбита как таковая и существует. Иначе всё летело бы равномерно и поступательно в одном направлении.

Демагогия. Ты прекрасно понял о чем я.

AVK>>Мы все равно будем считать что он там есть, а то что космонавтам неудобно кушать суп ложкой, так это ничего, переживут. Ради принципов на многое можно закрыть глаза
ГВ>А вот воздействие земной гравитации компенсируется центробежной силой, действющей на тело, которое движется по орбите. Так что, космонавтам таки суп ложкой кушать неудобно, поскольку суп летит по орбите с той же скоростью, что и корабль.

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

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

Нет, демагогия.

c. Некорректная аналогия

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

http://blacklight.h1.ru/oppo09.htm

ГВ>А по существу тебе сказать нечего?

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

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

AVK>>Знаешь из этого какой вывод — ОСР это не серебрянная пуля, и надо думать головой каждый раз.
ГВ>Угу, а кто его серебряной пулей называет?

Ну а что это есть, если вы призываете ему следовать безусловно?

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

ГВ>Лучше сам расскажи.

Долго.

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

Это не лес. Я тебе привел конкретный факт — ToString() в реальном приложении применяется очень широко, следовательно твои выводы о ненужности ToString() не верны.

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

С верой спорить бессмысленно.

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

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

AVK>Ты всерьез считаешь что я этого не знаю? Не забывай — мы сейчас не физику обсуждаем, а твою аналогию. И ковыряться в физике в такой ситуации это чистейшая демагогия. Суть ты прекрасно понял — для любого принципа существуют границы применимости. Принципов без таковых в природе пока не обнаружено.
Я разве спорю? Особено, если сводить любой принцип к вульгарно-бытовой трактовке. Разумеется, на каждой кухне своя теория атомного ядра. Далее — см. подпись под моими сообщениями. Тем паче, что приведённая тобой аналогия тоже корректностью не страдает.

VD>>>>>Ну, давай осбуждать вкус устриц с теми кто их ел.
ГВ>>>>Давай. Только давай сначал разберёмся, где здесь устрицы, а где крабовые палочки из третьесортной рыбы с красителем.
AVK>>>Демагогия.
ГВ>>Не-а. Метафора. И именно как метафора и подавалась.
AVK>Нет, демагогия.
AVK>c. Некорректная аналогия
AVK>http://blacklight.h1.ru/oppo09.htm
Ну, дело твоё. Вобщем-то, если принять постулат о границах применимости, то каждый на своей кухне прав. К чему тогда споры?

AVK>Просто не удержался при виде такой неприкрытой демагогии.
Аналогично, как ты понимаешь. Надеюсь, что понимаешь.

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

AVK>>>Знаешь из этого какой вывод — ОСР это не серебрянная пуля, и надо думать головой каждый раз.
ГВ>>Угу, а кто его серебряной пулей называет?
AVK>Ну а что это есть, если вы призываете ему следовать безусловно?
Ему можно и следовать, не следовать и ограниченно следовать. Это вопрос оценки тяжести последствий.

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

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

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

ГВ>>> А ещё лучше — объясни, почему приняты те или иные решения. В лес посылать мы все тут умеем.
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".

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

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

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

Я вот как раз не перевожу.

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

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

я отвечал Владу по этому поводу.

Описания проблем я там не увидел.

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

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

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

я отвечал Владу по этому поводу.

AVK>Описания проблем я там не увидел.

Постараюсь перечислить неудобства которые могли бы возникнуть у меня (Примеры получены поиском ToString в Janus)

1.

public static bool IsSubscribed(int id)
...
cmd.CommandText = "SELECT COUNT(*) FROM subscribed_forums WHERE id = " + id.ToString();

А если id это string, то корректнее

cmd.CommandText = "SELECT COUNT(*) FROM subscribed_forums WHERE id = " + id.ToSqlString();

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

2.

catch (Exception e)
    {
    MessageBox.Show(e.ToString());
    restruct = true;
    }

Что будет показано пользователю?

Exeception: <exception type>
[...]blablabla
+ Stack Trace

Это действительно то что надо?

3.

idParam.Value = (int) r["id"];
nameParam.Value = r["ShortForumName"].ToString();

Первая и вторая строчки делают разные вещи?
Опять разные формы для семантически одинаковых операций?

P.S. Изложенное выше не есть аргумент в пользу какой то стороны в споре, просто мои use cases — без какого-либо анализа.

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

M>1.
M>

M>public static bool IsSubscribed(int id)
M>...
M>cmd.CommandText = "SELECT COUNT(*) FROM subscribed_forums WHERE id = " + id.ToString();  
M>

M>А если id это string, то корректнее

А если id это Form то вобще работать не будет.

M>2.

M>

M>catch (Exception e)
M>    {
M>    MessageBox.Show(e.ToString());
M>    restruct = true;
M>    }
M>

M>Что будет показано пользователю?

M>Exeception: <exception type>
M>[...]blablabla
M>+ Stack Trace

M>Это действительно то что надо?

Да.

M>3.

M>

M>idParam.Value = (int) r["id"];
M>nameParam.Value = r["ShortForumName"].ToString(); 
M>

M>Первая и вторая строчки делают разные вещи?

Безусловно.

M>Опять разные формы для семантически одинаковых операций?

С чего ты взял что они семантически одинаковы? В колонке id гарантированно int, а вот в ShortName может быть либо string, либо DBNull.

M>P.S. Изложенное выше не есть аргумент в пользу какой то стороны в споре, просто мои use cases — без какого-либо анализа.

Ага, особенно мне первый вариант понравился.

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

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

[...]

AVK>А если id это Form то вобще работать не будет.

Не понимаю причем тут Form.

M>>2.

M>>

M>>catch (Exception e)
M>>    {
M>>    MessageBox.Show(e.ToString());
M>>    restruct = true;
M>>    }
M>>

M>>Что будет показано пользователю?

M>>Exeception: <exception type>
M>>[...]blablabla
M>>+ Stack Trace

M>>Это действительно то что надо?

Хорошо. А мне обычно обрабатывать и форматировать приходится, в зависимости от типа исключения.

[...]

M>>3.

M>>

M>>idParam.Value = (int)r["id"];
M>>nameParam.Value = r["ShortForumName"].ToString(); 
M>>

M>>Первая и вторая строчки делают разные вещи?

AVK>Безусловно.

M>>Опять разные формы для семантически одинаковых операций?

AVK>С чего ты взял что они семантически одинаковы?

Я просто спрашиваю.

AVK> В колонке id гарантированно int,

Вижу

(int)r["id"]

AVK> а вот в ShortName может быть либо string, либо DBNull.

А вот здесь "ShortName может быть либо string, либо DBNull" слабо выражено:

r["ShortForumName"].ToString();

Скорее здесь сказано "а в ShortForumName лежит какой-то object, его надо преобразовать в "human-readable string that is culture-sensitive"".

Можно представить следующую семантику приведенного выше фрагмента (возможно семантика в Janus не такая):

* ShortName приходит в как string или DBNull
* DbNull пришедший из запроса означает что данные не найдены
* Для не найденных данных мы используем default значение ''

тогда я бы написал

idParam.Value = (int)r["id"]; 
nameParam.Value = (string)if_null( r["ShortForumName"], "" );

Мне было бы яснее и спокойнее, чем ToString()

AVK>Ага, особенно мне первый вариант понравился.

Какой "первый вариант"?

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

M>[...]

AVK>>А если id это Form то вобще работать не будет.

M>Не понимаю причем тут Form.

А при чем тут string?

M>Хорошо. А мне обычно обрабатывать и форматировать приходится, в зависимости от типа исключения.

Это просто недописки — воткнули для отладки, на нормальную обработку не заменили.

AVK>> а вот в ShortName может быть либо string, либо DBNull.

M>А вот здесь "ShortName может быть либо string, либо DBNull" слабо выражено:

M>

M>r["ShortForumName"].ToString();  
M>

M>Скорее здесь сказано "а в ShortForumName лежит какой-то object, его надо преобразовать в "human-readable string that is culture-sensitive"".

Ну так и есть. Подробности того что там лежит это уже более подробная информация.

M>Мне было бы яснее и спокойнее, чем ToString()

Это потому что вы незнакомы с ADO.NET.

AVK>>Ага, особенно мне первый вариант понравился.

M>Какой "первый вариант"?

Твой первый пример.

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

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

M>>[...]

AVK>>>А если id это Form то вобще работать не будет.

M>>Не понимаю причем тут Form.

AVK>А при чем тут string?

А, теперь вопрос понятен. Также как и int, DateTime etc., формирование SQL на основе string является типичной операцией. С Form мне кажется не такая типичная.
Мне легко, когда семантически одинаковые операции выражены синтаксически одинаково. Так что в приведенном use case — id.ToString() плохо, потому что для строки пришлось бы писать по-другому.


Кстати, а можно реально добиться синтаксиса id.ToSqlString() ? Я понимаю можно сделать

public string ToSqlString( int ) {}
...

[...]

AVK>>> а вот в ShortName может быть либо string, либо DBNull.

M>>А вот здесь "ShortName может быть либо string, либо DBNull" слабо выражено:

M>>

M>>r["ShortForumName"].ToString();  
M>>

M>>Скорее здесь сказано "а в ShortForumName лежит какой-то object, его надо преобразовать в "human-readable string that is culture-sensitive"".

AVK>Ну так и есть. Подробности того что там лежит это уже более подробная информация.

M>>Мне было бы яснее и спокойнее, чем ToString()

AVK>Это потому что вы незнакомы с ADO.NET.

Может быть. Вы имеете в виду что DBNull.ToString() == "" или что-то другое?
Все равно — я бы так не делал ( "ShortName может быть либо string, либо DBNull" намного лучше описывает суть дела, чем "в ShortForumName лежит какой-то object" )

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

M>А, теперь вопрос понятен. Также как и int, DateTime etc., формирование SQL на основе string является типичной операцией.

Абсолютно нетипичная. Поскольку в случае строк используются параметры.

M>Мне легко, когда семантически одинаковые операции выражены синтаксически одинаково. Так что в приведенном use case — id.ToString() плохо, потому что для строки пришлось бы писать по-другому.

Это всего лишь экономия на коде, с параметрами возиться дольше. Опять же к ToString это никакого отношения не имеет.

M>Кстати, а можно реально добиться синтаксиса id.ToSqlString() ?

Не понял вопроса.

M>>>Мне было бы яснее и спокойнее, чем ToString()

AVK>>Это потому что вы незнакомы с ADO.NET.

M>Может быть. Вы имеете в виду что DBNull.ToString() == "" или что-то другое?
M>Все равно — я бы так не делал ( "ShortName может быть либо string, либо DBNull" намного лучше описывает суть дела, чем "в ShortForumName лежит какой-то object" )

Ага, и плевать что это в несколько раз больше кода?

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

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

M>>А, теперь вопрос понятен. Также как и int, DateTime etc., формирование SQL на основе string является типичной операцией.

AVK>Абсолютно нетипичная. Поскольку в случае строк используются параметры.

Т.е. pattern такой, а правильно понимаю?

1. Если параметрами SQL-statement являются только int'ами - пишем "sql ..." + <int>.ToString()
2. Если не все из них являются int'ами 
  2.1 Если не нужно sql-statement в строке используем параметры (binding)
  2.2 Если нужна строка sql-statement (нечасто случается но бывает) - используем ???

А если не такой, то какой?

[...]

M>>Кстати, а можно реально добиться синтаксиса id.ToSqlString() ?

AVK>Не понял вопроса.

можно ли сделать так, чтобы id.ToSqlString() работало?

Например, написав где-нибудь string ToSqlString( int ).

M>>>>Мне было бы яснее и спокойнее, чем ToString()

AVK>>>Это потому что вы незнакомы с ADO.NET.

M>>Может быть. Вы имеете в виду что DBNull.ToString() == "" или что-то другое?
M>>Все равно — я бы так не делал ( "ShortName может быть либо string, либо DBNull" намного лучше описывает суть дела, чем "в ShortForumName лежит какой-то object" )

AVK>Ага, и плевать что это в несколько раз больше кода?

Это правильный код — наверное бы писал. Вопрос, как много, как скоро бы надоело и какие бы абстракции я ввел чтобы стало лучше.

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

M>Т.е. pattern такой, а правильно понимаю?

Нет никакого паттерна. Просто если параметр целое то надобности в подъеме полноценной механики нет.

AVK>>Не понял вопроса.

M>можно ли сделать так, чтобы id.ToSqlString() работало?

Если это int то нет.

AVK>>Ага, и плевать что это в несколько раз больше кода?

M>Это правильный код — наверное бы писал.

Правильный этот тот который работает.

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

M>>Это правильный код — наверное бы писал.
AVK>Правильный этот тот который работает.

К сожалению, это не единственный критерий "правильности" кода. Необходимый, но не единственный.

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

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

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

я отвечал Владу по этому поводу.
AVK>Описания проблем я там не увидел.

А вот это:

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

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

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

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

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

Если нужно, то:

string str = string.Format("{0} {1} {2:0.00} {3}", 1, 2, 3.0, DateTime.Now);

Вот только эти если тут не причем. Главное, что очень часто нужно просто результат по умолчанию.

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

M>>>Это правильный код — наверное бы писал.
AVK>>Правильный этот тот который работает.

ГВ>К сожалению, это не единственный критерий "правильности" кода. Необходимый, но не единственный.

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

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

ГВ>[q]
ГВ>Проблема метода ToString() состоит в неопределённости его семантики.

Это не проблема, это опять философия и принципы.

ГВ> Что у него на выходе? Будут ли обрезаны незначащие нули у типов с плавающей точкой? С какой точностью он выведет данные?

Зависит от настроек системы. В 99% случаев это именно тот вариант, который нужен.

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

M>>>>Это правильный код — наверное бы писал.
AVK>>>Правильный этот тот который работает.
ГВ>>К сожалению, это не единственный критерий "правильности" кода. Необходимый, но не единственный.
VD>Сайдемся на том, что правильный код — это код который работает и не создает проблем. Так вот этот именн такой.

Это ты о котором?

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

M>>Что будет показано пользователю?
M>>Exeception: <exception type>
M>>[...]blablabla
M>>+ Stack Trace
M>>Это действительно то что надо?
AVK>>Да.
M>>Хорошо. А мне обычно обрабатывать и форматировать приходится, в зависимости от типа исключения.
AVK>Это просто недописки — воткнули для отладки, на нормальную обработку не заменили.

Вот и первое подтверждение тезису:

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

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

VD>Главное, что очень часто нужно просто результат по умолчанию.
Об этом ты уже говорил:

VD> Они [требования — ГВ.] в 90% случаев не предявляются.

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

Про одну ситуацию AVK уже сказал

Автор: AndrewVK
Дата: 14.11.04

:

Это просто недописки — воткнули для отладки, на нормальную обработку не заменили.

Какие ещё варианты?

Да, учти ещё, что далеко не всегда удобно получить "3.24465830E-3" вместо "0.003245", а преобразование строки в строку по сути, тривиально.

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

ГВ>>Проблема метода ToString() состоит в неопределённости его семантики.
AVK>Это не проблема, это опять философия и принципы.
Ну, тогда нам и спорить-то не о чем. Ты попросту не видишь проблемы там, где она есть.

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

ГВ>Это ты о котором?

О xxx.ToString()

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

VD> Что-же можешь вместе с ПК соблюдать правила разных ОЦП и т.п. даже во прики банальному разуму.

Почему-то вспомнилась ода Ломоносова:

Дерзайте, ныне ободренны,
Реченьем вашим показать,
Что может собственных платонов
И быстрых разумов невтонов      // <- тут бы надо "банальных разумов VladD2"
Земля российская рождать.

Извините, не удержался

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

E>Почему-то вспомнилась ода Ломоносова:
E>

E>Дерзайте, ныне ободренны,
E>Реченьем вашим показать,
E>Что может собственных платонов
E>И быстрых разумов невтонов      // <- тут бы надо "банальных разумов VladD2"
E>Земля российская рождать.
E>

E>Извините, не удержался

Вообще-то мог бы от оскарблений то и удержаться. Темболее, что до Ломоносва, с точки зрения стихотворчества, ты точно недорос.

AndrewVK,

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

Я уже не хотел продолжать, но на работе столкнулись. Не удержался, чтобы не упомянуть.

Итак, допустим, есть некая библиотека-framework для написания unit-тестов на C#. Как обычно, unit-тест состоит из некоторого количества "утверждений" (assertion), которые должны быть истинными. Если некоторое "утверждение" оказывается ложным, framework выводит соответствующее сообщение. В частности, есть и assert, предназначенный для сравнения двух результатов. Например (псевдокод):

Test.AssertEqual( obj1, obj2 );

Если объекты окажутся разными, framework выдаст соответствующее сообщение, что, мол: "ожидалось ..., а получили ...", где вместо троеточий будет выдано текстовое представление объектов.

И вот тут-то начинается самое интересное: для получения этого текстового представления данная библиотека использует obj.ToString().

В результате, если, скажем, в качестве obj1 и obj2 были массивы целых, но они оказались не равными, мы получим чрезвычайно "информативное" сообщение примерно следующего содержания:

array of int expected, array of int received.

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

P.S.

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

Уточню: внешний по отношению к объекту, строковое представление которого нужно получить.

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

ГВ>

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

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

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

ГВ>>

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

U>Не понял, а как должна выглядеть функция преобразования в строку, чтобы у нее не было неопределенности в семантике?

А никак в данном случае, поскольку сама задача "обобщённого преобразования в человекочитаемую строку" содержит неопределённость, будучи поставленной в таких терминах. Понимаешь, для сложного объекта, состоящего из нескольких полей, имеется как минимум n! способов размещения представления полей в результирующей строке. А поиск некоего "среднеудовлетворительного" представления — задача, которая успешно решается в о-о-очень редких случаях. "Успешно" означает, что представление оказалось действительно удовлетворяющим требованиям разных наблюдателей.

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

ГВ>>Угу, а кто его серебряной пулей называет?
VD>Ты и ПК. И на этом основании запретили добавлять в классы все что не относитс к эксесорам данных.
Кто же запрещает-то. Нравится — на здоровье!

ГВ>>Лучше сам расскажи. А ещё лучше — объясни, почему приняты те или иные решения. В лес посылать мы все тут умеем.
VD>Удбно, логично, практично. Что еще нужно?
Мда. Исчерпывающее объяснение.

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

ГВ>>Это ты о котором?
VD>О xxx.ToString()

Угу. Только он "работает и не создаёт проблем" на самом деле в очень ограиченном числе случаев.