Здравствуйте, grosborn, Вы писали:
G>http://msdn.microsoft.com/en-us/library/windows/desktop/dd183395(v=vs.85).aspx G>Brush Functions
G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП? И если это не процедурный подход, то как выглядит "настоящий" процедурный подход? G>И если это ООП, то навиг мы вообще на ООП переходили, почему не кодировали все в таком же стиле?
С чего ты взял? Где там ООП? И окна тоже изначально процедурный подход. Изначально все API писали в этом стиле, а ООП использовать начинали на прикладном уровне.
Это процедурный подход потом перепевали при создании ООП попутно сильно изменив методологию и сильно дополнив, а не наоборот.
И, извините, земля круглая и вертится вокруг солнца, а не наоборот. И слонов с черепахами там не было, если что.
G>С чего ты взял? Где там ООП? И окна тоже изначально процедурный подход. Изначально все API писали в этом стиле, а ООП использовать начинали на прикладном уровне.
Там нет ООП, но ОО в стиле Алана Кея в полный рост.
Классы, сообщения, наследование все есть. Тот кто это писал явно видел Smaltallk.
G>Это процедурный подход потом перепевали при создании ООП попутно сильно изменив методологию и сильно дополнив, а не наоборот.
Тут концов не найдешь, современный хороший процедурный подход (структурное программирование Дейкстры) появился
в 70-ые годы, а ОО в виде симулы это 1967 год, так что постарше даже чуть.
G>И, извините, земля круглая и вертится вокруг солнца, а не наоборот. И слонов с черепахами там не было, если что.
Здравствуйте, grosborn, Вы писали:
G>Тяжело читать твои посты, полны нелогичности и непонятных выводов. G>Вот опять это вот высказывание. Но ведь я не делал таких выводов, что стиль программирования и язык жестко связаны. "если C, то не ООП", это же ведь твое предположение, которое почему-то ты же и опровергаешь.
Что опять? На нелогичность до этого ты мне так и не указал. Да и эта "нелогичность" куда логичнее твоего отсыла к обезьянам и истории без каких-то конкретных исторических фактов. Извини, я придумал причину, по которой ты считаешь WinAPI не OOP, за тебя. Навеяло твоей отсылкой к истории. Если у тебя другая причина, то ты таки укажи ее, что бы мне опять не домысливать.
G>Но предположим, это была просто фигура речи, а если отбросить фантазии, за этой фигурой речи в десятый раз повторяется утверждение, что Win API это ООП подход, но написаный в процедурном стиле со структурами.
Твоя интерпретация утверждения весьма далека от его смысла. Винапи демонстрирует все формальные черты ООП, выявленные Пирсом с коллегами. На чем он и с помощью чего написан — не суть важно, т.к. инструмент не является определяющим фактором.
G>Я не понимаю. Мне конечно лень как-то обосновывать просто свое мнение. Ну предположим, ты об этом попросил. G>Ну вот был процедурный стиль со структурами. Назывался он процедурным стилем. Возьмем какой-нибудь первый попавшийся пример. Выбираю случайный пример.
Ты не понимаешь, это я понял. То что тебе лень обосновывать свое мнение — тоже. И давай допустим что я об этом действительно попросил.
G>http://msdn.microsoft.com/en-us/library/windows/desktop/dd183395(v=vs.85).aspx G>Brush Functions
G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП? И если это не процедурный подход, то как выглядит "настоящий" процедурный подход? G>И если это ООП, то навиг мы вообще на ООП переходили, почему не кодировали все в таком же стиле?
Вот что интересно... Разве ты объясняешь свое мнение (как я тебя будто бы попросил)? Вместо этого ты опять спрашиваешь мое. Это ты называешь "логичностью"?
Но я все равно отвечу, предположив, что ты действительно меня спросил.
G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП?
Наличие формальных признаков ООП. G>И если это не процедурный подход, то как выглядит "настоящий" процедурный подход?
Примерно так же, только в нем нет значительной части признаков ООП.
G>И если это ООП, то навиг мы вообще на ООП переходили, почему не кодировали все в таком же стиле?
Так это и есть ООП. О переходе на какое еще ООП с этого ООП ты говоришь?
Почему не кодировали — ну так это к тебе вопрос. Многие до сих пор кодируют в таком стиле, придерживаясь при этом ООП практик. В то время как другие кодируют процедурно на ООП языках.
Ответь теперь, что тебя заставляет утверждать что это именно процедурный подход, а не ООП? Ответ за тебя я уже придумал и посмеялся над ним, но для интереса пока его не буду вбивать. Вполне возможно что я и не угадал.
> Тут концов не найдешь, современный хороший процедурный подход (структурное программирование Дейкстры) появился
Как это не найдешь концов? Вы действительно хотите переписать историю по данным википедии. История гибнет под напором самиусов. Все ходы записаны — коды->ассемблеры->процедурные языки-ООП. Оно не параллельно развивалось, а последовательно.
Здравствуйте, grosborn, Вы писали:
>> Тут концов не найдешь, современный хороший процедурный подход (структурное программирование Дейкстры) появился
G>Как это не найдешь концов? Вы действительно хотите переписать историю по данным википедии. История гибнет под напором самиусов. Все ходы записаны — коды->ассемблеры->процедурные языки-ООП. Оно не параллельно развивалось, а последовательно.
Вот видишь, моя догадка о том что ты языки связываешь с подходом была все-таки верна. Ты сам в этом расписался.
Re[20]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, grosborn, Вы писали:
>> Вот видишь, моя догадка о том что ты языки связываешь с подходом была все-таки верна. Ты сам в этом расписался.
G>Капец. ООП уже язык? Оо-о-о... помираю.... Даже аналогию с обезъянами ты так и не понял.
Я понял что ожидать от тебя аргументов другого уровня не стоит.
Здравствуйте, grosborn, Вы писали: G>http://msdn.microsoft.com/en-us/library/windows/desktop/dd183395(v=vs.85).aspx G>Brush Functions
Прекрасный пример. G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП?
1. Непрозрачность HBRUSH. Это не структура, а object identifier.
2. Наличие полиморфизма. Смотрим, к примеру, сюда и обнаруживаем, что волшебные функции SelectObject и DeleteObject корректно работают со всеми видами кистей.
Если вас интересует, как выглядит просто процедурное программирование, ознакомьтесь со старым C RTL с его FILE*
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Язык ДРАКОН — новая идея в программировании
>>> Вот видишь, моя догадка о том что ты языки связываешь с подходом была все-таки верна. Ты сам в этом расписался. > > G>Капец. ООП уже язык? Оо-о-о... помираю.... Даже аналогию с обезъянами ты так и не понял. > Я понял что ожидать от тебя аргументов другого уровня не стоит.
??? Ты думаешь я обязан доказывать неверность твоих предположений? Я никогда не связывал языки и парадигмы, это твои личные заблуждения, разбирайся со своими личными проблемами сам. Нормальный человек просто спросил бы меня и получил бы честный ответ, а твой путь настоящего джедая не принесет тебе ни чуть знаний.
Posted via RSDN NNTP Server 2.1 beta
Забанен на рсдн за применение слова "Маргинал"
Re[23]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, grosborn, Вы писали:
>> Я понял что ожидать от тебя аргументов другого уровня не стоит.
G>??? Ты думаешь я обязан доказывать неверность твоих предположений? Я никогда не связывал языки и парадигмы, это твои личные заблуждения, разбирайся со своими личными проблемами сам. Нормальный человек просто спросил бы меня и получил бы честный ответ, а твой путь настоящего джедая не принесет тебе ни чуть знаний.
Здравствуйте, grosborn, Вы писали:
>> Тут концов не найдешь, современный хороший процедурный подход (структурное программирование Дейкстры) появился
G>Как это не найдешь концов? Вы действительно хотите переписать историю по данным википедии. История гибнет под напором самиусов. Все ходы записаны — коды->ассемблеры->процедурные языки-ООП. Оно не параллельно развивалось, а последовательно.
То есть симулы не было?
История очень далека была от линейной, про lisp ты тоже забыл, пролог не существовал?
Линейная она как раз у победителей то есть структурного подхода и мейнстримного сейчас ООП.
Здравствуйте, grosborn, Вы писали:
G>WinAPI это не ООП, это именно модульная идеология не ОО. Про наследование в Win API это ты конечно размечтался и тебя занесло.
WinAPI — это объектно-ориентированный API, выраженный при помощи процедурного языка.
Что такое ООП? Чёткого определения нет, но обычно упоминают "три главных слова": инкапсуляция, наследование, полиморфизм.
Давай посмотрим на пример из WinAPI — GDI:
Там есть инкапсуляция — все детали реализации функций скрыты за непрозрачными device-handle`ами.
Там есть наследование и полиморфизм: существует много разных реализаций абстракции "устройство" — окно, принтер, растр в памяти, WMF и даже поверхность DirctDraw.
Со всеми ты работаешь единым образом (в терминах ООП это бы звучало как "через интерфейс базового класса device"), но конкретная реализация метода относится к конкретному типу устройства. Итак, мы видим все три основополагающих принципа ООП.
Ты, видимо, считаешь, что раз нет привычного синтаксиса: ключевого слова "class", "new", оператора "." и т.п., то нет и ООП.
Это не так.
А вот и штатный форумный тролль подтянулся. Здравствуйте.
> 1. Непрозрачность HBRUSH. Это не структура, а object identifier.
И сразу переврал. Это не object identifier, а внутренний идентификатор структур данных в ОС. Если бы это был object identifier, он так и назывался бы — object identifier. А он называется хэндл.
> 2. Наличие полиморфизма. Смотрим, к примеру, сюда и обнаруживаем, что волшебные функции SelectObject и DeleteObject корректно работают со всеми видами кистей.
Есть еще более обобщающий пример — CloseHandle().
То есть то что одна единственная процедура освобождает разные структуры данных ОС по идентификатору, это ты считаешь ОО подоходом. То есть вообразил себе, что все (группы процедур со струтурами), это на самом деле не процедуры со структурами, а объекты. То есть тебе даже не важна внутренняя реализация, не важна нотация, не важна даже (!)группировка процедур в объект, просто назвал объектом и вуаля — ООП готово.
Да я что, спорить не будут. Зато весело.
> Если вас интересует, как выглядит просто процедурное программирование, ознакомьтесь
Я знаю как выглядит процедурное программирование, в отличие от некоторых. Ты привел пример аналогичный моему, за исключением того, что это обертка функций Win API.
> То есть симулы не было? > История очень далека была от линейной, про lisp ты тоже забыл, пролог не существовал? > > Линейная она как раз у победителей то есть структурного подхода и мейнстримного сейчас ООП.
Я собственно мейнстрим и обзначил, последовательность формулирования основных подходов. Ни симула ни лисп не меняют эту последовательность, процедурный стиль возник до симулы и лиспа (не в современном виде конечно).
Здравствуйте, Sinclair, Вы писали:
S>1. Непрозрачность HBRUSH. Это не структура, а object identifier.
Ну инкапсуляция это общий паттерн.
S>2. Наличие полиморфизма. Смотрим, к примеру, сюда и
обнаруживаем, что волшебные функции SelectObject и DeleteObject корректно работают со всеми видами кистей.
Полиморфизм тоже.
S>Если вас интересует, как выглядит просто процедурное программирование, ознакомьтесь со старым C RTL с его FILE*
FILE * же по стандарту не прозрачный, и может выводить на разные устройства.
