|
Модераторы: korob2001, ginnie |
|
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
А по теме, поднятой мной.
(см. http://forum.vingrad.ru/topic-132126.html ) Статья меня откровенно повеселила, Рад, что вас повеселила тоже. ИМХО, только две вещи автор отметил правильно. Все остальное - от (скорее всего) природной злобы автора и непонимания собственно Perl, его (Perl) назначения и места в мире языков программирования. Итак, две вещи: 1. Отсутствие нормальной (с точки зрения классического определения) поддержки ООП - объектно ориентированного программирования. Конечно, вы можете возразить, что на Perl все можно написать. Однако хочется, чтобы все это уже было внутри языка. Это лично меня приводит к некоторому внутренниему дискомфорту, когда пишешь на perl. А это, собственно, основной язык, которым я пользуюсь. 2. Неочевидность некоторых конструкций для (особенно) начинающего программиста-читателя. Неоднократно было подмечено. "Старт" проходит достаточно тяжело. Зато затем - почти все нормально. Из забавных фактов по этому поводу, хочется отметить, что одна моя знакомая, чтобы облегчить понимание приема параметров в процедуру, предложила назвать переменную @_ "собака с хвостом". Типа "а сейчас к нам пришла собака с хвостом". Вот так. Это сообщение отредактировал(а) Zuzu - 26.1.2007, 13:16 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, а какую-такую "нормальную" поддрежку ООП ты хотел?
В Perl можно создавать пакеты, классы, собственно, объекты, есть множественное наследование, делигирование, возможность обращения к структуре класса-предка, можно использовать локальные переменные, есть механизм связывания (tie). Вообще, чего нет изначально в интерпретаторе-компиляторе, давно уже написано в модулях и прагмах или можно написать. Чего ещё требуется? Добавлено @ 10:46 Я тут вот начал-таки читать "статью" и уже с самого начала она мне стала нравиться, большую роль в это проишествии сыграла первая же фраза "Статья посвящена популярному языку программирования PERL". Ну, коли он популярный, значит, его много кто использует, а он решил выявить и представить какие-то недостатки, которые, фактически, если даже есть, то те, кто пользуется языком (а он "популярный"), готовы с этими недостатками смириться и продолжают пользоваться плохим языком Perl. |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Еще раз повторю, руками можно написать все. Речь идет о поддержке именно на уровне языка. 1. Нет на уровне самого языка самого такого понятия как "свойство" класса и объекта. Приходится для этого создавать свою структуру типа хэш ("по классике") или массив (как сказано в Advanced Perl Programming), причем, все писать руками. Следствие - нарушение такого понятия как инкапсуляция. А именно, инкапсуляцию нарушает возможность обратится к свойству объекта напрямую, а не через интерфейс объекта. Также возникает гемморой с множественным наследованием "свойств". СкАжите: хочешь строгости - используй use fields Отвечу - не работает это в случае множественного наследования. В документации об этом написано (собственно, и так понятно, почему не работает). Понятно, что вы (как собственно, и классики, типа Гаммы (одна из книг отсюда: http://ooad.asf.ru/Files.aspx)) можите возразить: не используй множественное наследование (а лучше и наследование вообще) - а используй композицию (или, если быть более точным, агрегацию (aggregation)). Отвечу: иногда хочется. Т.к. проектировать и читать такие программы приятнее и проще. Приведу пример из своих последних новогодних экспериментов (на уровне посленовогоднего бреда): (абстрактное) животное (есть имя и цвет) -> кошка (есть имя и цвет, умеет мяукать) (абстрактное) животное (есть имя и цвет) -> рыба (есть имя и цвет, умеет плавать) кошка + рыба -> кошкарыба (есть имя и цвет, умеет и плавать и мяукать) Ну и по мелочи. На уровне мелкого дискомфорта. 2. Следствие отсутсвия типизации - отстутсвие такого типа данных, как "объект определенного класса". То, по поводу чего автор статьи аж весь изошелся. Видете-ли (пред)компилятор не проверяет наличие/отсутсвие описанных методов (и процедур, собственно), и ошибка возникает на этапе выполнения. Собственно, понятно. Нет типизации - сам за всем следи. Плата за гибкость. 3. Отсуствие внутренних (используемых только внутри объекта) методов. Все можно вызвать снаружи. Опять - нарушение инкапсуляции. Решается административными действиями, путем описания, что все, что начинается с _ (подчеркивания) - внутренний метод. И, дополнительно, на уровне контроллера приложения (Aplication Controller см: http://ooad.asf.ru/Patterns_title.aspx?IdKat=9), чтобы обеспечить внешнюю безопасность, чтобы любой пользователь (не программист!) не смог вызвать внутренний метод объекта. Это сообщение отредактировал(а) Zuzu - 18.1.2007, 14:39 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
nitr |
|
|||
Эксперт Профиль Группа: Участник Клуба Сообщений: 2543 Регистрация: 10.2.2006 Где: Россия :) Репутация: 37 Всего: 84 |
Zuzu, ждём Perl6 можно и тут глянуть, с чем предстоит... думаю тебе понравится ;)
Добавлено @ 18:26 тут |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, давай в приват, что ли. Поговорим на тему ООП.
Мне не понятно, почему ты говоришь, что у объекта в Perl нет свойств, т.к. свойства обычно хранятся в хэш-массиве, а если ты под свойствами имеешь в виду синтаксическое их написание без фигурных скобок, так это всего-то особенность языка (может, скажешь, что тебя и $ или % тяготит?). Таак, ну в Delphi, там можно указывать методы обработки работы со свойствами типа getter и setter. Это в Perl решается с помощью встроенной функции tie. Какой-такой геморрой со множественным наследованием? На счёт инкапсуляции. Таак. Ну, вот её-то и нету. Да, только, принципиально, она нужна? Объявление типа private беспокоит тех, кто борется за свои авторские права, а Perl создан как Free и OpenSource - идеология такая. Я принципиально-против типов данных в Perl - тоже нарушает идеологию, т.к. Perl создавался для манипуляции структурами данных, а про типы думать не надо. Не, ну ты мне приведи задачу, которую не возможно решить с помощью языка. [hr] nitr, про Perl6 уже обсуждали в другой теме. Это сообщение отредактировал(а) tishaishii - 18.1.2007, 20:07 |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, к стати, я вспомнил. Функции и свойства вроде private можно организовать с помощью встроенной функции caller и при определённом методе AUTOLOAD в классе.
|
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
tishaishii, отвечу лучше здесь. Про tie ты ведь мне идею подсказал, спасибо. Может еще у кого какие мысли будут.
1. Под свойством объекта я понимаю не конструкцию (на самом деле, вообще неважно, какого) языка типа "что-то там с фигурными скобочками", а вполне определенную вещь - некую область для хранения данных, принадлежащих объекту. При этом совокупная целостность (непротиворечивость) данных объекта должна быть реализована на уровне объекта. Простой пример - поле (строки) таблицы базы данных, для которого определено NOT NULL, а ему пытаются присвоить значение NULL. Что произойдет? DBMS выругается и неверного значения (в общем случае, строке) не присвоит! 2. За идею про tie и связывание свойств почитаю, спасибо. Но, ИМХО, очень уж тяжелая конструкция получается. 3. Privte методы реально упростили бы жизнь с точки зрения внешней безопасности приложения (см. п. 3 моего предыдущего топика). Напрягает больше не то, что нужно описывать (на уровне if или в самом объекте), какие из его методов можно вызывать снаружи (из web-интерфейса, например), а то, что потом все это нужно проверять. Объект-то про свою целостность должен знать сам! А если этот объект участвует во множественном наследовании - всех "родителей" приходится обходить "вручную", чтобы все это выяснить. Так что по поводу Private не нужно путать теплое с мягким! К авторским правам оно имеет такое же отношение, как морская свинка к морю. 4. Нет инкапсуляции - нет поддержки ООП (ООП есть инкапсуляция, наследование, полиморфизм). Извини, элементарная математическая логика. Все выражение истино тогда и только тогда, когда все его "слагаемые" истины. У Вирта, кажется это есть. Может у кого ссылка есть на библиотеку с книжками Вирта? Поделитесь ссылочкой. 5. Про AUTOLOD и "автоматическую генерацию методов", если ты внимательно почитаешь Advanced Perl Programming (и в Cookbook, кажется, написано тоже), там есть один прикол. До вызова AUTOLOAD необходимо определить (присвоить значение) элементу хэша. При отсутствии элемента инициируется исключение (die). И, собственно, понятно, почему. Нечего всякую ерунду для для объекта вызывать! При обычном наследовании еще можно определить (инициировать) значения элементов хэша путем обращения к процедуре инициализации своего суперкласса ($self->SUPER::_init() - как вариант). При множественном наследовании это не прокатит - нужно обходить всех "вручную". 6. Про типы данных - ты зря! Но это мое личное мнение. Я бы не отказался. 7. Написать можно что угодно и на чем угодно. Хоть в машинных кодах наколбасить. Особенно если воспользоваться "абстракцией потенциальной осуществимости" из математики (типа если все живем вечно и кормить никого не нужно - тогда напишем любую программу). Я не хочу "хаять Перл". Он меня кормит! Просто есть вещи, которых "жалко что в Перл нет". Вообще, сам на досуге "поиграйся" с поддержкой ООП в перле и попробуй реализовать классические вещи (хотя бы на уровне модели, когда результатом $aCat->speak просто является print "Meauuuu!!!\n"), которые описаны в литературе по ОО программированию (а лучше по ОО проектированию). Хотя бы с наследованием свойств и методов и их, (свойств и методов) полиморфизмом - раз уж выяснили, что инкапсуляции нет Лично мне это упражнение доставило в свое время истинное удовольствие. P.S. Господа модераторы! Подскажите тему, куда это все перенести! Извиняюсь за offtopic. --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Короче, прошу прощения, у меня не много времени на ответ.
Вот ты мне приведи задачу, которую не возможно решить на Perl. |
|||
|
||||
korob2001 |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
Вынес всё, что касается ООП в отдельную тему. Здесь можно продолжить обсуждение. -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
|||
|
||||
tishaishii |
|
||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, ну у меня реальные вещи в голове не укладываются пока без ООП. Так что играюсь уже с этим ООП в Perl года 2-2,5 и говорил тебе всё это не по-наслышке.
А что сложного там в tie - это не в курсе. На худой конец есть уже готовые модули (типа Tie::Hash... - http://search.cpan.org/search?query=Tie%3A...mp;mode=module). Ну вот тебе готовый код, например, для скаляра (можно использовать как свойство в классе):
а вот пример его применения:
Если есть вопросы как работает - пиши. Это сообщение отредактировал(а) tishaishii - 24.1.2007, 17:20 |
||||
|
|||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
tishaishii, спасибо за пример. Посмотрел код. Забавно.
Лично я фразы типа +$${$_[0]}{-setter}(@_) понимаю только после вдумчивого второго прочтения... Наверно, возраст, сказывается... Но все-таки понимаю, что радует! Спорить о том, как прогрммировать (и как не нужно программировать) считаю абсолютно бесполезным. Каждый, особенно если работает самостоятельно , а не в команде, волен выбирать это для себя сам. И собственно, "мысли по коду". Во-первых, лично я считаю, что класс (Class) должен сам знать о свойствах объектов, которые от него порождены и переписывать их (свойства) во время создания экземпляра (объекта) не считаю правильным. Нарушается идея "представления объекта, как черного ящика". Как следствие, если ты вдруг нашел ошибку в коде какого-то setter-а, например, то тебе придется его выискивать и исправлять ошибку во всем своем коде, а не "просто поменять в классе". А если твой класс используется в качестве компонента другой системы? Радости от такого программирования и дальнейшей поддержки кода очень мало. И еще, ИМХО. В нотации UML (по крайней мере UML 1.4) принято обозначать "закрытые" свойства с - в начале (-privateName), а "открытые" с + (+publicName). Т.к. в perl нет такого понятия как "закрытое свойство" на уровне языка, лично я предпочитаю на "смешивать понятия", а использовать принятые в Perl соглашения. А именно, если имя начинается с _ - это "внутренняя штучка" объекта (_name) . Иначе - "открытая штучка" (name). Это сообщение отредактировал(а) Zuzu - 25.1.2007, 15:27 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
tishaishii |
|
||||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Ну, пользуясь таким Class, ты можешь породить класс Child:
Использование:
Добавлено @ 19:27 Если хочешь обрабатывать аргументы в Child::new:
Это сообщение отредактировал(а) tishaishii - 25.1.2007, 19:24 |
||||||
|
|||||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Короче, ты уж определись, нужен тебе Perl 5.8, али - нет?
Он помогает легко решать многие проблемы, которые не так легко решить в друших языках (кроме Refal и Prolog, наверное). Но есть куча модулей на search.cpan.org, которые тебе чрезвычайно помогут. Возможно переписывание операторов (как в Ц). Возможно подключение АктивИкс-объектов - а их ты можешь создать сам, а вот такой простой язык с ними использовать очень удобно. Какие ещё-там проблемы с ООП - говори - предложу подходящее решение. Добавлено @ 23:07 Таак, ещё, про private тебе надо приводить пример про caller, AUTOLOAD и @AUTOLOAD? Это, как всегда, просто. При вызове метода, всего-то, надо распознать модуль, вызывающий метод. Для Perl 5.8 - это СЛОЖНЕЙШАЯ ЗАДАЧА. )))) |
|||
|
||||
Zuzu |
|
||||||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Спасибо, конечно. Если будут толковые вопросы - задам.
Опять-двадцать пять! Мы, видимо, просто говорим на разных языках и тебя сбило с толку замечание о том, что необходимо будет менять код в разных местах при нахождении ошибки... И чем твой код концептуально отличается от того, что было в предыдущем варианте? Да ничем! Ты определяешь (инициализируешь) структуру данных (вместе с getterom!) на этапе выполнения а не на этапе описания. Да еще через связывание с использованием tie, да еще передав ее (структуру) SUPER-классу... Что по мне, то я готов смириться с тем, что "хэш объекта" - вещь, которую "руками не трогать" (на уровне административных мер, как вариант, при работе в команде), а для определения (читай - "описания", которое можно понять даже не запуская программу, прочитав при этом код самого класса, а не "шарашась по всему коду") использовать что-то полегче типа трививального, рекомендованного в стандартной документаци по Perl.
При этом, по крайней мере, возникает иллюзия, что мы обращаемся к свойству объекта через интерфейс объекта (т.е. "как положено"). Как бесплатное приложение - можно проектировать задачу с помощью стандартных средств, понимающих UML (жалко, для перла нет автоматической генерации кода классов из них! собственно, понятно, почему). И реализация получается "тупее". Читай: - Через год можно будет ее понять, даже не вникая в суть проблемы. - Реализовывать и поддерживать можно будет отдать программисту, который "с неба звезд не хватает". - Вообще меньше загружен мозг при реализации, если пишешь код сам. Нужно просто "тюкать по клавишам" или, как вариант, сконцентрироваться на аспектах реализации, решая при этом одну частную проблему, а про общую логику "всего комплекса" можно просто на время забыть. Обо всем этом позаботились раньше при проектировании, тестировании и проверке модели на этапе проектирования. Можно даже попытаться доказать правильность алгоритма аналитически (т.е. без реализации, не запуская) - сам алгоритм-то меньше получается! Что-то стало смахивать на "религиозные войны"... А так вообще (скажу, наверно, банальную мысль) я придерживаюсь мнения, что каждый может все писать так, как ему удобнее. С учетом "административных требований" команды, в которой работаещь, конечно. --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
||||||
|
|||||||
tishaishii |
|
||||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Я указал параметры на этапе описания и с чего ты там взял про "выполнение", когда при описании модуля я использовал другой модуль и описал первый.
Ты вообще в курсе, что такое "SUPER::new"? Это аналог "super" в Java. И ты хочешь ещё бороться с тем, что ООП в Java плохое? И что означает восклицание
По-моему, ты просто не до конца понимаешь примера, что я написал. Чувствую, у тебя есть психологическая проблема: ты озлоблен, причём на вещь, которая существует только в твоём воображении - на язык программирования. |
||||||
|
|||||||
Правила форума "Perl" | |
|
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, korob2001, sharq. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Perl: Общие вопросы | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |