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

ГВ>>Ну что, моя очередь ставить двойки?
C>Попробуйте — снова посажу Вас в лужу.

Ты не увиливай, громовержец. Я тебя спросил, что считать определением типа, которым ты руководствуешься. Ответ будет?

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

ГВ>>>Ну что, моя очередь ставить двойки?
C>>Попробуйте — снова посажу Вас в лужу.

ГВ>Ты не увиливай, громовержец. Я тебя спросил, что считать определением типа, которым ты руководствуешься. Ответ будет?

И я ответил, а Вы троллите. Не утруждайтесь — на остальные Ваши попытки потроллить я отвечать не стану.

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

E>>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:

struct IOrder {
E>>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>};

C>Да, это вполне корректный интерфейс, хотя и костыль, т.к. придет Вася Пупкин в проект и порушит всю чистоту конструкции, добавив неабстрактный метод.

А кто сказал, что интерфейс должен содержать только абстрактные методы? Чем не абстрактные методы противоречат "интерфейсу"?

E>>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...
C>Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?

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

E>>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...
C>Это контракт не интерфейса, а объекта, который реализует данный интерфейс.

Контракт формулируется для интерфейса, а реализуется — реализующим интерфейс классом.

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

C>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.
C>А строки "они и в африке" строки.
Да-да-да
А что творится айфоне? А с китайским языком знаешь какие приколы бывают?

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


C>>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.
C>>А строки "они и в африке" строки.
NBN>Да-да-да
NBN>А что творится айфоне?
И что же творится в айфоне?

NBN>А с китайским языком знаешь какие приколы бывают?
Нет, расскажите.

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

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

E>>>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:

struct IOrder {
E>>>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>>};

C>>Да, это вполне корректный интерфейс, хотя и костыль, т.к. придет Вася Пупкин в проект и порушит всю чистоту конструкции, добавив неабстрактный метод.

ГВ>А кто сказал, что интерфейс должен содержать только абстрактные методы? Чем не абстрактные методы противоречат "интерфейсу"?
Абсолютно всем. Интерфейс с методами — не интерфейс, а просто класс.

E>>>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...
C>>Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?

ГВ>При том, что эти утверждения — неотъемлемая часть интерфейса, которую могут (и должны) учитывать его пользователи.
Это может быть неотъемлимой частью объектов классов, реализующих данный интерфейс, но уж никак не интерфейса.

E>>>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...
C>>Это контракт не интерфейса, а объекта, который реализует данный интерфейс.

ГВ>Контракт формулируется для интерфейса, а реализуется — реализующим интерфейс классом.
Контракт формируется для класса, а не для интерфейса. Интерфейс это и есть контракт.

Вам не наскучило пороть чушь?

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

E>>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:

struct IOrder {
E>>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>};

C>Да, это вполне корректный интерфейс,
Значит ты используешь слово "интерфейс" в этаком COM-образном смысле, а не в смысле "интерфейс класса". Хорошо, давай придерживаться такой терминологии...

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

C>т.к. придет Вася Пупкин в проект и порушит всю чистоту конструкции, добавив неабстрактный метод.
Во-первых, это только вопрос об определениях. Интерфейс же нужен не для того, чтобы состоять только из чисто виртуальных методов, а для того, чтобы формально зафиксировать какой-то аспект взаимодействия объектов из объектной модели... Если используемые средства разработки (как COM, например) навязывают виртуальность всех аспектов интерфейса, то невиртуальные части в нём недопустимы, а если не навязывает, то от чего бы и нет? Это к основной, главной и единственной задачи интерфейса -- формализовать какой-то аспект взаимодействия с реализующим интерфейс объектом, не имеет прямого отношения -- виртуальный какой-то метод или нет...

E>>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...

C>Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?
При том, что интерфейс -- это формализация взаимодействия. Она требует декларации и соблюдения контракта, иначе ты не сможешь реализовать ни одну из сторон взаимодействия: ни реализовать интерфейс, ни воспользоваться им...

E>>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...

C>Это контракт не интерфейса, а объекта, который реализует данный интерфейс.

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

---

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

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

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

Ну то, что ты чего-то не видишь, может обозначать всего лишь узость кругозора

Вот тебе проблемка: что таки считать за один символ в строке? Вот положим тот же юникод возьмём. Там бывают такие коды нехорошие, которые к предыдущим буквам диакритические знаки пририсовывают. Вот что соответствует одному символу в этом случае? знаки "U" и "приписать умляут к предыдущему символу" -- это два символа или один?

или вот тебе другая проблемка. Если у тебя есть ивритско-английская строка, например, то у неё есть два порядка итерации букв. Графический и логический. Какой из порядков должна предоставлять правильная строка по умолчанию?

А ещё есть довольно много буквочек, которые в юникоде не представлены. Например, это часть кантонских иероглифов. Зато есть куча других кодировок, популярных в ЮВА, где они все представлены. Вот как хранить в "правильной" строке такого рода символы?

А ещё у реальных строчек, которые в книжках встречаются, есть форматирование. Например строка может быть Allcfps, или иероглифы могут быть того или иного стиля, или текст может быть полужирным, или курсивом, цифры могут быть такими, как их принято писать в Европе (когда 9 и 6 пишется вровень с большой 0), а могут быть такими, какими их принято писать в США (когда кружочки цифр 9 и 6 пишут вровень с маленькой о, а хвосты соответственно торчат вниз и вверх), а ещё могут быть верхние и нижние индексы, ну и т. д... Это всё должна нормальная строка поддерживать или нет?

Вот, например, как в "нормальную" строку должны попадать верхние индексы (которыми обычно сноски обозначают)?..

Ну и так далее...

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

ГВ>>А кто сказал, что интерфейс должен содержать только абстрактные методы? Чем не абстрактные методы противоречат "интерфейсу"?
C>Абсолютно всем. Интерфейс с методами — не интерфейс, а просто класс.

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

E>>>>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...
C>>>Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?
ГВ>>При том, что эти утверждения — неотъемлемая часть интерфейса, которую могут (и должны) учитывать его пользователи.
C>Это может быть неотъемлимой частью объектов классов, реализующих данный интерфейс, но уж никак не интерфейса.

Мы сейчас говорим о публичных контрактах, верно? Такой контракт всегда подразумевает две (как минимум) взаимодействующие стороны. Одна сторона — реализатор, другая — пользователь. Без реализатора контракт неосуществим, но без пользователя — вообще нонсенс. Но пользователь у нас взаимодействует с интерфейсом (в смысле — взаимодействует-то он, конечно, с реализующим классом, но посредством интерфейса), а значит, и контракт должен формулироваться относительно интерфейса. Дальше из контракта, связанного с интерфейсом логично выводится спецификация и требования к реализации — вот это уже то, на основании чего создаётся реализующий класс. Кроме того, классов, реализующих интерфейс может быть много, и проще и понятнее связать контракт с интерфейсом, а не с классом.

Всё просто, как видишь.

E>>>>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...
C>>>Это контракт не интерфейса, а объекта, который реализует данный интерфейс.
ГВ>>Контракт формулируется для интерфейса, а реализуется — реализующим интерфейс классом.
C>Контракт формируется для класса, а не для интерфейса. Интерфейс это и есть контракт.

Не-а. Интерфейс — это часть контракта.

C>Вам не наскучило пороть чушь?

Знаешь, есть вопросы на которые в принципе нельзя отвечать. Вот, например: ты перестал пить коньяк по утрам?

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

ГВ>>Ты не увиливай, громовержец. Я тебя спросил, что считать определением типа, которым ты руководствуешься. Ответ будет?
C>И я ответил, а Вы троллите. Не утруждайтесь — на остальные Ваши попытки потроллить я отвечать не стану.

Короче говоря, обопрёмся на википедию. Хорошо.

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

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

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

C>>я могу сказать что С++ для тебя это Си с классами(если помнишь), и обсуждать темы такого порядка ты может только на уровне "Мне это не нравится и ВСЁ".
C>По сути что можете сказать?
C>Хотите услышать чем вариант дотнет лучше шаблона из Вашего примера?
C>Тем, что ошибка будет указана прямо в редакторе во время набора на строке f<B>(), где B — класс, не реализующий интерфейс, а в С++ только во время компилляции будет выдана ошибка при чем совсем в другом месте — на вызове
C>t.f() — будет указано, что класс B НЕ имеет метода f().

Это проблема языка или IDE? Я работал под расширениями емакса, которые производят все операции проверки шаблона в редакторе, так что это далеко не проблема языка, а среды разработки.

C>>Что за цитаты, примеры кода? Приведи реальный пример когда из-за кривизны языка, а не программера получаются неявные ошибки не описанные и заранее не продуманные в языке.
C>Ошибки заранее не продуманные в языке? Это Вы сильно сказали. К сожалению, мне слишком далеко до Вашего интеллектуального уровня, чтоб был смысл продолжать этот неконструктивный спор.

Жаль что моя идея не дошла, наверно сильно завернул, под ошибками языка, которые приводят к неявным проблемам, но для которых есть "обходы" я называю к примеру множественное наследование приводящее к брилианту смерти, в С++ это обходится виртуальным наследованием, в управляемых языках запретом имплементации в "виртуальных" базовых классов, и кто вам сказал что интерфейс это и есть контракт? Интерфейсом можно описать часть контракта, по вашему это называется "Костыль", а что такое на самом деле контракт в шарпе и какие утилиты используются для полного цикла использования контракта почитайте у мелкомягких:
http://research.microsoft.com/en-us/projects/contracts/

E>Ну и так далее...
Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
0. Они не immutable.
1. Они слишком сильно сосредоточены на бинарном представлении.

Строки дотнета тоже не лишены недостатков, но об этих недостатках дефолтным строкам стандартной библиотеки плюсов еще приходится только мечтать.

Здравствуйте, Erop, Вы писали:
C>>Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.
E>А как у System.String с Shift-JIT, например?
А что с ней не так?

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

C>>>я могу сказать что С++ для тебя это Си с классами(если помнишь), и обсуждать темы такого порядка ты может только на уровне "Мне это не нравится и ВСЁ".
C>>По сути что можете сказать?
C>>Хотите услышать чем вариант дотнет лучше шаблона из Вашего примера?
C>>Тем, что ошибка будет указана прямо в редакторе во время набора на строке f<B>(), где B — класс, не реализующий интерфейс, а в С++ только во время компилляции будет выдана ошибка при чем совсем в другом месте — на вызове
C>>t.f() — будет указано, что класс B НЕ имеет метода f().

C>Это проблема языка или IDE? Я работал под расширениями емакса, которые производят все операции проверки шаблона в редакторе, так что это далеко не проблема языка, а среды разработки.

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

C>>>Что за цитаты, примеры кода? Приведи реальный пример когда из-за кривизны языка, а не программера получаются неявные ошибки не описанные и заранее не продуманные в языке.
C>>Ошибки заранее не продуманные в языке? Это Вы сильно сказали. К сожалению, мне слишком далеко до Вашего интеллектуального уровня, чтоб был смысл продолжать этот неконструктивный спор.

C>Жаль что моя идея не дошла, наверно сильно завернул, под ошибками языка, которые приводят к неявным проблемам, но для которых есть "обходы" я называю к примеру множественное наследование приводящее к брилианту смерти, в С++ это обходится виртуальным наследованием, в управляемых языках запретом имплементации в "виртуальных" базовых классов, и кто вам сказал что интерфейс это и есть контракт? Интерфейсом можно описать часть контракта, по вашему это называется "Костыль", а что такое на самом деле контракт в шарпе и какие утилиты используются для полного цикла использования контракта почитайте у мелкомягких:
C>http://research.microsoft.com/en-us/projects/contracts/
Вы что же совсем не понимаете разницы между interface as contract и между code contracts?

Действительно, спорить мне с Вами не о чем.

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

C>>http://research.microsoft.com/en-us/projects/contracts/
C>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?

Прикольный постинг по этому поводу: API Design Myth: Interface as Contract

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

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

C>>>http://research.microsoft.com/en-us/projects/contracts/
C>>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?

ГВ>Прикольный постинг по этому поводу: API Design Myth: Interface as Contract

А никто и не утверждал, что интерфейс является полным контрактом класса. Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе точно так же как и code сontracts в конкретной реализации интерфейса — в классе, описывают пред- и пост- условия в методе или еще более специфичные соглашения, как тут вчера приводили о порядке вызовов методов, т.п. — это тоже контракты КЛАССА. У классов естественно может быть целое множество контрактов, которое в совокупности составляет полный контракт этого класса. Вы же пытаетесь смешивать теплое с мягким, грубейше нарушая принцип single responsibility, когда добавляете КОД в интерфейс. О чем Вам, кстати, и господин WolfHound твердил.

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

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

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

C>>>>http://research.microsoft.com/en-us/projects/contracts/
C>>>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?
[...]
C>А никто и не утверждал, что интерфейс является полным контрактом класса.

Я о том же, интерфейс — это не контракт, а вы разве не писали обратного?
http://rsdn.ru/forum/flame.comp/3412734.1.aspx

Автор: criosray
Дата: 01.06.09

Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

То что он ничего не может делать это с какой стороны посмотреть и что делать, а вот контракт как раз должен делать кое-что, в чём заключается его цель.

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

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

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

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

C>>>>>http://research.microsoft.com/en-us/projects/contracts/
C>>>>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?
C>[...]
C>>А никто и не утверждал, что интерфейс является полным контрактом класса.

C>Я о том же, интерфейс — это не контракт, а вы разве не писали обратного?
C>http://rsdn.ru/forum/flame.comp/3412734.1.aspx

Автор: criosray
Дата: 01.06.09

Вы читать умеете? Или дальше первого предложения не осилили?

А никто и не утверждал, что интерфейс является полным контрактом класса. [b]Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе точно так же как и code сontracts в конкретной реализации интерфейса — в классе, описывают пред- и пост- условия в методе или еще более специфичные соглашения, как тут вчера приводили о порядке вызовов методов, т.п. — это тоже контракты КЛАССА. У классов естественно может быть целое множество контрактов, которое в совокупности составляет полный контракт этого класса. Вы же пытаетесь смешивать теплое с мягким, грубейше нарушая принцип single responsibility, когда добавляете КОД в интерфейс. О чем Вам, кстати, и господин WolfHound твердил.[/b]

Специально для Вас выделил ключевое.

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

...
C>Специально для Вас выделил ключевое.

Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:

Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

Потом вы пишете

А никто и не утверждал, что интерфейс является полным контрактом класса

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

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

C>Здравствуйте, criosray, Вы писали:
C>...
C>>Специально для Вас выделил ключевое.
C>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:
C>

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

C>Потом вы пишете
C>

C>А никто и не утверждал, что интерфейс является полным контрактом класса

C>Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:
C>Колесо — это чисто машина.
По такой логике criosray должен был написать, что интерфейс — это чисто класс. Вроде такого не было