Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата korvin @ 19.03.11, 19:33

Цитата D_KEY @ 19.03.11, 19:08

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

я ничего не понял =)

Суть в том, что описывая абстрактный класс я почти всегда делаю открытый интерфейс невиртуальным(чтобы клиенты оставались без изменений, если что-то поменяется в реализации и внутренней декомпозиции), все чисто виртуальные методы - закрыты, а виртуальные методы с реализацией по умолчанию - в protected.
Интерфейсы же открыты и требуют переопределения методов. То есть некоторым образом смешиваются интерфейсы клиентов и наследников.

У меня сейчас несколько измененное состояние сознания в связи с болезнью, температурой и слабостью. Извините все, если что не так

Цитата MyNameIsIgor @ 19.03.11, 19:30

Я инженер, следовательно, не пишу трактаты, а на практике выращиваю столбы под лунным светом, и если голимая теория не помогает мне в практической деятельности, то я с ней поступаю как всегда поступают с теорией, не соответствущей практике: "в печку её"

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

Добавлено 19.03.11, 19:58

Цитата D_KEY @ 19.03.11, 19:51

Суть в том, что описывая абстрактный класс я почти всегда делаю открытый интерфейс невиртуальным(чтобы клиенты оставались без изменений, если что-то поменяется в реализации и внутренней декомпозиции), все чисто виртуальные методы - закрыты, а виртуальные методы с реализацией по умолчанию - в protected.
Интерфейсы же открыты и требуют переопределения методов. То есть некоторым образом смешиваются интерфейсы клиентов и наследников.

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

Цитата korvin @ 19.03.11, 19:54

интерфейсы не требуют переопределения методов =) они требуют реализации методов

Хорошо, они требуют реализации. В данном случае разница не велика.

Цитата

больше ничего сказать не могу, не люблю языки с множеством различных спецификаторов (protected, virtual, etc), они только усложняют и запутывают =)

Скажем так, они могут усложнить и запутать
Не в них суть. Суть в разделении интерфейса для клиентов и интерфейса для наследников("реализаторов" если речь об интерфейсах).

Сообщение отредактировано: D_KEY - 19.03.11, 20:07

Цитата D_KEY @ 19.03.11, 19:46

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

Так я разве отказываюсь? Я говорю, что модель уже несёт в себе семантику. В ответ слышу: нет, не несёт. Вот и вся разница.

Цитата D_KEY @ 19.03.11, 19:46

CopyConstructable описан и в нынешнем стандарте и auto_ptr ему не соответствует, т.к. консруктор копирования принимает неконстантную ссылку и модифицирует переданный ему объект(думаю, что ты это знаешь).

Не знал Как бы то ни было, хочешь, напишу смарт, принимающий ссылку на константный объект, но имеющий семантику перемещения? И всё по сигнатурам будет! Да вот только не по семантике...

Цитата D_KEY @ 19.03.11, 19:46

А рассмотреть интерфейс как, скажем по простому, отдельно описанную часть открытого интерфейса класса ты не хочешь?

Ну, а мы разве не этим сейчас занимаемся?

Цитата korvin @ 19.03.11, 19:47

как интерфейс может знать реализацию метода? я не зря использовал эпитет "конкретная".
вот тебе абстрактный интерфейс:

interface File {
    Open,
    Close,
    Read,
    Write
}

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

Хороший интерфейс. Мне нравится. Нераскрытой семантики - хоть жопой жуй. Вот скажите, когда я только сделаю Open на файле, текущая позиция где будет? В начале? Или в конец? А, может, на пятом байте? А позиции чтения и записи связаны или нет? Если я сделаю Read, то потом Write будет с позиции после прочитанной или нет? И что-то не вижу ответа на свои вопросы в объявлении интерфейса... Наверно, теорию надо почитать - там всё есть на все случаи моей страшной как атомная война жизни Простите великодушно, но я за ответами в документацию лучше полезу, и плевать на сколько "не ООПэшно" это будет. Ну, а теперь, korvin, не отвечая на мои вопросы, напишите функцию, делающую с этим интерфейсом что-то более-менее сложнее "Hello, world", а я вам предоставлю реализацию интерфейса, на которой ваш код ласты склеит.

Цитата korvin @ 19.03.11, 19:54

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

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

Цитата MyNameIsIgor @ 19.03.11, 20:12

Цитата D_KEY @ 19.03.11, 19:46

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

Так я разве отказываюсь? Я говорю, что модель уже несёт в себе семантику. В ответ слышу: нет, не несёт. Вот и вся разница.

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

Цитата

Как бы то ни было, хочешь, напишу смарт, принимающий ссылку на константный объект, но имеющий семантику перемещения? И всё по сигнатурам будет! Да вот только не по семантике...

Более того, ты сможешь при желании и передать его туда, куда не нужно, неверно реализовав интерфейс. Только что это доказывает?

Цитата

Вот скажите, когда я только сделаю Open на файле, текущая позиция где будет? В начале? Или в конец? А, может, на пятом байте? А позиции чтения и записи связаны или нет? Если я сделаю Read, то потом Write будет с позиции после прочитанной или нет? И что-то не вижу ответа на свои вопросы в объявлении интерфейса...

Ты можешь уточнить этот интерфейс впоследствии. Вполне возможно, что на некоем уровне достаточно и представленного интерфейса...

Цитата D_KEY @ 19.03.11, 20:38

Тебе говорят о том, что интерфейс несет лишь ту семантику, которая может, собственно, следовать из интерфейса, т.е. та, что идет от сигнатуры методов.

Ну, в таком случае "от сигнатуры" ответь на мои вопросы korvin'у.

Цитата D_KEY @ 19.03.11, 20:38

Более того, ты сможешь при желании и передать его туда, куда не нужно, неверно реализовав интерфейс. Только что это доказывает?

Что существует семантика, кроме объявленного в коде названия метода.

Цитата D_KEY @ 19.03.11, 20:38

Ты можешь уточнить этот интерфейс впоследствии. Вполне возможно, что на некоем уровне достаточно и представленного интерфейса...

Несмешно. Очень хочется увидеть этот уровень. Который файл открыл и пишет в него хз с какой позиции. Морда архитектора этого ужаса явно просит кирпича поувесестей.

Сообщение отредактировано: MyNameIsIgor - 19.03.11, 20:54

Цитата MyNameIsIgor @ 19.03.11, 20:54

Цитата D_KEY @ 19.03.11, 20:38

Тебе говорят о том, что интерфейс несет лишь ту семантику, которая может, собственно, следовать из интерфейса, т.е. та, что идет от сигнатуры методов.

Ну, в таком случае "от сигнатуры" ответь на мои вопросы korvin'у.

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

Цитата

Цитата D_KEY @ 19.03.11, 20:38

Более того, ты сможешь при желании и передать его туда, куда не нужно, неверно реализовав интерфейс. Только что это доказывает?

Что существует семантика, кроме объявленного в коде названия метода.

Мне не понятно, как язык должен контролировать семантику, выходящую за рамки языковых возможностей?

Цитата

Цитата D_KEY @ 19.03.11, 20:38

Ты можешь уточнить этот интерфейс впоследствии. Вполне возможно, что на некоем уровне достаточно и представленного интерфейса...

Несмешно. Очень хочется увидеть этот уровень. Который файл открыл и пишет в него хз с какой позиции. Морда архитектора этого ужаса явно просит кирпича поувесестей.

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

Цитата D_KEY @ 19.03.11, 21:52

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

Короче, ясно: нет ответа. И я как всегда прав: часть семантики интерфейса находится в документации и неотделима от него. Без документации интерфейс использовать невозможно.

Цитата D_KEY @ 19.03.11, 21:52

Мне не понятно, как язык должен контролировать семантику, выходящую за рамки языковых возможностей?

Да, гля, я же об этом и толдычу! Не может. По крайней мере сейчас. А потому решение "давайте по умолчанию будем считать одинаковыми методы интерфейсов, совпадающие по названию и сигнатуре" ни в какие ворота не лезет. Если сделать совершенное фантастическое предположение, что компилятор доку читать не умеет, то придём к совершенно естественному выводу: одноимённые и совпадающие по сигнатуре требования методов в разных интерфейсах являются разными хотя бы потому, что наша информация о них не полная. Не имеем мы никаких основания считать их одинаковыми.

Цитата D_KEY @ 19.03.11, 21:52

Под файлом может пониматься поток данных, у которого есть лишь одна позиция - текущая.

А может и не пониматься. Как мне из кода понять, понимается или нет? А ведь ты предлагаешь понимать, только потому, что по сигнатурам совпадают.

Цитата D_KEY @ 19.03.11, 21:52

Но соглашусь, что пример несколько надуман...

Скажем прямо: он просто фантастичен.

Сообщение отредактировано: MyNameIsIgor - 19.03.11, 22:19

Цитата MyNameIsIgor @ 19.03.11, 20:12

Ну, а теперь, korvin, не отвечая на мои вопросы, напишите функцию, делающую с этим интерфейсом что-то более-менее сложнее "Hello, world", а я вам предоставлю реализацию интерфейса, на которой ваш код ласты склеит.

Когда-то нечто подобное я тоже предлагал. Совсем по другому поводу, правда, но это неважно. Сам факт того, что это возможно, переводит доводы теоретических идеологов теории ИнтерфейсноОриентированногоПрограммирования на уровень утопического идеализма.
К примеру я могу много рассуждать на темы Общей Теории Относительности, Релятивисткой Теории Гравитации, Квантовой Теории, о динамине Чёрных Дыр в конце концов (даже рассчитал одну такую, которая чисто теоретически могла бы возникнуть на энергиях БАК), космологии и эволюции галактический сверхскоплений, нескольких вариантов Струнных Теорий и даже расскажу о связи упоминавшихся в Half-Life 2 пространствах Калаби-Яу с реалиями нынешней теорфизики. Да, читал много, большую часть осмыслил, ещё большую осилил пониманием. Вот только я себе не дам ни грамма шансов против практика в теоретической физике в совместной дискуссии. Я реалист и хорошо понимаю разницу между эрудитом и специалистом.

Сообщение отредактировано: Qraizer - 19.03.11, 23:38

Цитата MyNameIsIgor @ 19.03.11, 22:16

Без документации интерфейс использовать невозможно.

Какой интерфейс? Да и что можно использовать без документации, если уж на то пошло?

Цитата

Цитата D_KEY @ 19.03.11, 21:52

Мне не понятно, как язык должен контролировать семантику, выходящую за рамки языковых возможностей?

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

То есть концепты можно выкинуть за ненадобностью? Ведь требуем мы именно этого... Заданное название и сигнатуру.

Цитата

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

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

Добавлено 20.03.11, 00:40

Цитата Qraizer @ 19.03.11, 23:32

Я реалист и хорошо понимаю разницу между эрудитом и специалистом.

Все бы ничего, но к чему это было сказано, ума не приложу... Уж если кончаются аргументы, то можно об этом сказать или просто промолчать.

D_KEY, я и молчал. Не из-за недостатка агрументов, а из-за отсутствия новых аргументов. Свои я высказал двумя прошлыми постами, только ты не захотел слушать. А сказано было ни более ни менее, чем "движения нет, сказал мудрец брадатый" и дальше ещё три строчки. Считай, что я подписался под постами MyNameIsIgor-я. А вообще, читай первый абзатц. Второй - то лирика.
Абстрактный класс... интерфейс... концепт... Жизнь, D_KEY, жизнь. Я ж просил попытаться выразить свои доводы не кодом, но документацией. Я ж кода не приводил почему, думаешь? Не в коде дело, а в нашедших в нём своё отражение идеях программера. И ещё - в человеческом факторе. Давай я не буду напоминать об интерфейсе операции / для целочисленных аргументов. И твоём желании считать по дефолту все методы константными, кроме явно указанных как наоборот. Тоже утопично, если подумать, и дело совсем не в обратной совместимости.

Сообщение отредактировано: Qraizer - 20.03.11, 01:50

Цитата D_KEY @ 20.03.11, 00:36

Какой интерфейс? Да и что можно использовать без документации, если уж на то пошло?

Ты сам отвечаешь на свой вопрос: практически все интерфейс нельзя использовать без документации. Напомню, что всё началось с

Цитата MyNameIsIgor @ 19.03.11, 18:45

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

и удивления а-ля "ты с какой луны свалился?"

Цитата korvin @ 19.03.11, 18:58

нет, единственный контракт, который создает интерфейс -- именование множества сообщений, которые может обработать объект и всё.

Цитата D_KEY @ 19.03.11, 19:00

Вот такие хреновые методы Тебе не кажется, что название должно отражать, что делает метод?

Вот через две страницы мы всего лишь пришли к пониманию того, что сигнатура и название - это ещё далеко не всё.

korvin'у не читать

Да и то надо подождать korvin'а, а то Роб Пайк вполне себе мог брякнуть, что ему вовсе не интересна текущая позиция в файле.

Цитата D_KEY @ 20.03.11, 00:36

То есть концепты можно выкинуть за ненадобностью? Ведь требуем мы именно этого... Заданное название и сигнатуру.

Не только не выкидывать, но ещё и контракты добавить по соответствующему предложению в комитете.

Цитата D_KEY @ 20.03.11, 00:36

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

Ну, вот, опять двадцать пять... А можно я ещё одну ересь скажу? Я вообще не вижу необходимости иметь в языке "интерфейсы". Меня вполне устроит множественное наследование.
Я ведь уже прямо на пальцах показал, что интерфейс зависит от недоступной для компилятора информации. Я за компилятор для того и посажен, чтобы решать. А он - обычная тупая сконина, которая должна слушаться, а не палки в колёса вставлять своими альтернативными взглядами на жизнь с далеко идущими выводами.

Цитата D_KEY @ 20.03.11, 00:36

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

Вот именно - в динамике. Во-первых, у нас статически типизированный язык. Во-вторых, мы хотим позднего связывания. Опа - и мы имеем интерфейсы.
Потому первая крайне важная для моего ответа, известная всем вещь: использующий интерфейс код ничего не знает о его реализациях. Это крайне важное отличие, ибо шаблон знает в момент компиляции тот тип, который ему дают как реализующий нужный концепт.
Второй важный момент: мы громогласно заявляем, что реализуем интерфейс, и в то же время скромненько в стороночке молчим о релизуемых нами концептах. Потому что не знаем мы в каких шаблонах будут использовать написанный нами класс. Вопросы соответствия класса концепту будем решать не мы, а тот, кто наш класс использует. Ему специально по такому праздничному случаю и маппинг дали.
А вот теперь давай подумаем, что нам надо, чтобы убедиться в соответствии типа концепту? Нам нужен механизм проверки. Почему был выбран именно механизм по названию метода и его сигнатуре? А потому что для иной проверки у компилятора нет информации. В отличие от интерфейсов, где автор реализации явно ему сказал, что реализовал. И вот поэтому, если нас не устраивает имеющийся механизм, то нас поджидает жопа альтернатива: говорить какие концепты мы реализовали. Вот если бы так было, то я бы тоже сказал: никаких "слияний" методов! даёшь явное указание того, что реализуется! И не надо силиться представлять, какой страх божий получился бы в итоге - экземпляр вполне себе есть в дикой природе. Шарпом называется. В его дженериках даже пёрнуть нельзя без того, чтобы потребовать от типа-аргумента реализовать интерфейс с методом Пёрнуть(). Т.е. интерфейс служит не только для динамического полиморфизма, но ещё и для статического. Ну, если уж совсем строго, то нет там никакого статического полиморфизма, а джененрики - так, сбоку бантик, не особо то и нужный. За это генитальное решение отдельное "спасибо" г-ну Хейлсбергу. Собственно, всю тему temlates vs generics это и перетирали.
Ещё раз главную мысль моего словесного поноса: в случае концептов используется механизм проверки соответствия по имени метода и его сигнатуре потому, что нет альтернативы ввиду недостаточности информации о коцептах в точке использования класса у реализующего этот класс. Попытка ввести механизмы, предоставляющие подобную информацию, приведут к дискредитации шаблонов и утраты ими большей части своих возможностей.

Кстати, если есть интерфейс, принимающая его функция и реализующий его класс

interface IA
{
  void f();
}
 
void do_something_with_IA(IA ia) { /*какой-то код*/ }
 
class A : IA
{
  void f() { /*какой-то код*/ }
}

а так же существует код, использующий класс A (сующий его во всякую щель, ожидающую IA), но этому коду ещё известно и о

interface IB
{
  void f();
}
 
void do_something_with_IB(IB ib) { /*какой-то код*/ }

то можно ли запихнуть экземпляр A в do_something_with_IB? А что, по сигнатурам всё проходит! Да и с концептами так делать можно. И вообще у нас поведение по умолчанию - "сливать" "одинаковые" методы.
Мой ответ - категорическое нет. Не реализовывал автор A интерфейс IB и всё тут. И нефиг за него додумывать.

Сообщение отредактировано: MyNameIsIgor - 20.03.11, 05:01

Цитата MyNameIsIgor @ 19.03.11, 20:12

Хороший интерфейс. Мне нравится. Нераскрытой семантики - хоть жопой жуй. Вот скажите, когда я только сделаю Open на файле, текущая позиция где будет? В начале? Или в конец? А, может, на пятом байте? А позиции чтения и записи связаны или нет? Если я сделаю Read, то потом Write будет с позиции после прочитанной или нет? И что-то не вижу ответа на свои вопросы в объявлении интерфейса...

а зачем тебе это знать? если тебе нужно работать с конкретной (или абстрактной) реализацией -- с ней и работай. интерфейс тебе лишь гарантирует наличие этих методов.

Цитата MyNameIsIgor @ 19.03.11, 20:12

Наверно, теорию надо почитать - там всё есть на все случаи моей страшной как атомная война жизни Простите великодушно, но я за ответами в документацию лучше полезу, и плевать на сколько "не ООПэшно" это будет. Ну, а теперь, korvin, не отвечая на мои вопросы, напишите функцию, делающую с этим интерфейсом что-то более-менее сложнее "Hello, world", а я вам предоставлю реализацию интерфейса, на которой ваш код ласты склеит.

например?

func copy (in, out : File) {
    (in, out).Open()
 
    out.Write( in.Read() )
 
    (in, out).Close()
}

Цитата MyNameIsIgor @ 19.03.11, 20:12

Во-первых, доводы инженера - это доводы практика. Всегда.

это как "да не очкуй, Славик, я так сто раз делал"? нет, спасибо, я уже насмотрелся на "творчество" таких инженеров, которые не знают теорию реляционных баз данных, что такое нормализация и зачем она нужна, как обеспечивать целостность, непротиворечивость данных в БД.

Цитата MyNameIsIgor @ 19.03.11, 20:12

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

эээ для доказательств используют _только_ теорию, никакой практикой нельзя что-то доказать, можно показать в подтверждение, но после ста успешных экспериментов, непроведенный стопервый легко может опровергнуть это ваше "доказательство"

Цитата MyNameIsIgor @ 19.03.11, 20:12

И если теория не подходит - её выкидывают. Тоже всегда

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

Цитата MyNameIsIgor @ 19.03.11, 20:12

Потому что теория - обслуга. Она вторична. Она возникает после практики. И для неё.

так что первичней: курица или яйцо?

Цитата MyNameIsIgor @ 19.03.11, 20:12

Она является обобщением опыта. Но не всегда ко всему подходящим обобщением. И не всегда правильным. Именно поэтому она меняется с течением времени.

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

Добавлено 20.03.11, 06:16

Цитата D_KEY @ 19.03.11, 21:52

У него нет сигнатуры, у него только имена.

да, я подумал, что так будет проще и понятней, ибо сигнатур там не много, оказалось нет. вначале хотел написать с сигнатурами
как-нибудь так:

interface IFile {
    void Open  ()
    void Close ()
    any  Read  ()
    void Write (any)
}

Добавлено 20.03.11, 06:28

Цитата MyNameIsIgor @ 20.03.11, 04:54

korvin'у не читать

Да и то надо подождать korvin'а, а то Роб Пайк вполне себе мог брякнуть, что ему вовсе не интересна текущая позиция в файле.

кстати, в ОС Plan B (не путать с Plan 9, но B фактически является 9 с одни изменением) файлы вообще не имеют интерфейса Open/Close (ну и называются не файлами, а "коробками" (boxes)), т.е. они как бы всегда открыты, цель такого шага сугубо практична.
дано:
смонтированный удаленный каталог /net/foo (например через NFS/Samba/9P)
в нем два каталога: bar и baz
в каталоге bar находится файл gee
задание:
скопировать gee из bar в baz без эээ прохождения содержимого этого файла по сети.
т.е. в win/nix/p9 это выглядело бы так: сначала содержимое этого файла порциями бы вытягивалось на нашу машину, затем эти порции отправлялись бы обратно на удаленную машину.

собственно в целях решения этой проблемы и был сделан Plan B, в вике можно более подробно почитать.

Добавлено 20.03.11, 06:32

Цитата MyNameIsIgor @ 20.03.11, 04:54

то можно ли запихнуть экземпляр A в do_something_with_IB? А что, по сигнатурам всё проходит! Да и с концептами так делать можно. И вообще у нас поведение по умолчанию - "сливать" "одинаковые" методы.
Мой ответ - категорическое нет. Не реализовывал автор A интерфейс IB и всё тут. И нефиг за него додумывать.

как это не реализовал, когда реализовал? все методы соответствующих сигнатур на месте => реализовал

Цитата korvin @ 20.03.11, 06:12

как это не реализовал, когда реализовал? все методы соответствующих сигнатур на месте => реализовал

Реализовал интерфейс IB::f()? Да автор IA про него и не слышал и во сне не видел, и понятия не имеет, что должен делать IB::f(). Вот может наглядней так:

      interface IAL
      {
        int shift(int value);
      }
      
      void do_something_with_IA(IAL ia) { /*какой-то код*/ }
      
      class A : IAL
      {
        int shift(int value) { return value << 1; }
      }
 
      interface IBR
      {
        int shift(int value);
      }
      
      class B : IBR
      {
        int shift(int value) { return value >> 1; }
      }
      
      void do_something_with_IB(IBR ib) { /*какой-то код*/ }

Боюсь, что код void do_something_with_IB(A a) будет делать что-то не то, что хотелось бы.

Сообщение отредактировано: Adil - 20.03.11, 07:45

Цитата korvin @ 20.03.11, 06:12

а зачем тебе это знать?

Чтобы написать код, делающий осознанные действия, а не неизвестно что.

Цитата korvin @ 20.03.11, 06:12

если тебе нужно работать с конкретной (или абстрактной) реализацией -- с ней и работай. интерфейс тебе лишь гарантирует наличие этих методов.

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

Цитата korvin @ 20.03.11, 06:12

например?

Что не ясно? Что вы не знаете, куда записали? Что вы не можете гарантировать, что сами же считате записанное? А если отсутствие этой гарантии и предполагалось, то как мне об этом узнать из этого списка методов?
И вообще, я здесь не вижу использования приведённого вами интерфейса. Здесь есть использование чего-то такого

interface Openable
{
  Open
}
interface Closeable
{
  Close
}
interface Input : Openable, Closable
{
  Read
}
interface Output : Openable, Closeable
{
  Write
}

Вот Input с Output'ом вы и пользуете. А вот

interface File : Output, Input
{
}

ни разу. Не вижу в какой момент вам бы требовалась связная работа именно с файлом. Так что даю вводную: нужна функция, принимающая строку и записывающая её в файл начиная с десятой позиции. Вперде, korvin!

Цитата korvin @ 20.03.11, 06:12

нет, спасибо, я уже насмотрелся на "творчество" таких инженеров, которые не знают теорию реляционных баз данных, что такое нормализация и зачем она нужна, как обеспечивать целостность, непротиворечивость данных в БД.

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

Цитата korvin @ 20.03.11, 06:12

Цитата MyNameIsIgor @ 19.03.11, 20:12

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

эээ для доказательств используют _только_ теорию, никакой практикой нельзя что-то доказать, можно показать в подтверждение, но после ста успешных экспериментов, непроведенный стопервый легко может опровергнуть это ваше "доказательство"

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

Цитата korvin @ 20.03.11, 06:12

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

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

Цитата korvin @ 20.03.11, 06:12

так что первичней: курица или яйцо?

Практика, конечно.

Цитата korvin @ 20.03.11, 06:12

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

Как выпускник маткласса ответственно заявляю: совершенно бесполезная без практических приложений наука. Не даром её называют не только царицей наук, но и их служанкой
У вас вообще какое восприятие чёрно-белое. Юношеским максимализмом попахивает... Я разве говорил, что теория не нужна. Да Боже упаси! Но когда она сталкивается с практикой, то всегда проигрывает (это, кстати, кто-то сказал, не помню уже кто...).

Цитата korvin @ 20.03.11, 06:12

как это не реализовал, когда реализовал? все методы соответствующих сигнатур на месте => реализовал

Это диагноз...

Сообщение отредактировано: MyNameIsIgor - 20.03.11, 07:54