Здравствуйте, 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()

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