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

N>>>Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования.
N>>>Ты ничего не сделаешь с существующим окном, не указав его хэндл.
N>>>Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв.
N>>>Всё это — работа с объектами.

N>И что не соответствует выделенному? Если нет объекта или объект не в том состоянии, у тебя не получится нормальной работы с ним.

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

N>Нет в описанном "чистых функций", не обманывай себя.

Если пользоваться академическим и бессмысленным определением из википедии, то, да, нет.

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

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

N>>>>Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования.
N>>>>Ты ничего не сделаешь с существующим окном, не указав его хэндл.
N>>>>Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв.
N>>>>Всё это — работа с объектами.

N>>И что не соответствует выделенному? Если нет объекта или объект не в том состоянии, у тебя не получится нормальной работы с ним.

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

Да ну? Почему, например, DirectX не требует создания контекста окна для рисования?
И что мне мешает провести линию на экране не создавая всяких объектов? Почему-то в всяких graph.bgi это можно было делать без проблем, а тут какая-то ерунда началась — контекст создавай, ещё какую-то ерунду настраивай прежде чем сможешь хотя бы один пиксел засветить... нет чтобы всё отнять и поделить...

U> А вот, к примеру, для вывода рамки textBox'а не нужны ни текст, ни выделенный символ, ни даже хэндл самого textBox'а, но если вывод рамки прибит к textBox'у, то без всего этого рамку не выведешь.

Просто рамку — да. А какую именно рамку? Она вообще-то может быть существенно разной в зависимости от нескольких параметров. Например, text box может состоять из нескольких подполей. Как ты это передашь в функцию? Он может быть в фокусе, это будет отражаться в методе рисования рамки. Ты это будешь передавать отдельным флагом? Если рамку надо нарисовать другим цветом, будешь передавать указание на этот цвет? Там ещё с полдесятка параметров, о которых ты ещё не знаешь.

Как только ты начнёшь думать передавать в подобной среде всё, что нужно, в функцию, она или превратится в то, как сейчас выглядит CreateFile(), или начнутся извращения со списками свойств (с большой опасностью неправильной конверсии), или с полями структуры, и в результате ты придёшь к тем же объектам, но иначе покрашенным. Посмотри, например, на pthread_create(). Для расширения свойств создаваемой нити придуман отдельный объект (пусть и без явного цикла жизни) атрибутов, и функции работы с параметрами в этом объекте (get, set). Вот такое же будет и тебе для text box. И какой смысл разработчикам делать какое-то отдельное от самого text box'а средство для рисования рамки?

N>>Нет в описанном "чистых функций", не обманывай себя.
U>Если пользоваться академическим и бессмысленным определением из википедии, то, да, нет.

Я не смотрел в википедию для понимания этого определения, но если она говорит то же, что я, то это мне только лучше

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

Глобальный флаг стиля интерфейса (XP/Vista/etc., не говоря уж о юниксовых вариантах), параметры установленной цветовой схемы — это аргументы функции или что-то другое? Думаю, вопрос риторический.

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

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

N>>Нет в описанном "чистых функций", не обманывай себя.

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

U>Если же пользоваться практически полезным определением
Я не мастер восстанавливать определения непротиворечивым образом из контекста, как это любит и умеет DarkGray, потому не мог бы ты дать ссылку на источник практически полезного определения, что бы я мог приобщиться к практической полезности? Ну и вообще-говоря, почему остальные должны пользоваться именно практически полезным определением без источника, если общедоступным и общеупотребимым является определение в википедии? Может википедию стоит дополнить?

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

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

Может что бы избежать недопонимания, назовешь свои функции "хорошими", "правильными" или "практически полезными"? Просто термин "чистые" в отношении функций используется не менее 70и лет. Мне кажется, слишком долго, что бы вот так вот взять и объявить его бесполезность и заменить смысл.

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


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

А при чем здесь ООП то? На чистых функциях то же лишнее состояние прекрасно можно изобразить:

void drawTextBox(HGRAPHICS context, HTEXTBOX textBox)

Здесь я наивно предполагаю, что drawTextBoxBorder спрятана внутри библиотеки и пользователю недоступна. И все — приплыли. Проблема та же самая — сложно отпилить отдельные части для отдельного использования. Функция "чистая" даже в вашем определении — она только меняет context, но не трогает textBox.

Вы же сами пишете, что проблема в лишнем состоянии. Добавлю — еще в "излишней инкапсуляции" библиотек. На самом деле вы хотите, чтобы вам был предоставлен доступ ко всему "стеку" слоев. Для текстбокса это отдельно слои рендеринга ("простого"), модули измерения и раскладки (layout) текста, работы со шрифтам. Также нужно предоставлять доступ к "утилитным" функциям вроде drawTextBoxBorder. Предоставлять доступ к промежуточным слоям никто не запрещает ни ООП, ни чистые функции. Ну и в обоих случаях получится удобный API.

Только вот во всем этом есть одна проблема — проектировать "промежуточные" слои нужно специально для повторного использования. WolfHound это уже высказывал эту мысль в обсуждении. И одна из задач — учет возможных дальнейших изменений библиотеки. Это совсем не так просто, как кажется. То, что для drawTextBoxBorder сейчас не используется состояние текстбокса не значит, что в дальнейшем это состояние не будет использоваться. Например, можно у текстбоксов с фокусом и без иметь различные рамки. Или там для выделенного текста как-то особо отмечать бордер (при перетаскивании текста, например). Или другую рамочку при достижении максимальной длины текста делать (при редактируемом текстбоксе). Все это потребует менять API "чистой" функции drawTextBoxBorder. Что для "повторно используемой" библиотеки является очень плохой идеей. Правильным решением здесь является выделение функции drawCommonTextBox и вызов ее из текстбокса. Но никто не мешает делать такие функции и в ООП. А если вдруг когда-то текстбокс начнет иметь разные рамки, ваше использование drawCommonTextBox будет вести себя немного по-другому. Но здесь вам никто идентичного поведения и не обещал.

P.S. Трансляция между something.someMethod и someMethod(something, ...) вообще должна быть синтаксическим сахаром на уровне компилятора. Но во второй форме будут якобы "чистые методы", которые не имеют проблем. Ну а раз они не имеют проблем, конвертируем их в первую форму и в ООП тоже проблем не будет .

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

ГВ>Например, в лучшие для ООП времена бытовала такая мифологема, что скоро программы будут собирать "из кубиков"

Ты спутал ООП и КОП.

ГВ>Как раз топикстартер говорит о прямо противоположном: о том, что элементы ОО-программ на самом деле трудны в повторном использовании.

ООП в этом плане ничем не отличается от остальных популярных парадигм. Для возможности реюза в другом окружении код должен быть специально для этого заточен. В любой парадигме.

Здравствуйте, мыщъх, Вы писали:

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

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

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

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

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

M>А при чем здесь ООП то? На чистых функциях то же лишнее состояние прекрасно можно изобразить:

На это я уже отвечал:

КБ>Речь шла о том что якобы только ООП-код может не реюзабельным, а не-ООП код реюзабельным получается автоматически.

Об автоматичности речи точно не было. Чистые функции это необходимое, но недостаточное условие реюзабельного кода.

M>Здесь я наивно предполагаю, что drawTextBoxBorder спрятана внутри библиотеки и пользователю недоступна. И все — приплыли. Проблема та же самая — сложно отпилить отдельные части для отдельного использования. Функция "чистая" даже в вашем определении — она только меняет context, но не трогает textBox.

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

M>Добавлю — еще в "излишней инкапсуляции" библиотек.

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

M> Все это потребует менять API "чистой" функции drawTextBoxBorder. Что для "повторно используемой" библиотеки является очень плохой идеей.

В худшем случае функция drawTextBoxBorder становится obsolete, а textBox начинает использовать функцию drawTextBoxBorder2. В чем проблема-то?

M> Правильным решением здесь является выделение функции drawCommonTextBox и вызов ее из текстбокса.

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

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

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

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

S> Ну и вообще-говоря, почему остальные должны пользоваться именно практически полезным определением без источника, если общедоступным и общеупотребимым является определение в википедии? Может википедию стоит дополнить?

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

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

Разумеется. Об этом во всех азбуках программирования написано, в главе о именовании функций.

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

MA>Здравствуйте, мыщъх, Вы писали:

М>>драматизм ситуации в том, что в си все каллбэки объявляются явно. а вот в ооп они хитро скрыты.
MA>кто мешает испольовать воч-лист и трассировщик, что бы дойти до сути?
ну вот смотрите:
def main():
for i in range(5):
t = Thread(queue)
t.setDaemon(True)
t.start()

class Thread(threading.Thread):
def __init__(self, queue):
threading.Thread.__init__(self)
self.queue = queue

def run(self):
while True:

в си такое невозможно в принципе. потому что 'run' нужно как-то в Thread передать. а в ооп совсем неочевидно каким образом этот run вообще вызывается. и вызывается ли.

трассировщик не предлагать.


MA>в делфях насколько я помню это было не просто, а очень просто
"очень просто" это смотреть код и читать его без средств динамического анализа.

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

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

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

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

U>Что такое термин и в чем практический смысл его использования? Термин — это сокращение/псевдоним определения. Т.е. для того, чтобы каждый раз, когда речь заходит о некоей сущности, не писать определение вводится термин и далее используется вместо определения. Определение того, что я понимаю под чистой функцией я дал.
После того как многократно использовал.
U>Подбирать для этой сущности другой термин, на том основании, что термин "чистая функция" уже кем-то занят, я смысла не вижу никакого, т.к. в русском языке не так много слов, и соответственно какое ни возьми окажется что кто-нибудь когда-нибудь уже его использовал в качестве термина. Соответственно спор о терминах это пустая трата времени, обсуждать имеет смысл определения, а не его псевдоним.
Тебе следует использовать свое определение именно каждый раз, потому как собеседники подразумевают под чистотой нечто другое.

S>> Ну и вообще-говоря, почему остальные должны пользоваться именно практически полезным определением без источника, если общедоступным и общеупотребимым является определение в википедии? Может википедию стоит дополнить?

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

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

U>Разумеется. Об этом во всех азбуках программирования написано, в главе о именовании функций.
Ты о содержательных именах? Можно ссылку хотя бы на один букварь, где бы говорилось что имя связано с чистотой функции?

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

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

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

M>>Добавлю — еще в "излишней инкапсуляции" библиотек.

U> Принципиальная разница именно в проблеме лишнего состояния, которая не разрешима в рамках чистого ООП.
Кто заставляет вводить лишнее состояние? И как быть в ФП с теми случаями, когда изменяемое состояние нужно? Это практически любые "толстые" клиенты, например.

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

Ну например, как на "чистых функциях" будет решаться задача кэширования результатов вызова какого-нибудь сервиса? Базовый метод — callService. Ну и туда, естественно, требует солидный кусок мира — настройки этого сервиса (endpoint, например), аргументы вызова, обработчики результата и т.п. Только не говорите, что для настроек сервиса будет handle — в этом случае у меня это будет объектом с инкапсулированными настройками и сам объект будет называться сервисом. К тому же handle будет обладать той же проблемой. Далее, есть какой-то кэш с методами get/put. Как будет выглядеть "чистая функция", которая может брать значения из кэша? Ей будет передаваться сам кэш и вся та куча параметров (включая endpoint и т.п.), необходимая для работы вызова сервиса? А что будет, если мы потом захотим мониторинг добавить (количество попаданий в кэш)? Нужно будет еще и параметры мониторинга менять с изменением кода? Ну и получим в результате что-то вроде:

HResult callServiceWithPossibleCachingAndMonitoring(HCallCountContext callCountContext, HCacheHitCountContext cacheHitCountContext, HCache cache, HEndpoint endpoint, HArgs args);

Как-то многовато получилось... И при изменениях поддерживать неудобно. Принципиально здесь то, что у нас на самом деле есть 4 "грязных" состояния, которые должна менять функция (два конекста статистики, кэш и сервис). Статистику мы потом еще в базу иногда сбрасываем. Как с этим предлагает бороться ФП? Можно наделать функций-оберток с замыканием на свой "грязный" контекст. Только вот там будут "грязные" функции и без контекста они больше не работают. Ну и те же функции, кстати, будут в объектах ООП. Можно сделать монады и оставить функции "чистыми". Только вот на самом деле неявным (или явным) контекстом будет та самая монада, которая была бы в ООП объектом. Точно так же в ней будет сокрыто состояние. И точно так же, как функции doSomethingWithMonad monad, в ООП будет запись monad.doSomethingWithThis. А еще в ФП будет куча комбинаторов между различными (ведь разные контексты независимы друг от друга для возможности использовать их по-отдельности) монадами. Что-то тоже не очень хорошо получилось. Решение в "ООП" стиле:

public interface Cache<K, V> {
  public void put(K, V);
  public V get(K);
}

public interface Service {
  public HResult call(HArgs args);
}

public static function Service createService(HEndpoint endpoint);
public static function Service createCachedService(Service service, Cache<HArgs, HResult> cache);
public static function Service countCalls(Service service, Counter function);
public static function Cache<K, V> countCacheHits(Cache<K, V> cache, CacheHitCounter counter);

Фактически "те же" монады (каждый экземпляр сервиса — это монада). Только интерфейсы у них меньше и изменять код проще.

M>> Все это потребует менять API "чистой" функции drawTextBoxBorder. Что для "повторно используемой" библиотеки является очень плохой идеей.

U>В худшем случае функция drawTextBoxBorder становится obsolete, а textBox начинает использовать функцию drawTextBoxBorder2. В чем проблема-то?

В этом самом худшем случае! Изменение интерфейса библиотеки — это плохо. Оно заставляет очень долго думать над управлением версиями используемых библиотек. Вот допустим, мы использовали какую-то функциональность из библиотеки VeryCoolTextBox. Она, в свою очередь, использовала где-то drawTextBoxBorder (который и мы тоже использовали). Через полгода нам потребовалась функциональность, появившаяся во второй версии VeryCoolTextBox. Отлично, мы берем вторую версию этой библиотеки. Оказывается, для ее работы нужна еще и вторая версия библиотеки BaseTextBorders (а именно — функция drawTextBoxBorder2). Ладно, взяли библиотеку. И получили, что у половины текстбоксов стиль один (из drawTextBoxBorder), а у другой половины — другой (из VeryCoolTextBox). Ну и что теперь делать? Варианты то есть (можно использовать старую версию VeryCoolTextBox, можно весь код на новые текстбоксы поправить, можно VeryCoolTextBox пропатчить) но думать надо

Случай, когда мы контролируем всех клиентов drawTextBoxBorder, мы не рассматриваем. Этот случай — "код, не предназначенный к повторному использованию".

M>> Правильным решением здесь является выделение функции drawCommonTextBox и вызов ее из текстбокса.

U>Правильным решением будет и выделение функции drawTextBoxBorder как чистой функции нижнего уровня, и функции drawCommonTextBox как чистой функции верхнего уровня, использующей чистые функции нижних уровней. А там уже пользователь фрамеворка сам решит, какой уровень нужно использовать для его задач.

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

Здравствуйте, мыщъх, Вы писали:


М>в си такое невозможно в принципе. потому что 'run' нужно как-то в Thread передать. а в ооп совсем неочевидно каким образом этот run вообще вызывается. и вызывается ли.

Это не проблемы ООП. Это проблемы конкретного API. То, что в api передается объект у которого ищется метод — это решение данного конкретного API. Туда вполне может передаваться функция. Ну или если функции не поддерживаются (не являются полноценными объектами), то интерфейс runnable. На C что-то подобное и неочевидное изобразить тоже можно. Например, thread.start будет получать адрес функции, которая возвращает адрес структуры, у которой в третьем поле нужно взять адрес функции, которая получив структуру наконец-то вернет адрес фунции, которую нужно выполнять. Но это будут проблемы уже этого API.

P.S. И если там в примере наследование от Thread — это тоже плохое API. Thread вообще должен быть ненаследуемым.

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

M>Здравствуйте, мыщъх, Вы писали:


М>>в си такое невозможно в принципе. потому что 'run' нужно как-то в Thread передать. а в ооп совсем неочевидно каким образом этот run вообще вызывается. и вызывается ли.

M>Это не проблемы ООП. Это проблемы конкретного API.
здраствуйте, я ваша бабушка. а виртуальные функции разве не преподносятся как достижение ООП? и практически все ООП библиотеки в таком стиле написаны.

> То, что в api передается объект у которого ищется метод — это решение данного конкретного API.
> Туда вполне может передаваться функция. Ну или если функции не поддерживаются
в процедурном программировании -- да. функция передается явно. теоритически возможно передавать ее и неявно (например, стартовый код вызывает main или WinMain по имени -- на стадии линковки и, например, из кода совсем неочевидно, что main вызывается один раз, а DllMain — более одного раза), но в ООП это считается хорошим тоном.

Здравствуйте, мыщъх, Вы писали:

M>>Это не проблемы ООП. Это проблемы конкретного API.
М>здраствуйте, я ваша бабушка. а виртуальные функции разве не преподносятся как достижение ООП? и практически все ООП библиотеки в таком стиле написаны.

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

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

M>Здравствуйте, мыщъх, Вы писали:

M>>>Это не проблемы ООП. Это проблемы конкретного API.
М>>здраствуйте, я ваша бабушка. а виртуальные функции разве не преподносятся как достижение ООП? и практически все ООП библиотеки в таком стиле написаны.
M>А кем преподносится? Вас обманули, это устаревшая информация.
всеми библиотеками, какие только есть.

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

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

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

> Вместо них как раз делегирование должно использоваться.
во! я тоже за делегирование.

Здравствуйте, мыщъх, Вы писали:

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

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

G>Здравствуйте, мыщъх, Вы писали:

G>Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки?
G>Наследование — отношение is-a. В каком смысле "прямая" is-a "точка".
идите лесом. есть базовый класс. он выводит пиксель. производный класс расширяет функционал до отрисовки Line. если это бред, то не мой. это то, что пишут в книгах за ООП. и это то, с чем я не согласен

Здравствуйте, мыщъх, Вы писали:

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

G>>Здравствуйте, мыщъх, Вы писали:

G>>Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки?
G>>Наследование — отношение is-a. В каком смысле "прямая" is-a "точка".
М>идите лесом. есть базовый класс. он выводит пиксель. производный класс расширяет функционал до отрисовки Line. если это бред, то не мой. это то, что пишут в книгах за ООП. и это то, с чем я не согласен
Может тогда сделать строку производной от класса символа, который выводит символ в консоль, что бы расширить символ до вывода строки?

А где такое пишут?

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

S>Может тогда сделать строку производной от класса символа, который выводит символ в консоль, что бы расширить символ до вывода строки?
а это не так? ооп не заканчивается на плюсах. во многих языках даже число 1 это оъект. тем более символ. кстати, а вы уверены, что класс символа у вас есть? что у вас вообще есть символ? опять же, в мире есть не только плюсы. есть языки в которых есть только строки и 'a' === "a".

Здравствуйте, мыщъх, Вы писали:

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

S>>Может тогда сделать строку производной от класса символа, который выводит символ в консоль, что бы расширить символ до вывода строки?
М>а это не так?
Полагаю, что нет
М>ооп не заканчивается на плюсах.
и не начинается
М>во многих языках даже число 1 это оъект. тем более символ. кстати, а вы уверены, что класс символа у вас есть? что у вас вообще есть символ? опять же, в мире есть не только плюсы.
да, знаю такие языки.
М>есть языки в которых есть только строки и 'a' === "a".
Но мы говорим о случае, когда строка расширяет символ (линия рассширяет пиксель). Вот такие примеры хотелось бы посмотреть. Обобщим до случая, когда коллекция расширяет элемент