> ООП - это комбинация инкапсуляции, полиморфизма, наследования и абстракции.
Добавлю, что из всего вышеперечисленного только наследование присуще исключительно ООП. Поэтому существует мнение, что ООП - это наследование.
Выше уже (очень правильно) написали, что ООП — это объекты + сообщения. Где там наследование вообще? А так же, как инкапсуляция, полиморфизм и абстракция?
Чтобы доказать, что некоторое определение (например, от Алана Кэя) чего-либо (например, ООП) — "плохое", изменим это определение, сведя его к абсолютно другим (гораздо более нетривиальным и сложным концепциям), потом будем долго рассуждать про эти самые концепции (можно ещё на практике показать, что это всё плохо работает) и в результате сделаем вывод, что это определение плохое :)
Вместо того, чтобы признать, что исходное определение и вообще идею мы не понимаем, никогда на практике её не применяли, а вместо этого занимались демагогией.
Мало ли чего на заборах пишут. В Prolog есть логическая машина вывода, в Erlang этого и близко нет. Prolog не медленный.
Ой, прошу прощения! Я не сразу понял, что разговариваю с носителем Абсолютного и Окончательного Правильного Мнения, а ключевой вопрос у нас — наличие машины вывода… :) Все, больше вопросов не имею.
Во-первых, я намекал что далеко не все согласны с тем, что «Erlang совсем не декларативный». Например, в русской Wikipedia про Erlang почему-то прямо так русским по белому и пишут: «декларативный язык программирования». Впрочем, английская тоже поместила его в категорию декларативных.
Тем не менее, я как раз соглашусь — вопрос о декларативности Erlang-а очень спорный. Но просто потому, что трактовка термина «декларативный» довольно смутная.
И родство синтаксиса (практически бесспорно) «декларативного» Prolog и (якобы) «недекларативного» Erlang здесь только подливает масла в огонь. Просто потому, что синтаксис языка с потолка не берется — он, как ни крути, должен соответствовать тому, какие идеи в этот язык заложены. …В общем, удалил я дальнейшее развитие мысли о странностях противопоставления декларативности и императивности и соответствующего деления языков — не место тут разворачивать дискуссию по данной теме.
…Тем более, что я изначально всего-то лишь хотел обратить внимание, что Prolog в свое время стал источником идей и вдохновения не только в области «чистого» логического программирования. И это можно (а, возможно, и нужно) было отразить в статье. Вдруг кто-нибудь нашел бы это достаточным поводом, чтобы задуматься.
Тем более, что связь между Prolog и Erlang гораздо глубже, чем «просто взяли синтаксис». Не интересно разве, почему это для языка, который был предназначен для создания распределенных систем реального времени вдруг взяли синтаксис медленного и узкоспециализированного логического языка? и почему вдруг erlang-исты заявляют, что «Erlang started life as a modified prolog»? — то есть, не «просто взяли синтаксис», а взяли язык и доработали под другую проблематику! Более того, первый компилятор Erlang был написан именно на Prolog-е.
Вообще, ставить под сомнение бывает полезно. Но нужно ли оно лично вам? Каждый решает сам :)
Понятно, что языки принципиально разные. Но не вызывает ли (какого-нибудь… эээ… как бы это назвать…) удивления (может быть?), что такие разные языки, как весь такой декларативный и логический Prolog и совсем такой недекларативный, недофункциональный, а с акторами еще объектный Erlang внезапно имеют между собой нечто общее? Да синтаксис — и не так уж мало для такой огромной и принципиальной разницы. Не ломает шаблон? Не ставит, например, под сомнение «общепринятое» понятие «декларативности»?
Тогда уж он «реинкарнировался» не только в Ruby, но и в Java, и в Objective C, и даже в C# и еще много во что… Но нет! Чтобы «реинкарнироваться», надо умереть. А Smalltalk пока не собирается. Только не надо по этому поводу разводить здесь флейм ;)
Если «на самом деле так и есть», то дальше тут обсуждать нечего. Можете посвятить свою жизнь написанию идеального zero code и автоматизировать его тестирование …но без меня ;D
Вопрос про автоматизацию тестирования — настолько ни о чем, что автоматически причисляется к троллингу. К уже сказанному мне добавить нечего. В общем, к сожалению, не вижу темы для дальнейшего обсуждения в данной ветке.
Дядюшка Боб, конечно, далеко не всегда адекватно излагает чужие идеи, но приписывать ему такое — это не слишком? Получает, идеальная программа — пустая. Она, конечно, ничего не делает, но зато ее так легко изменить!
Не надо путать корректность программы и ее соответствие требованиям. Очевидно же: программа в любом случае должна решать поставленные задачи (соответствовать требованиям); пусть она это будет делать и не идеально (будет не «совсем корректной» или просто некорректной), но хотя бы так, чтобы ее кто-нибудь мог использовать. И уже только после этого может возникнуть желание ее изменить.
С некоторых пор — условно — нет проблем с *делегированием* (через какой-нибудь perform). А вот с *отправкой* как раз проблемы… как были, так и остались. Как-то не работает оно без рефлексии :-) Вы же, надеюсь, в курсе, как работает тот же perform?
Вы постоянно общаетесь какими-то намеками, недосказанными мыслями, «тестируете» мою эрудицию и т.п., а троллем обзывают при этом меня… но ладно… Угадывать что вы там подразумеваете не буду, так что
Объекты отвечают (или должны отвечать) на сообщения, и когда вы хотите что-то сделать – вы посылаете объекту сообщение, а уж как он обработает его — совершенно не важно.
Скорее уж, я «сокрушаюсь», что сообщение это не объект :-) Вот «всё есть объект», а сообщение — нет :-)
выдает true. На всякий случай, чтобы не воспроизводить ваш стиль, поясняю: экземпляры GHObjectGhostStub возвращают полученные сообщения в качестве результата; первые два условия — для того чтобы показать, что это именно посланное сообщение; третье условие, разумеется, избыточно, но вы же настаиваете ;)
Скорее, то, что это «имя» — *литерал*, а не выражение. То, что оно не может быть *вычислено*, если хотите.
При всем моем уважении, в двух представленных тут сообщениях, нет «сообщения 5».
Вы хотели послать 5? Я создал объект, представляющий сообщение «5», и послал его получателю.
А мне вот очевидно, что у *сообщения* как раз и нет какого-то такого «смысла». Он — «смысл», в вашей интерпретации — безусловно, есть. У протокола, например. Но не у какого-то конкретного *сообщения*. Хотя бы исходя из того, что в протоколах (да даже системах), которые построены не на сообщениях, такой «смысл» тоже присутствует :-)
То есть, поскольку данные тоже присутствуют даже в системах, которые построены не на сообщениях, нам должно быть очевидно, что их нет в сообщениях?
Каждая посылка сообщения выполняется с некоторой целью. Чтобы этой цели достичь, и отправитель, и получатель должны понимать смысл этого сообщения. Я не уверен, что смысл и протокол — одно и то же. Но не очень хочу обсуждать еще и это, не принципиально. Хотите, «запихните» «смысл» в «протокол» — тогда каждое сообщение будет получать свой смысл из него. В Smalltalk-е «смысл» закодирован в имени (селекторе сообщения).
И, в любом случае, что именно вы хотите введением в топик этого самого «смысла» объяснить — мне, к сожалению, так и не стало понятно.
Неужели так сложно? Вы согласились, что некий смысл есть (пусть и назвали его протоколом). Этот смысл может быть где-то, а может быть в самом сообщении. Первый выриант — Erlang, второй вариант — Smalltalk.
Дело именно в жесткой «склейке» передачи данных, и их обработки. Жесткой до такой степени, что, собственно, от передачи там ничего и не остается… и становится совершенно не понятно, чем такой message send *принципиально* отличается от function call.
Здесь мы вернулись в то место, где уже были (и, вроде бы, даже не раз) — смысла повторять пройденный путь не вижу.
Кстати, какой-нибудь, пресловутый, doesNotUnderstand (да и вообще, т.н. «делегирование» aka «forwarding») как раз очень показателен, в этом смысле. Вот вроде есть у меня готовое «сообщение» аMessage. Я даже знаю кому его надо отправить: aReceiver. Но выясняется, что aMessage — а это, если хотите, и есть те самые «чистые данные» — не сообщение. И отправить его я не могу. Нет у aMessage нужной для этого семантики. :-)
Теперь я не понимаю. Что такое aMessage? Просто в принятых среди Smalltalk-еров соглашениях aMessage намекает, что там экземпляр Message, и с его отправкой нет проблем. Или вы сокрушаетесь, что не можете отправить произвольный объект как сообщение? Можете, просто для этого надо «объяснить» объекту, с какой целью вы хотите это сделать — дать имя сообщению. Требование, что у сообщения должно быть имя, превращает сообщение в не-сообщение?
Выше уже (очень правильно) написали, что ООП — это объекты + сообщения. Где там наследование вообще? А так же, как инкапсуляция, полиморфизм и абстракция?
Чтобы доказать, что некоторое определение (например, от Алана Кэя) чего-либо (например, ООП) — "плохое", изменим это определение, сведя его к абсолютно другим (гораздо более нетривиальным и сложным концепциям), потом будем долго рассуждать про эти самые концепции (можно ещё на практике показать, что это всё плохо работает) и в результате сделаем вывод, что это определение плохое :)
Вместо того, чтобы признать, что исходное определение и вообще идею мы не понимаем, никогда на практике её не применяли, а вместо этого занимались демагогией.
А если нет типов?
Очевидно: между объектами.
Значит, то ООП, которое вы знаете — не ООП.
Следующий шаг: осознать, что TDD — не про тестирование, а про разработку; и пишутся не тесты, а спецификации.
Высказывание:
подтверждается :D
Во-первых, я намекал что далеко не все согласны с тем, что «Erlang совсем не декларативный». Например, в русской Wikipedia про Erlang почему-то прямо так русским по белому и пишут: «декларативный язык программирования». Впрочем, английская тоже поместила его в категорию декларативных.
Тем не менее, я как раз соглашусь — вопрос о декларативности Erlang-а очень спорный. Но просто потому, что трактовка термина «декларативный» довольно смутная.
И родство синтаксиса (практически бесспорно) «декларативного» Prolog и (якобы) «недекларативного» Erlang здесь только подливает масла в огонь. Просто потому, что синтаксис языка с потолка не берется — он, как ни крути, должен соответствовать тому, какие идеи в этот язык заложены. …В общем, удалил я дальнейшее развитие мысли о странностях противопоставления декларативности и императивности и соответствующего деления языков — не место тут разворачивать дискуссию по данной теме.
…Тем более, что я изначально всего-то лишь хотел обратить внимание, что Prolog в свое время стал источником идей и вдохновения не только в области «чистого» логического программирования. И это можно (а, возможно, и нужно) было отразить в статье. Вдруг кто-нибудь нашел бы это достаточным поводом, чтобы задуматься.
Тем более, что связь между Prolog и Erlang гораздо глубже, чем «просто взяли синтаксис». Не интересно разве, почему это для языка, который был предназначен для создания распределенных систем реального времени вдруг взяли синтаксис медленного и узкоспециализированного логического языка? и почему вдруг erlang-исты заявляют, что «Erlang started life as a modified prolog»? — то есть, не «просто взяли синтаксис», а взяли язык и доработали под другую проблематику! Более того, первый компилятор Erlang был написан именно на Prolog-е.
Вообще, ставить под сомнение бывает полезно. Но нужно ли оно лично вам? Каждый решает сам :)
Понятно, что языки принципиально разные. Но не вызывает ли (какого-нибудь… эээ… как бы это назвать…) удивления (может быть?), что такие разные языки, как весь такой декларативный и логический Prolog и совсем такой недекларативный, недофункциональный, а с акторами еще объектный Erlang внезапно имеют между собой нечто общее? Да синтаксис — и не так уж мало для такой огромной и принципиальной разницы. Не ломает шаблон? Не ставит, например, под сомнение «общепринятое» понятие «декларативности»?
Вопрос про автоматизацию тестирования — настолько ни о чем, что автоматически причисляется к троллингу. К уже сказанному мне добавить нечего. В общем, к сожалению, не вижу темы для дальнейшего обсуждения в данной ветке.
Не надо путать корректность программы и ее соответствие требованиям. Очевидно же: программа в любом случае должна решать поставленные задачи (соответствовать требованиям); пусть она это будет делать и не идеально (будет не «совсем корректной» или просто некорректной), но хотя бы так, чтобы ее кто-нибудь мог использовать. И уже только после этого может возникнуть желание ее изменить.
…???
…???
- отвечаю на поставленный вопрос:
- …и напомню одну цитату:
Утверждение неверное:например, так
выдает true. На всякий случай, чтобы не воспроизводить ваш стиль, поясняю: экземпляры GHObjectGhostStub возвращают полученные сообщения в качестве результата; первые два условия — для того чтобы показать, что это именно посланное сообщение; третье условие, разумеется, избыточно, но вы же настаиваете ;)Опять ложное утверждение:снова выдает true!
Каждая посылка сообщения выполняется с некоторой целью. Чтобы этой цели достичь, и отправитель, и получатель должны понимать смысл этого сообщения. Я не уверен, что смысл и протокол — одно и то же. Но не очень хочу обсуждать еще и это, не принципиально. Хотите, «запихните» «смысл» в «протокол» — тогда каждое сообщение будет получать свой смысл из него. В Smalltalk-е «смысл» закодирован в имени (селекторе сообщения).
Неужели так сложно? Вы согласились, что некий смысл есть (пусть и назвали его протоколом). Этот смысл может быть где-то, а может быть в самом сообщении. Первый выриант — Erlang, второй вариант — Smalltalk.Здесь мы вернулись в то место, где уже были (и, вроде бы, даже не раз) — смысла повторять пройденный путь не вижу.
…Только при чем тут #doesNotUnderstand?