Посоветуйте «легкий» язык для понимания принципов ООП

>Тоже мне нашёл лиспера, my ass. Тролль это, по должности. Срать ему на людей, что он старательно демострирует и лексиконом, и исходниками своими. Верный последователь своего кумира Erik Naggum, ото ж. Ты поменьше принимай за чистую монету то, что в инете, а тем более на ЛОРе набрасывают.

Добрый и заботливый анонимус учит жизни. Гыгы.

Сейчас хочу, не уделяя большого внимания особенностям синтаксиса, более глубоко постичь ООП. Что лучше выбрать?

Бери UML и не парь мозк

> Код говорит о том, что метод(ы) можно определить в замыкании.

покажи как вызвать этот метод из другого метода в объекте.

покажи как вызвать этот метод из другого метода в объекте.

(flet ((private-foo ()
         "hello from foo"))
  (defmethod bar ((obj foo))
    (private-foo))
  (defmethod baz ((obj foo))
    (private-foo)))

(baz (make-instance 'foo))

Всем спасибо за ответы и мысли. Кроме поставленного вопроса также открыл для себя очень много интересного =) Отдельно спсб Zubok ;)

а вот википедия с тобой несогласна

это должно меня удивлять?

т.е. ты продолжаешь утверждать что характерные признаки инкапсуляции не имеют отношения к ООП?

т.е. ты продолжаешь утверждать что характерные признаки инкапсуляции не имеют отношения к ООП?

Имеют, но им не ограничиваются.

зря я наверное попросил показать код, ибо не понимаю его :(

так он говорил что не имеют вообще, цитирую «ни-ка-ко-го».

зря я наверное попросил показать код, ибо не понимаю его :(

flet объявляет функцию(ии), видимые только в текущем лексическом окружении. Когда другая функция ссылается на такую функцию, создаётся замыкание, внутри которого видно отflet'ченную функцию, но снаружи её не видно.

defclass объявляет класс, defgeneric - мультиметод, defmethod - его специализацию по типу(ам).

так он говорил что не имеют вообще, цитирую «ни-ка-ко-го».

Примерно также, как ООП имеет отношение к программированию. Т.е. ООП - это программирование, но программирование - это не только ООП :)

Я бы не рекомендовал Python. Из того с чем я знаком я бы выбрал Java.

Уважаю таких людей.

ты продолжаешь утверждать что характерные признаки инкапсуляции не имеют отношения к ООП?

я утверждаю, что вышеназванные признаки не имеют отношения к инкапсуляции

для избежания недопонимания (комментариев ещё на д-цать) постараюсь развернуть мысль

инкапсуляция - это степень независимости интерфейса и реализации, чернота ящика в терминологии Алана Кэя; тем выше инкапсуляция, чем проще произвольным образом менять реализацию некоторого интерфейса. например, если в Haskell логику транзакционных операций я вынесу непосредственно в функцию-обработчик - я получу плохо инкапсулированную сущность; ежели я засуну её в монаду, и буду пользоваться в обработчике исключительно монадическим интерфейсом (join, >>=, return, etc), сущность станет хорошо инкапсулированной. во втором случае я в любой последующий момент смогу изменить эту логику на какую-то другую, не меняя код обработчика (так как интерфейс остался неизменным). аналогичным образом в Erlang высокая степень инкапсуляции обеспечивается динамикой топологии отправки сообщений: сообщение сможет принять любая нода, имеющая соответствующий обработчик; какая именно - личное дело программиста, который волен менять их в рантайм

единственная фактическая польза от квалификаторов доступа - самодокументированность классов; но, вообще говоря, для этого придуманы и куда более эффективные методики (например, literate programming)

> инкапсуляция - это степень независимости интерфейса и реализации, чернота ящика в терминологии Алана Кэя

Всё дело - в волшебных пузырьках^W^Wопределениях.

Всё дело - в волшебных пузырьках^W^Wопределениях.

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

> это определение имеет практический смысл

Замечательное определение. Только я не уверен, что оно имеет хоть какое-то отношение к «инкапсуляции».

И насчет того, что private/public - это всего лишь документация вроде literate programming: с каких пор конструкции literate programming проверяются компилятором?

>Если инженер по специальности «Котло- и Реакторостроение» может осилить лисп и найти по нему работу, то быть причастным к IT/CS и утверждать, что лисп - сложный язык, работы нет, et cetera, это если и не собственный приговор, то должно заставить о многом задуматься.

Вот тут точно. Плюсмиллион...

Только я не уверен, что оно имеет хоть какое-то отношение к «инкапсуляции»

для любителей википедии:

http://en.wikipedia.org/wiki/Information_hiding#Encapsulation

И насчет того, что private/public - это всего лишь документация вроде literate programming: с каких пор конструкции literate programming проверяются компилятором?

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

>> покажи как вызвать этот метод из другого метода в объекте.

мне казалось он имел в виду скорее

(flet ((private-foo () "hello from foo"))
  (defmethod bar ((obj foo))
    (private-foo)))

(defmethod baz ((obj foo))
  (bar obj))

(baz (make-instance 'foo)) 

> для любителей википедии:

Я люблю википедию, но не в таких случаях.

насчет того, что private/public - это всего лишь документация вроде literate programming: с каких пор конструкции literate programming проверяются компилятором?

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

Не много, но видел, и сам использовал. А какое это отношение имеет к тому, что public/private проверяется компилятором и является полезным инструментом?

Я люблю википедию, но не в таких случаях.

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

А какое это отношение имеет к тому, что public/private проверяется компилятором и является полезным инструментом?

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

> называй своих авторитетов. по ссылке приведено определение Буча

Я по ней не ходил.

кого берём в арбитры, выбирай

Для начала точно сформулируй, о чем мы спорим - о том, что public/private не имеют отношения к инкапсуляции?

А какое это отношение имеет к тому, что public/private проверяется компилятором и является полезным инструментом?

ну такое, что польза эта крайне сомнительна

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

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

Ты, похоже, имеешь в виду конкретный класс языков - C++/Java-подобные. А вот в Питоне я вполне могу работать с закрытым методом по ошибке.

> не хочешь ли ты сказать, что, например, при разработке библиотеки на Яве ты сделаешь интерфейс, через который будет работать пользователь, а потом в классе, реализующем этот интерфейс ты сделаешь все поля и методы public (или package, если ты слишком ленив для расстановки квалификаторов)?

могу и ошибаться, но думаю, что он хотел сказать, что управлять тем, что попадёт во вне, а что нет, он будет через список экспорта модуля.

А вот в Питоне я вполне могу работать с закрытым методом по ошибке.

как?

>> А вот в Питоне я вполне могу работать с закрытым методом по ошибке.

как?

Просто вызову метод, который не предназначался для вызова извне.

Просто это не сделать, потому и ошибиться довльно трудно.

>> не хочешь ли ты сказать, что, например, при разработке библиотеки на Яве ты сделаешь интерфейс, через который будет работать пользователь, а потом в классе, реализующем этот интерфейс ты сделаешь все поля и методы public (или package, если ты слишком ленив для расстановки квалификаторов)?

могу и ошибаться, но думаю, что он хотел сказать, что управлять тем, что попадёт во вне, а что нет, он будет через список экспорта модуля.

Я, конечно, 10 лет ничего не писал на Яве, но что такое «список экспорта модуля»? Насколько я помню, разрешено импортировать любой public-класс или интерфейс Ява-пакета.

Ну и вопрос-то был о том, что происходит внутри пакета.

>>>> А вот в Питоне я вполне могу работать с закрытым методом по ошибке.

как?

Просто вызову метод, который не предназначался для вызова извне.

Просто это не сделать

А что сложного? Посмотрел на список методов, вызвал.

потому и ошибиться довльно трудно.

Блин. Дело в том, что, когда ты ошибешься (или намеренно нарушишь правила), компилятор промолчит.

Можно пример привести иллюстрирующий возможность ошибки?

как обычно, пришли пораженные лиспом головного мозга и засрали всю тему

Можно пример привести иллюстрирующий возможность ошибки?

Один из нас чего-то не понимает.

class Foo(object):
   def foo(self): pass
   #private foo
   def pfoo(self): pass

f = Foo()
f.foo()
f.pfoo()

Один из нас чего-то не понимает.

Конечно, потому я и попросил пример. Еесли нужно метод/атрибут сделать приватным, то есть два способа: через соглашение именовать метод с '_' (паттерн) или с '__' (уже особенность объектной модели питона). Соответственно выглядеть будет так

class Foo(object): 
   def _foo(self): pass 
   #private foo 
   def __pfoo(self): pass 

Метод _foo можно вызвать обычным спосообом, как a._foo() (надежда на знакомство кодера с паттернами программирования на питоне), а метод __pfoo доступен как _Foo__pfoo (это уже добровольно-принудительный механизм). Просто так ошибиться и вызвать приватный метод довльно сложно. Всё это написано в введении к ЯП.

> Еесли нужно метод/атрибут сделать приватным, то есть два способа: через соглашение именовать метод с '_' (паттерн) или с '__' (уже особенность объектной модели питона).

Это всё так, хотя делается отнюдь не всегда.

Просто так ошибиться и вызвать приватный метод довльно сложно.

См. выше.

Я, конечно, 10 лет ничего не писал на Яве, но что такое «список экспорта модуля»? Насколько я помню, разрешено импортировать любой public-класс или интерфейс Ява-пакета.

ты так говоришь, как буд-то не знаешь, что jtootf любит Хаскелл

module
( func1
, func2
, type1(constructor1)
, type2(..)
) where

-- implementation here

Это всё так, хотя делается отнюдь не всегда.

Конечно, примерно так же, как и приватные члены в других ЯП оказываются, например, под public.

> примерно так же, как и приватные члены в других ЯП оказываются, например, под public.

Не-а. Язык прививает определенный стиль программирования. Гвидо много раз просили сделать квалификаторы доступа, но он каждый раз отказывался («Python will remain an 'open kimono' language»). Это идеология - оставлять всё доступным.

Не-а. Язык прививает определенный стиль программирования.

Точно, и все нужные паттерны описаны в документации для начинающих.

Это идеология - оставлять всё доступным.

Чувствуешь разницу между всё одинаково доступно и всё доступно с различной степенью 'сложности'?

> Чувствуешь разницу между всё одинаково доступно и всё доступно с различной степенью 'сложности'?

А ты чувствуешь разницу между «можно» и «нельзя»?

А ты чувствуешь разницу между «можно» и «нельзя»?

Плавно приходим к заключению, что ЯП это средство защиты от обезьянки с гранатой.

> Плавно приходим к заключению, что ЯП это средство защиты от обезьянки с гранатой.

К этому заключению переходишь ты.

Для начала точно сформулируй, о чем мы спорим

я, в общем-то, не имею желания спорить ни о чём. просил я определение инкапсуляции, в котором квалификаторы доступа были бы «характерными признаками»

при разработке библиотеки на Яве ты сделаешь интерфейс, через который будет работать пользователь, а потом в классе, реализующем этот интерфейс ты сделаешь все поля и методы public (или package, если ты слишком ленив для расстановки квалификаторов)

в Java это будет противоречить по крайней мере принятому стилю, потому я так делать не буду; в Java-подобном языке без квалификаторов доступа всё будет именно так по умолчанию, и я не вижу в этом никаких проблем: работать с объектом правильно (через интерфейс) значительно проще, чем неправильно (с обращением к полям напрямую), а значит всё в порядке. с тем же успехом можно говорить, что в C++ нет ООП (а в C нет абстракции данных), так как там ко всему можно получить доступ, работая с сырой памятью

Ты, похоже, имеешь в виду конкретный класс языков - C++/Java-подобные. А вот в Питоне

нет, я имею в виду произвольное ООП - хоть в XOTcl, хоть в O'Haskell

могу и ошибаться, но думаю, что он хотел сказать, что управлять тем, что попадёт во вне, а что нет, он будет через список экспорта модуля.

если речь идёт о модулях, то несомненно

> А ты чувствуешь разницу между «можно» и «нельзя»?

ага, я как-то спросил на лисповой конфе про инкапсуляцию в CL, дмитрий_вк «раставил все точки над ы». если мыслить бинарно «можно/нельзя», то да, такой инкапсуляции в питоне нет, а если «можно/неудобно», то есть. мягкая инкапсуляция. но вообще, имхо, не стоит предъявлять подобные претензии к динамическим языкам, на то они и динамические. для статических да, пожалуй неприемлемо подобное поведение.

> если мыслить бинарно «можно/нельзя», то да, такой инкапсуляции в питоне нет, а если «можно/неудобно»

пожалуй лучше заменить это предложение на

если подразумевается «можно/нельзя», то да, такой инкапсуляции в питоне нет, а если «удобно/неудобно»

> если речь идёт о модулях, то несомненно

а что ещё есть в Хаскелле для организации инкапсуляции? ну кроме замыканий

Первый вариант по смыслу происходящего подходит лучше всего, попадание в самую суть.

> я, в общем-то, не имею желания спорить ни о чём. просил я определение инкапсуляции, в котором квалификаторы доступа были бы «характерными признаками»

Определения нет, но, для любителей википедии: http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)

«In an object-oriented programming language encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination[1][2] thereof:

* A language mechanism for restricting access to some of the object's components.[3][4]»

при разработке библиотеки на Яве ты сделаешь интерфейс, через который будет работать пользователь, а потом в классе, реализующем этот интерфейс ты сделаешь все поля и методы public (или package, если ты слишком ленив для расстановки квалификаторов)

в Java это будет противоречить по крайней мере принятому стилю, потому я так делать не буду

Итак, не будешь; только из-за противоречия общепринятому стилю?

работать с объектом правильно (через интерфейс) значительно проще, чем неправильно (с обращением к полям напрямую)

Еще немного, и ты скажешь, что правильно работающие программы писать проще, чем неправильно работающие.