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

ПК>

Есть два класса: 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>С верой спорить бессмысленно.
Угу. С любой. С верой в миллион леммингов — тоже.