Модераторы: korob2001, ginnie

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Объектно Ориентированное Программирование, Обсуждение ООП в Perl 
:(
    Опции темы
Zuzu
Дата 17.1.2007, 13:06 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 140
Регистрация: 19.10.2006
Где: Екатеринбург

Репутация: 3
Всего: 4



А по теме, поднятой мной. 

(см. http://forum.vingrad.ru/topic-132126.html )

Статья меня откровенно повеселила, Рад, что вас повеселила тоже. smile 

ИМХО, только две вещи автор отметил правильно. Все остальное - от (скорее всего) природной злобы автора и непонимания собственно Perl, его (Perl) назначения и места в мире языков программирования. Итак, две вещи:

1. Отсутствие нормальной (с точки зрения классического определения) поддержки ООП - объектно ориентированного программирования. Конечно, вы можете возразить, что на Perl все можно написать. Однако хочется, чтобы все это уже было внутри языка. Это лично меня приводит к некоторому внутренниему дискомфорту, когда пишешь на perl. А это, собственно, основной язык, которым я пользуюсь.

2. Неочевидность некоторых конструкций для (особенно) начинающего программиста-читателя. Неоднократно было подмечено. "Старт" проходит достаточно тяжело. Зато затем - почти все нормально. Из забавных фактов по этому поводу, хочется отметить, что одна моя знакомая, чтобы облегчить понимание приема параметров в процедуру, предложила назвать переменную @_ "собака с хвостом". Типа "а сейчас к нам пришла собака с хвостом".

Вот так.


Это сообщение отредактировал(а) Zuzu - 26.1.2007, 13:16
--------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно.
PM   Вверх
tishaishii
Дата 18.1.2007, 10:32 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 1262
Регистрация: 14.2.2006
Где: Москва

Репутация: 4
Всего: 8



Zuzu, а какую-такую "нормальную" поддрежку ООП ты хотел?
В Perl можно создавать пакеты, классы, собственно, объекты, есть множественное наследование, делигирование, возможность обращения к структуре класса-предка, можно использовать локальные переменные, есть механизм связывания (tie). Вообще, чего нет изначально в интерпретаторе-компиляторе, давно уже написано в модулях и прагмах или можно написать. Чего ещё требуется?

Добавлено @ 10:46 
Я тут вот начал-таки читать "статью" и уже с самого начала она мне стала нравиться, большую роль в это проишествии сыграла первая же фраза "Статья посвящена популярному языку программирования PERL". Ну, коли он популярный, значит, его много кто использует, а он решил выявить и представить какие-то недостатки, которые, фактически, если даже есть, то те, кто пользуется языком (а он "популярный"), готовы с этими недостатками смириться и продолжают пользоваться плохим языком Perl.
PM MAIL ICQ Skype   Вверх
Zuzu
Дата 18.1.2007, 12:08 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 140
Регистрация: 19.10.2006
Где: Екатеринбург

Репутация: 3
Всего: 4



Цитата(tishaishii @  18.1.2007,  13:32 Найти цитируемый пост)
Zuzu, а какую-такую "нормальную" поддрежку ООП ты хотел?


Еще раз повторю, руками можно написать все. Речь идет о поддержке именно на уровне языка.

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
--------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно.
PM   Вверх
nitr
Дата 18.1.2007, 18:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Участник Клуба
Сообщений: 2543
Регистрация: 10.2.2006
Где: Россия :)

Репутация: 37
Всего: 84



Zuzu, ждём Perl6 smile можно и тут глянуть, с чем предстоит... думаю тебе понравится ;)

Добавлено @ 18:26 
тут


--------------------
PM   Вверх
tishaishii
Дата 18.1.2007, 19:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 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
PM MAIL ICQ Skype   Вверх
tishaishii
Дата 19.1.2007, 06:15 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 1262
Регистрация: 14.2.2006
Где: Москва

Репутация: 4
Всего: 8



Zuzu, к стати, я вспомнил. Функции и свойства вроде private можно организовать с помощью встроенной функции caller и при определённом методе AUTOLOAD в классе.
PM MAIL ICQ Skype   Вверх
Zuzu
Дата 19.1.2007, 14:00 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 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"), которые описаны в литературе по ОО программированию (а лучше по ОО проектированию). Хотя бы с наследованием  свойств и методов и их, (свойств и методов) полиморфизмом - раз уж выяснили, что инкапсуляции нет smile Лично мне это упражнение доставило в свое время истинное удовольствие.

P.S. Господа модераторы! Подскажите тему, куда это все перенести! Извиняюсь за offtopic.
--------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно.
PM   Вверх
tishaishii
Дата 19.1.2007, 16:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 1262
Регистрация: 14.2.2006
Где: Москва

Репутация: 4
Всего: 8



Короче, прошу прощения, у меня не много времени на ответ.
Вот ты мне приведи задачу, которую не возможно решить на Perl.
PM MAIL ICQ Skype   Вверх
korob2001
Дата 23.1.2007, 21:31 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Комодератор
Сообщений: 2871
Регистрация: 29.12.2002

Репутация: 31
Всего: 61



Цитата(Zuzu @  19.1.2007,  11:00 Найти цитируемый пост)
P.S. Господа модераторы! Подскажите тему, куда это все перенести! Извиняюсь за offtopic.

Вынес всё, что касается ООП в отдельную тему. Здесь можно продолжить обсуждение.


--------------------
"Время проходит", - привыкли говорить вы по неверному пониманию. 
"Время стоит - проходите вы".
PM MAIL WWW ICQ MSN   Вверх
tishaishii
Дата 24.1.2007, 17:19 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 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).

Ну вот тебе готовый код, например, для скаляра (можно использовать как свойство в классе):
Код

#Class.pm

package Property;
BEGIN {*UNTIE=*DESTROY}

sub TIESCALAR {
    print "creating layer..\n";
    my$self=\{};
    bless $self, $_[0];
    if(defined $_[1]) {
        $self->STORE($_[1]{-default})             if exists $_[1]{-default};
        $$$self{-getter}=$_[1]{-getter}           if exists $_[1]{-getter};
        $$$self{-setter}=$_[1]{-setter}           if exists $_[1]{-setter};
        $$$self{-destroyer}=$_[1]{-destroyer}     if exists $_[1]{-destroyer};
        $$$self{-aftertie}=$_[1]{-aftertie}       if exists $_[1]{-aftertie};
    }
    $$$self{-aftertie}($self, @_) if exists $$$self{-aftertie};
    +$self
}

sub FETCH     {
    if(exists $${$_[0]}{-getter}) {
        +$${$_[0]}{-getter}(@_)
    } else {
        print "getter called..\n";
        +${+shift}
    }
}
sub STORE     {
    if(exists $${$_[0]}{-setter}) {
        +$${$_[0]}{-setter}(@_)
    } else {
        print "setter called..\n";
        +${+$_[0]}=$_[1]
    }
}
sub DESTROY   {
    if(exists $${$_[0]}{-destroyer}) {
        +$${$_[0]}{-destroyer}(@_)
    } else {
        print "destroyer of worlds..\n";
        +shift
    }
}

package Class;
#описание класса для размножения

sub new {
    my($class, $self)=(shift, {@_});
    foreach(keys %{$self->{-properties}||={}}) {
        tie $self->{$_}, Property, $self->{-properties}{$_};
        print $_, "\n";
    }
    delete $self->{-properties};
    +bless $self, $class;
}


а вот пример его применения:
Код

#test.pl

package Child;
push @ISA, 'Class';
#пример дочернего класса

package main;

my$o1=Child->new( #описание объекта с нужными свойствами
    -properties=>{
        p1=>{
            -default=>1,
            -getter=>sub {
                print "Your getter\n";
                +${+shift}
            }
        },
        p2=>{
            -default=>3,
            -destroyer=>sub {
                print "Your destroyer\n";
            }
        }
    }
);
print $o1->{p1}, "\n";
$o1->{p1}=2;


Если есть вопросы как работает - пиши.

Это сообщение отредактировал(а) tishaishii - 24.1.2007, 17:20
PM MAIL ICQ Skype   Вверх
Zuzu
Дата 25.1.2007, 15:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 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
--------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно.
PM   Вверх
tishaishii
Дата 25.1.2007, 19:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 1262
Регистрация: 14.2.2006
Где: Москва

Репутация: 4
Всего: 8



Ну, пользуясь  таким Class, ты можешь породить класс Child:
Код
package Child;
push @ISA, 'Class';
#пример дочернего класса

sub new {
    +shift->SUPER::new(
        -properties=>{
            p1=>{
                -default=>1,
                -getter=>sub {
                    print "Your getter\n";
                    +${+shift}
                }
            },
            p2=>{
                -default=>3,
                -destroyer=>sub {
                    print "Your destroyer\n";
                }
            }
        }
    );
}

sub run {
    print "Running...\n";
    +shift
}

Использование:
Код

my$o1=Child->new;
print $o1->{p1}, "\n";
$o1->run;
$o1->{p1}=2;


Добавлено @ 19:27 
Если хочешь обрабатывать аргументы в Child::new:
Код

sub new {
    my$self=shift->SUPER::new(
        -properties=>{
            p1=>{
                -default=>1,
                -getter=>sub {
                    print "Your getter\n";
                    +${+shift}
                }
            },
            p2=>{
                -default=>3,
                -destroyer=>sub {
                    print "Your destroyer\n";
                }
            }
        }
    );
    my$args={@_};
# ..... делаешь с аргументами всякую каку
    +$self
}


Это сообщение отредактировал(а) tishaishii - 25.1.2007, 19:24
PM MAIL ICQ Skype   Вверх
tishaishii
Дата 25.1.2007, 22:59 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 1262
Регистрация: 14.2.2006
Где: Москва

Репутация: 4
Всего: 8



Короче, ты уж определись, нужен тебе Perl 5.8, али - нет?
Он помогает легко решать многие проблемы, которые не так легко решить в друших языках (кроме Refal и Prolog, наверное). Но есть куча модулей на search.cpan.org, которые тебе чрезвычайно помогут. Возможно переписывание операторов (как в Ц). Возможно подключение АктивИкс-объектов - а их ты можешь создать сам, а вот такой простой язык с ними использовать очень удобно. Какие ещё-там проблемы с ООП - говори - предложу подходящее решение.

Добавлено @ 23:07 
Таак, ещё, про private тебе надо приводить пример про caller, AUTOLOAD и @AUTOLOAD?
Это, как всегда, просто. При вызове метода, всего-то, надо распознать модуль, вызывающий метод. Для Perl 5.8 - это СЛОЖНЕЙШАЯ ЗАДАЧА. smile))))
PM MAIL ICQ Skype   Вверх
Zuzu
Дата 30.1.2007, 17:36 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 140
Регистрация: 19.10.2006
Где: Екатеринбург

Репутация: 3
Всего: 4



Цитата(tishaishii @  26.1.2007,  01:59 Найти цитируемый пост)
Какие ещё-там проблемы с ООП - говори - предложу подходящее решение


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

Цитата(tishaishii @  25.1.2007,  22:24 Найти цитируемый пост)


sub new {
    my$self=shift->SUPER::new(
        -properties=>{
            p1=>{
                -default=>1,
                -getter=>sub {
                    print "Your getter\n";
                    +${+shift}
   ...


      
Опять-двадцать пять! Мы, видимо, просто говорим на разных языках и тебя сбило с толку замечание о том, что необходимо будет менять код в разных местах при нахождении ошибки... И чем твой код концептуально отличается от того, что было в предыдущем варианте? Да ничем! Ты определяешь (инициализируешь) структуру данных (вместе с getterom!) на этапе выполнения а не на этапе описания. Да еще через связывание с использованием tie, да еще передав ее (структуру) SUPER-классу... Что по мне, то я готов смириться с тем, что "хэш объекта" - вещь, которую "руками не трогать" (на уровне административных мер, как вариант, при работе в команде), а для определения (читай - "описания", которое можно понять даже не запуская программу, прочитав при этом код самого класса, а не "шарашась по всему коду") использовать что-то полегче типа трививального, рекомендованного в стандартной документаци по Perl.

Код

...
sub p1 {
my $self = shift;
if (@_) {       # setter
  $self->{P1} = shift;
  warn "Your setter called\n";
} else{
  warn "Your getter called\n";
}
return ($self->{P1} || 1);     # default value
}
...
$anObject->p1('Some value');
print 'Value is ' . $anObject->p1 . "\n";



При этом, по крайней мере, возникает иллюзия, что мы обращаемся к свойству объекта через интерфейс объекта (т.е. "как положено"). Как бесплатное приложение - можно проектировать задачу с помощью стандартных средств, понимающих UML (жалко, для перла нет автоматической генерации кода классов из них! собственно, понятно, почему). И реализация получается "тупее". Читай:

- Через год можно будет ее понять, даже не вникая в суть проблемы.
- Реализовывать и поддерживать можно будет отдать программисту, который "с неба звезд не хватает".
- Вообще меньше загружен мозг при реализации, если пишешь код сам. Нужно просто "тюкать по клавишам" или, как вариант, сконцентрироваться на аспектах реализации, решая при этом одну частную проблему, а про общую логику "всего комплекса" можно просто на время забыть. Обо всем этом позаботились раньше при проектировании, тестировании и проверке модели на этапе проектирования. Можно даже попытаться доказать правильность алгоритма аналитически (т.е. без реализации, не запуская) - сам алгоритм-то меньше получается!

Что-то стало смахивать на "религиозные войны"... А так вообще (скажу, наверно, банальную мысль) я придерживаюсь мнения, что каждый может все писать так, как ему удобнее. С учетом "административных требований" команды, в которой работаещь, конечно.


--------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно.
PM   Вверх
tishaishii
Дата 2.2.2007, 02:46 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 1262
Регистрация: 14.2.2006
Где: Москва

Репутация: 4
Всего: 8



Цитата
Опять-двадцать пять! Мы, видимо, просто говорим на разных языках и тебя сбило с толку замечание о том, что необходимо будет менять код в разных местах при нахождении ошибки... И чем твой код концептуально отличается от того, что было в предыдущем варианте? Да ничем! Ты определяешь (инициализируешь) структуру данных (вместе с getterom!) на этапе выполнения а не на этапе описания. Да еще через связывание с использованием tie, да еще передав ее (структуру) SUPER-классу...

Я указал параметры на этапе описания и с чего ты там взял про "выполнение", когда при описании модуля я использовал другой модуль и описал первый. 
Цитата
да еще передав ее (структуру) SUPER-классу...

Ты вообще в курсе, что такое "SUPER::new"? Это аналог "super" в Java. И ты хочешь ещё бороться с тем, что ООП в Java плохое? И что означает восклицание 
Цитата
Да еще через связывание с использованием tie, да еще передав ее (структуру) SUPER-классу...
? Я не в полне тебя понял, что зазорного-такого в связывании (тем более через tie), когда я передавал структуру супер-классу и что в этом может быть такого нехорошего?
По-моему, ты просто не до конца понимаешь примера, что я написал.
Чувствую, у тебя есть психологическая проблема: ты озлоблен, причём на вещь, которая существует только в твоём воображении - на язык программирования.
PM MAIL ICQ Skype   Вверх
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Perl"
korob2001
sharq
  • В этом разделе обсуждаются общие вопросы по языку Perl
  • Если ваш вопрос относится к системному программированию, задавайте его здесь
  • Если ваш вопрос относится к CGI программированию, задавайте его здесь
  • Интерпретатор Perl можно скачать здесь ActiveState, O'REILLY, The source for Perl
  • Справочное руководство "Установка perl-модулей", можно скачать здесь


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, korob2001, sharq.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Perl: Общие вопросы | Следующая тема »


 




[ Время генерации скрипта: 0.1793 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.