Здравствуйте, VoidEx, Вы писали:
VE>Поэтому компилятор тыкнет в места, где это надо исправить. И именно поэтому чистое ФП и рулит.
А ты про какое такое чистое ФП говоришь? А то в этой теме уже было несколько их трактовок
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, VoidEx, Вы писали:
VE>>Поэтому компилятор тыкнет в места, где это надо исправить. И именно поэтому чистое ФП и рулит. T>А ты про какое такое чистое ФП говоришь? А то в этой теме уже было несколько их трактовок
Здравствуйте, mrTwister, Вы писали:
T>"структура" из f1() и f2() — это тоже шаг в сторону ООП. Чем такая структура принципиально отличается от объекта?
А чем она вообще на него похожа, кроме того, что это кортеж двух чистых функции?
Может, State? Identity?
S>>Если она же есть в ФП, то теоретически ничто не мешает мне "по нажатию клавиши" получить список всех функций с заданной сигнатурой.
T>Какая мне польза от тысяч функций с сигнатурой "void f()", когда я ищу, например, реализацию ITransaction, членом которого (интерфейса) является "void Rollback()"?
А вы напишите "transaction |>" и IDE будет знать первый аргумент. Это лишь вопрос синтаксиса. А заслуга всё-таки статической типизации. "Чего вы тень на плетень наводите?"
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, mrTwister, Вы писали:
T>>"структура" из f1() и f2() — это тоже шаг в сторону ООП. Чем такая структура принципиально отличается от объекта?
VE>А чем она вообще на него похожа, кроме того, что это кортеж двух чистых функции? VE>Может, State?
Да, state. Набор функций и их замыкания являются состоянием.
VE>Identity?
Я не понимаю, почему identity является чем-то, характеризующим ООП. Если мы туда добавим "bool Equals()", это сразу все поменяет?
S>>>Если она же есть в ФП, то теоретически ничто не мешает мне "по нажатию клавиши" получить список всех функций с заданной сигнатурой.
T>>Какая мне польза от тысяч функций с сигнатурой "void f()", когда я ищу, например, реализацию ITransaction, членом которого (интерфейса) является "void Rollback()"?
VE>А вы напишите "transaction |>" и IDE будет знать первый аргумент. Это лишь вопрос синтаксиса. А заслуга всё-таки статической типизации. "Чего вы тень на плетень наводите?"
И получу в общем списке "commit(transaction)", "log(transaction)", "createTables(transaction)", "backupDatabase(transaction)" и еще 100500 нерелевантных вариантов.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, samius, Вы писали:
S>>Если мы аппелируем к этому определению и в частности к структуре, содержащей поля и "методы" в их ООП трактовке, то мы вынуждены признать что ООП парадигма может существовать лишь в рамках ООП языков. И то возникают вопросы. Так, оказывается что COM не ООП по причине того что интерфейсы не содержат полей данных.
SV.>Я не очень понимаю, что такое "ап(п)еллировать к определению". Вы хотите сказать "если мы его примем"? А что, есть основания не принимать?
Да, каюсь. Слово вспомнилось, а как пишется и используется не освежил. Мне стыдно.
По поводу оснований не принимать такое определение: ИМХО, это не определение, а пояснение. Что-то вроде "коромысло — это то чем носят воду". Что бы определять, уместно ли говорить об ООП в конкретном коде/технологии, нужно смотреть на присутствие фундаментальных концепций ООП. Ссылку я давал в предыдущем посте (на той же странице википедии, откуда вы взяли "определение"), вы ее проигнорировали.
SV.>Утверждение "мы вынуждены признать что ООП парадигма может существовать лишь в рамках ООП языков" таким основанием не является по причине неверности.
Это мое утверждение. Это я утверждаю что если судить о наличии ООП по полям и методам, то мы придем к тому что ООП взможно лишь в языках с поддержкой ООП, что не верно. SV.>Есть грязные хаки, которые позволяют работать с объектами на языках типа C.
Ничего грязного в них не вижу. SV.> Например, такова технология COM.
Согласно "определению" о полях и методах COM не является объектной по причине отсутствия полей. Я читал ответ Синклеру, то что вы называете полями в виртуальном ООП, полями не является.
Предлагаю не продолжать тему COM, вместо этого отклонить определение о полях и методах.
SV.>Объекты от этого не перестают быть объектами, поскольку описаны в явном виде в библиотеке типов, которая считается неотъемлемой частью кода. Все методы и все свойства каждого объекта, исчерпывающе и неизбыточно. К WinAPI, напомню, ничего подобного не прилагается.
Библиотека типов не является неотъемлемой частью кода. Она опциональна.
А к ВинАПИ прилагается документация, книги, заголовки.
SV.>Отсюда и все остальное. Зачем переусложнять? Наличие объектов — то есть, полей и методов, объединенных в одно целое — которые взаимодействуют между собой — необходимое и единственное условие ООП.
Это вы переусложняете полями. Поля и методы не являются чем-то необходимым для ООП. Объект может хранить свое состояние в файле, облаке, или за кулисами HWND.
Здравствуйте, VoidEx, Вы писали:
VE>http://lmgtfy.com/?q=Pure+functional+programming
VE>Первые две можно почитать. Не стоит собеседника с ходу подозревать в чём-то, даже если ты уже свой максимум этики уже спустил на других.
Вместо того, чтобы ехидничать не по делу, лучше бы ветку почитал и понял, о чем шел разговор. Было обсуждение с Undying его собственной трактовки ФП, отличающейся от общепринятой, когда ты влез в середину разговора.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, VoidEx, Вы писали:
VE>>А чем она вообще на него похожа, кроме того, что это кортеж двух чистых функции? VE>>Может, State?
T>Да, state. Набор функций и их замыкания являются состоянием.
VE>>Identity?
T>Я не понимаю, почему identity является чем-то, характеризующим ООП. Если мы туда добавим "bool Equals()", это сразу все поменяет?
Здравствуйте, mrTwister, Вы писали:
T>Да, state. Набор функций и их замыкания являются состоянием.
И как мы это состояние можем поменять?
VE>>Identity?
T>Я не понимаю, почему identity является чем-то, характеризующим ООП. Если мы туда добавим "bool Equals()", это сразу все поменяет?
Ну добавь в ФП такое equals, вперёд.
VE>>А вы напишите "transaction |>" и IDE будет знать первый аргумент. Это лишь вопрос синтаксиса. А заслуга всё-таки статической типизации. "Чего вы тень на плетень наводите?"
T>И получу в общем списке "commit(transaction)", "log(transaction)", "createTables(transaction)", "backupDatabase(transaction)" и еще 100500 нерелевантных вариантов.
Ну сделай data This a = This a. и пиши This transaction |>
Тоже мне, бином Ньютона.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, VoidEx, Вы писали:
VE>>http://lmgtfy.com/?q=Pure+functional+programming
VE>>Первые две можно почитать. Не стоит собеседника с ходу подозревать в чём-то, даже если ты уже свой максимум этики уже спустил на других.
T>Вместо того, чтобы ехидничать не по делу, лучше бы ветку почитал и понял, о чем шел разговор. Было обсуждение с Undying его собственной трактовки ФП, отличающейся от общепринятой, когда ты влез в середину разговора.
Сам бы почитал.
Процитирую:
[quote]Поэтому компилятор тыкнет в места, где это надо исправить. И именно поэтому чистое ФП и рулит.[/quote]
Вот и расскажи мне, какие такие чистые ФП языки в определениях, отличных от моего, на ввод стейта буду плеваться ошибками компиляции?
Здравствуйте, AndreyM16, Вы писали:
AM>В последнее время замечаю что, чем на большее число элементов(функций, интерфейсов) разбита логика, тем легче писать юнит тесты. То есть разбивать (если есть время и желание) нужно хотя бы для целей тестирования.
По-моему, это настолько мощное премущество композиции, что... ну вы поняли. Да хотя бы ради читабильного call-stack при ошибках...
Здравствуйте, SV., Вы писали: SV.>IDL — Interface Definition Language, а не Programming Language.
Ну, так в COM ничего другого и нет.
SV.>И в этом виртуальном ООП'е, описанном на IDL'е, поля, конечно же, есть.
Не вижу никаких таких полей в ООПе, описанном на IDL. Может, я чего-то простого не замечаю? SV.>В реальности, конечно, создатели COM'а все сделали для того, чтобы вы виртуальные "поля" реализовывали через методы ООП-языков (в первую очередь — C++), отсюда и синтаксис, но это, извините, не обязательно.
Вы, похоже, придумываете неортодоксальную трактовку property. Я вас разочарую — никаким "полем" эта штука не является. Это всего лишь удобный способ записи к тому, что издали выглядит как состояние. На самом деле, это такой способ записи контракта на поведение. Полей там по-прежнему нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mrTwister, Вы писали:
T>"структура" из f1() и f2() — это тоже шаг в сторону ООП. Чем такая структура принципиально отличается от объекта?
Ну, начинается.
Принципиально эта структура отличается иммутабельностью, благодаря которой мы можем иметь повышенную понятность. Ибо все зависимости по состоянию придётся обозначать в явном виде.
Понятно, что можно эмулировать недо-ФП на ООП (см. тж. "функторы" или, скажем, замыкания из C#), и можно эмулировать недо-ООП на ФП.
T>Мы и раньше не были в этом уверены, так как операция "нарисовать рамку" по определению имеет побочные эффекты.
Ну-ну-ну. Откуда же вдруг взялись побочные эффекты для самого рисователя? Побочные эффекты в рисователе рамки были у нас сведены к канвасу, по которому он рисует. А в самом рисователе состояние — это всего лишь результат творческого применения конструкторов.
То есть, жизненный цикл рисователя таков:
1. Конфигурируем рисователь. Это может быть оформлено как один шаг — вызов new, или как последовательность шагов — вызовы SetBorderWidth, SetBorderColor, и т.д. Важно нам вот что: в результате всех этих манипуляций мы получаем 1 (одну) функцию, которая отображает канвас до рисования в канвас после рисования.
2. Собственно, рисуем: скармливаем в эту функцию канвас и, скажем, параметры конкретной рамки, т.е. структуру Rect.
3. Всё. На этом шаге у нас рисователь никак не изменяется, и гарантированно ничего, кроме канваса, не меняет.
T>А почему нет?
Потому что мухи — отдельно, котлеты — отдельно. Вы ещё скажите, что ООП лучше потому, что в нём есть раскраска синтаксиса.
S>>Описанное преимущество — это заслуга статической типизации. T>Не только.
Только. S>>Если она же есть в ФП, то теоретически ничто не мешает мне "по нажатию клавиши" получить список всех функций с заданной сигнатурой. T>Какая мне польза от тысяч функций с сигнатурой "void f()", когда я ищу, например, реализацию ITransaction, членом которого (интерфейса) является "void Rollback()"?
В огороде бузина, в киеве — дядька. В ФП у вас не будет ни ITransaction, ни его реализации, чтобы её поискать. Вы будете искать другие вещи — и будете их успешно находить. Какие проблемы-то?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
SV.>>В реальности, конечно, создатели COM'а все сделали для того, чтобы вы виртуальные "поля" реализовывали через методы ООП-языков (в первую очередь — C++), отсюда и синтаксис, но это, извините, не обязательно. S>Вы, похоже, придумываете неортодоксальную трактовку property. Я вас разочарую — никаким "полем" эта штука не является. Это всего лишь удобный способ записи к тому, что издали выглядит как состояние. На самом деле, это такой способ записи контракта на поведение. Полей там по-прежнему нет.
Трактовки самые что ни на есть ортодоксальные. Другие из Wikipedia удаляют, потому и цитирую:
A property, in some object-oriented programming languages, is a special sort of class member, intermediate between a field (or data member) and a method. Properties are read and written like fields, but property reads and writes are (usually) translated to get and set method calls. The field-like syntax is said to be easier to read and write than lots of method calls, yet the interposition of method calls allows for data validation, active updating (as of GUI visuals), or read-only 'fields'. That is, properties are intermediate between member code (methods) and member data (instance variables) of the class, and properties provide a higher level of encapsulation than public fields.
Virtuality is the quality of having the attributes of something without sharing its (real or imagined) physical form.
Силлогизм такой. 1. Свойство должно выглядеть как поле (the field-like syntax is said to be easier to read and write than lots of method calls), но не быть им. 2. Когда что-то имеет характеристики чего-то другого (выглядит как что-то другое), но не является им физически, это называется виртуальностью. В. Свойство — виртуальное поле. Будете спорить?
Про "издали". Я не настолько хорошо знаю COM, но, по-моему, даже в нем это "издали" можно сильно приблизить. Как VB6-программисту отличить в чужом объекте свойство от поля? Судя по тому, как часто люди задают этот вопрос, в упор не видят. Хорошо виртуализировано, значит.
Теперь вернемся к IDL'ю. Я попытался обратить ваше внимание на то, что это вообще не язык программирования, а язык описания интерфейса. Он и придуман-то специально для описания того, как модуль должен выглядеть, а не быть (реализованным). Глядя в IDL какого-нибудь модуля, вы не знаете даже, есть ли в этом модуле методы на уровне языка программирования, не говоря уж про поля. О каком "разочаровании" может идти речь? Такая виртуализация делает честь этой технологии, а не разочаровывает пользователей.
Если мы закончили с IDL'ем, предлагаю перейти к полям в языках программирования. Судя по реплике про "вывернутую наизнанку" ортодоксальную трактовку ООП, вы с ней несогласны. Хотелось бы послушать.
Здравствуйте, samius, Вы писали:
SV.>>Я не очень понимаю, что такое "ап(п)еллировать к определению". Вы хотите сказать "если мы его примем"? А что, есть основания не принимать? S>Да, каюсь. Слово вспомнилось, а как пишется и используется не освежил. Мне стыдно.
По-моему, вы поспешили с устыжением. Я не имел в виду наехать, а просто не понял (без фиги в кармане).
Как пишется. Я вот вообще не уверен, что общепринятое русское написание этого слова корректно. Как мне объяснили, в словах латинского происхождения согласная в приставке после "а" должна удваиваться, если мы не хотим путать такие слова со словами греческого происхождения, где "а" — отрицательный префикс. Типа, атеист — антитеист, а аккумулятор — накопитель, а не антинакопитель. По этому правилу, "аффилиированный" и "аппелировать" должны писаться с двумя "ф" и "п" соответственно. У нас их пишут не так. Видимо, хотят путать, или, по крайней мере, не создают препятствий к путанице. Короче говоря, я бы не стал стыдиться написания "аппелировать". Откуда там должно быть две "п" как раз понятно, а откуда две "л" — нет. Потому и написал со скобками.
Как используется. "Ап(п)ел(л)ировать к определению" в самом деле используется, но что это значит? Калька "обратимся к определению"? Тоже неглупо, вроде бы. Я лишь уточнил.
К счастью, все это не имеет отношения к ООП. Если модераторам не лень, они могут (?) сдублировать этот постинг в более подходящий форум.
S>По поводу оснований не принимать такое определение: ИМХО, это не определение, а пояснение. Что-то вроде "коромысло — это то чем носят воду". Что бы определять, уместно ли говорить об ООП в конкретном коде/технологии, нужно смотреть на присутствие фундаментальных концепций ООП. Ссылку я давал в предыдущем посте (на той же странице википедии, откуда вы взяли "определение"), вы ее проигнорировали.
"То чем носят воду" — определение коромысла, но неполное. Воду и в клюве носят, но клюв — не коромысло. Если уточнить "...состоящее из двух крюков для подвешивания ведер и перекладины для наплечного ношения", будет полное.
Определение ООП, приведенное в Википедии и процитированное мною — и определение, и полное. Проверим.
1. Определение — предикат, формула, в которую можно подставить что угодно (хоть бы и коромысло) и посмотреть, подходит ли это что угодно. Википедийная формула является таким предикатом, чисто по форме? Да, нет?
2. Если да, то полное ли оно? Можете вы привести пример чего-то, что укладывается в эту формулу, но не является ООП, как клюв в примере с определением коромысла?
Что касается концепций, это же не толковый словарь, а энциклопедия. Дав определение, авторы рассматривают концепции, почему нет?
S>Согласно "определению" о полях и методах COM не является объектной по причине отсутствия полей. Я читал ответ Синклеру, то что вы называете полями в виртуальном ООП, полями не является. S>Предлагаю не продолжать тему COM, вместо этого отклонить определение о полях и методах.
COM, как следует из названия, объектная модель компонентов (модулей). В свою очередь, модель — что угодно, используемое для представления чего угодно другого (я не шучу, http://en.wikipedia.org/wiki/Conceptual_model: In the most general sense, a model is anything used in any way to represent anything else.) Чисто из названия получается, что мы берем компонент, который, может быть, внутри даже не объектный, но представляем его как объектный.
С моей точки зрения, при этом поля появляются аж дважды: как настоящие поля и как свойства (нечто, что должно выглядеть как поля). В разговоре с Синклером дискуссия пошла по второму, более сложному, направлению. Нам с вами можно ограничиться первым. Вот те данные, которые инкапусированы в COM-объекты, и будут полями. Настоящими, без всякой виртуальности.
SV.>>Объекты от этого не перестают быть объектами, поскольку описаны в явном виде в библиотеке типов, которая считается неотъемлемой частью кода. Все методы и все свойства каждого объекта, исчерпывающе и неизбыточно. К WinAPI, напомню, ничего подобного не прилагается. S>Библиотека типов не является неотъемлемой частью кода. Она опциональна. S>А к ВинАПИ прилагается документация, книги, заголовки.
Я же все время об этом и толкую. Попробуйте научить машину выделить "объекты", опираясь на документацию и книги. А попробуйте — опираясь только на код. Разница станет очевидна.
Черт с ней, с машиной — я как человек человека вас спрошу: кто кого использует, контекст перо, или перо контекст?
Здравствуйте, netch80, Вы писали:
SV.>>Если это библиотека, то я совсем запутался. Протокол беседы, как я ее вижу — Я: "переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками". Вы: "Не совсем так", и приводите контр(?)пример — Berkeley DB.
N>Нет. Моё "не совсем так" было возражением не на эти слова, а на "то неважно, ООП это, процедуры, или еще что-то" (в том же абзаце). Я доказываю, что объектное построение — подход, который (по сравнению с обычным процедурным) упрощает использование кода, более того — за счёт поддерживаемых свойств является самым надёжным (в плане долговременных последствий) среди всех альтернативных подходов.
SV.>>По этому пункту победа за вами, но тут оказывается, что Berkeley DB — как раз-таки библиотека. Что же тогда вы имели в виду, написав "Не совсем так"?
N>Повторяю: я возражал против следующего тезиса: (выделен в цитате курсивом)
N>
1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.
N>Я доказываю, что выбор инфраструктуры реализации тут важен, потому что сам стиль интерфейса, когда свойства, настройки, и т.д. сосредоточены в "объекте" (чем бы он ни был), имеет существенное преимущество тем, что устраняет необходимость "таскать" за собой все необходимые параметры, свойства, уточнения того, что хотим сделать, которые чрезвычайно важны для типичной библиотеки; далее, когда это всё сосредоточено в некотором объекте, структура которого нам не важна, открывается обширное поле для оптимизации его работы. Где-то надо держать временный файл постоянно открытым, где-то — делать сложные вычисления параметров, которые лучше делать только один раз, и так далее. Есть хорошая аналогия — если вы поручаете какое-то постоянное дело подчинённому, то надо давать ему задания и требовать отчёта о выполнении, а не руководить каждым взмахом его руки. (Разумеется, есть и отрицательные стороны — он может сделать что-то не так; и функциональность в объекте может требовать лишнего; но какой подход без недостатков?) Чем сложнее задача, тем важнее логическое её представление в виде отдельных сущностей со своим поведением, и тем вероятнее её выигрыш от объектного подхода.
Теперь понял.
"Если это так" включало в себя "задумывалась как библиотека/API". Последнее же неявно предполагало, что интерфейс уже продуман, и его не придется менять. Ну, в крайнем случае, сделать одну обратно-совместимую major-ревизию с Ex-методами. Знаете шутку про функцию вычисления факториала на WinAPI с lpReserved? Это оно.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, samius, Вы писали:
S>>Да, каюсь. Слово вспомнилось, а как пишется и используется не освежил. Мне стыдно.
SV.>По-моему, вы поспешили с устыжением. Я не имел в виду наехать, а просто не понял (без фиги в кармане).
Дело собственно в том, что я в этой ветке тем и занимался что пристыживал по поводу употребления терминов не в их общеупотребимом смысле. Потому и не грех самому устыдиться.
SV.>Как пишется. Я вот вообще не уверен, что общепринятое русское написание этого слова корректно. Как мне объяснили, в словах латинского происхождения согласная в приставке после "а" должна удваиваться, если мы не хотим путать такие слова со словами греческого происхождения, где "а" — отрицательный префикс. Типа, атеист — антитеист, а аккумулятор — накопитель, а не антинакопитель. По этому правилу, "аффилиированный" и "аппелировать" должны писаться с двумя "ф" и "п" соответственно. У нас их пишут не так. Видимо, хотят путать, или, по крайней мере, не создают препятствий к путанице. Короче говоря, я бы не стал стыдиться написания "аппелировать". Откуда там должно быть две "п" как раз понятно, а откуда две "л" — нет. Потому и написал со скобками.
Очень интересно про букву "а" и удваивание согласной. Не знал.
SV.>Как используется. "Ап(п)ел(л)ировать к определению" в самом деле используется, но что это значит? Калька "обратимся к определению"? Тоже неглупо, вроде бы. Я лишь уточнил.
Вот здесь второе толкование сверху (в смысле ссылаться).
S>>По поводу оснований не принимать такое определение: ИМХО, это не определение, а пояснение. Что-то вроде "коромысло — это то чем носят воду". Что бы определять, уместно ли говорить об ООП в конкретном коде/технологии, нужно смотреть на присутствие фундаментальных концепций ООП. Ссылку я давал в предыдущем посте (на той же странице википедии, откуда вы взяли "определение"), вы ее проигнорировали.
SV.>"То чем носят воду" — определение коромысла, но неполное. Воду и в клюве носят, но клюв — не коромысло. Если уточнить "...состоящее из двух крюков для подвешивания ведер и перекладины для наплечного ношения", будет полное.
Вот так же структура и методы работы с ней не являются еще ООП. Причем, наоборот, есть примеры ООП где нет структуры и методов, либо они не связаны между собой отношением "together".
SV.>Определение ООП, приведенное в Википедии и процитированное мною — и определение, и полное. Проверим.
SV.>1. Определение — предикат, формула, в которую можно подставить что угодно (хоть бы и коромысло) и посмотреть, подходит ли это что угодно. Википедийная формула является таким предикатом, чисто по форме? Да, нет?
Нет. SV.>2. Если да, то полное ли оно? Можете вы привести пример чего-то, что укладывается в эту формулу, но не является ООП, как клюв в примере с определением коромысла?
struct CurrentLocation
{
static int x = 0;
static int y = 0;
static bool IsEqual(int x1, int y1) { return x == x1 && y == y1; };
};
Структура есть, метод тоже. Но к ООП я бы это относить не стал, даже учитывая то, что оно могло бы быть написано на ООП языке.
SV.>Что касается концепций, это же не толковый словарь, а энциклопедия. Дав определение, авторы рассматривают концепции, почему нет?
Рассмотренные концепции не имеют отношения к примеру, который я привел. Из этого можно сделать вывод, что либо определение не точное, либо концепции имеют слабое отношение к определению. Я склоняюсь к первому.
SV.>COM, как следует из названия, объектная модель компонентов (модулей). В свою очередь, модель — что угодно, используемое для представления чего угодно другого (я не шучу, http://en.wikipedia.org/wiki/Conceptual_model: In the most general sense, a model is anything used in any way to represent anything else.) Чисто из названия получается, что мы берем компонент, который, может быть, внутри даже не объектный, но представляем его как объектный.
Уточню, что COM это прежде всего инструмент для представления чего угодно в объектную модель. Но само по себе использование COM не гарантирует объектность того что мы оборачиваем в COM, даже через призму COM.
SV.>С моей точки зрения, при этом поля появляются аж дважды: как настоящие поля и как свойства (нечто, что должно выглядеть как поля). В разговоре с Синклером дискуссия пошла по второму, более сложному, направлению. Нам с вами можно ограничиться первым. Вот те данные, которые инкапусированы в COM-объекты, и будут полями. Настоящими, без всякой виртуальности.
Можем взять определение поля в ООП и показать что COM может инкапсулировать данные, хранящиеся совершенно другим способом, или даже вычислимые.
S>>Библиотека типов не является неотъемлемой частью кода. Она опциональна. S>>А к ВинАПИ прилагается документация, книги, заголовки.
SV.>Я же все время об этом и толкую. Попробуйте научить машину выделить "объекты", опираясь на документацию и книги. А попробуйте — опираясь только на код. Разница станет очевидна.
Разница есть, но на определение ООП она не влияет даже в той его форме, на которой вы настаиваете.
SV.>Черт с ней, с машиной — я как человек человека вас спрошу: кто кого использует, контекст перо, или перо контекст?
Имхо, и перо и контекст пассивны. Когда я зашруровываю ботинки, считается ли что шнурки используют ботинки? А если чай мешаю ложкой, то использует ли ложка чай?
Если серьезнее, то типично контекст инкапсулирует элементарные операции с ним. Перо по отношению к этим операциям является таким же атрибутом, как координаты в context.MoveTo(x,y). Но вот однозначности это не добавляет в отношении того, кто кого использует. Мы можем смотреть на это как на DrawLine(dc,...), так и на dc.DrawLine(...). В ООП языках принята вторая запись, а суть от этого не меняется.
Здравствуйте, m e, Вы писали: ME>что значить "недо"? принципиально нельзя что-то сэмулировать полностью, или требуются нелокальные преобразования, или... ?
Значит у вас а) не будет поддержки компилятора, и б) код будет получаться излишне многословным.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, samius, Вы писали:
SV.>>1. Определение — предикат, формула, в которую можно подставить что угодно (хоть бы и коромысло) и посмотреть, подходит ли это что угодно. Википедийная формула является таким предикатом, чисто по форме? Да, нет? S>Нет. SV.>>2. Если да, то полное ли оно? Можете вы привести пример чего-то, что укладывается в эту формулу, но не является ООП, как клюв в примере с определением коромысла? S>
S>struct CurrentLocation
S>{
S> static int x = 0;
S> static int y = 0;
S> static bool IsEqual(int x1, int y1) { return x == x1 && y == y1; };
S>};
S>
S>Структура есть, метод тоже. Но к ООП я бы это относить не стал, даже учитывая то, что оно могло бы быть написано на ООП языке.
Во-первых, не могло быть, а было написано на ООП-языке. Почему? Потому, что static (применительно к членам) специально служит в ООПных языках для обозначения неООПных мест в (преимущественно) ООПном коде.
Во-вторых, структуры-то ведь в вашем примере НЕТ. Если вы щелкните по гиперссылке в определении из Wikipedia, вы увидите, что data structure, о котором речь, и C++ structure — разные вещи. У вас приведена как раз последняя, но НЕ первая. В кривых языках слово struct в особо извращенных случаях (как у вас) может описывать то, что структурой не является. Поэтому, ваш пример принять не могу. Нет ли у вас более другого?
S>Уточню, что COM это прежде всего инструмент для представления чего угодно в объектную модель. Но само по себе использование COM не гарантирует объектность того что мы оборачиваем в COM, даже через призму COM.
Честно скажу: не понял.
Во-первых, с моей точки зрения, "инструмент для представления чего угодно в объектную модель" — масло масляное. Модель — сама по себе инструмент для представления чего угодно. Имеет смысл утверждение: "COM это прежде всего инструмент для представления чего угодно в виде объектов".
Во-вторых, уточнение это сужение. Я написал достаточно точно: компонентов (модулей). Вы заменили их на "чего угодно". Это (по форме) не уточнение, а обобщение. А по сути ваше обобщение я принять не могу. Что угодно как объекты вам COM представить не поможет. Только программные компоненты (модули).
В-третьих, "через призму COM" объектность гарантирована. На то она и модель.
S>Можем взять определение поля в ООП и показать что COM может инкапсулировать данные, хранящиеся совершенно другим способом, или даже вычислимые.
А другим это каким, например?
Что касается вычислимых, это направление дискуссии с Синклером. Прошу в ту подветку.
SV.>>Я же все время об этом и толкую. Попробуйте научить машину выделить "объекты", опираясь на документацию и книги. А попробуйте — опираясь только на код. Разница станет очевидна. S>Разница есть, но на определение ООП она не влияет даже в той его форме, на которой вы настаиваете.
Опять не понял. Есть определение. Оно делит все на две части — определяемое и все остальное. Между определяемым и всем остальным есть разница, отраженная в определении (наличие объектов, состоящих из методов и полей). Эта разница порождает другую разницу, как следствие (невозможность кластерного анализа, особеннно машинного).
Почему эта разница вообще должна влиять на определение? По-моему, не должна.
SV.>>Черт с ней, с машиной — я как человек человека вас спрошу: кто кого использует, контекст перо, или перо контекст? S>Имхо, и перо и контекст пассивны. Когда я зашруровываю ботинки, считается ли что шнурки используют ботинки? А если чай мешаю ложкой, то использует ли ложка чай?
Ну вот, по-вашему они пассивны, а в разных библиотеках то перо использует контекст, то контекст — перо. Неустранимая неоднозначность. Которая устраняется ручным проведением границ.
S>Если серьезнее, то типично контекст инкапсулирует элементарные операции с ним. Перо по отношению к этим операциям является таким же атрибутом, как координаты в context.MoveTo(x,y). Но вот однозначности это не добавляет в отношении того, кто кого использует. Мы можем смотреть на это как на DrawLine(dc,...), так и на dc.DrawLine(...). В ООП языках принята вторая запись, а суть от этого не меняется.
ГВ>>в известном смысле ООП приближено к образным структурам мышления обычного человека K>В известном смысле, ООП приближено к представлениям подкатегории необычных людей об образных структурах мышления обычного человека. Вот так будет вернее.
Думаю еще хуже. Объекты появляются лишь в конечном представлении программы, а думать о программе и об объектах из которых состоит программа нужно чем то другим. Иначе объекты были бы неизменяемы на всем протяжении жизненного цикла, прямо как правила логики. Так что объекты мы проектируем, а не думаем ими Если же отбрасывать процесс проектирования то останется только листинг наполненный объектами, отсюда и выходит у некоторых теоретиков, что только объекты и важны.
