Forum Webscript.Ru
Программирование => Perl => Тема начата: Skif от 14 Февраля 2005, 17:49:40
-
Вот дорос(наверное) недавно, до создания своих модулей. И тут же обзавелся рядом вопросов.
Например, раннее мне требовалось написать какой-то sub, который бы возвращал несколько значений, то я писал нечто сродни этому
sub myfunc(???) {
# Здесь что-то делал с переменными
}
Вызывал из скрипта чем-то подобным
&myfunc($val1,$val2,$val3);
Но теперь такой вариант не прокатывает.
Мне нужно в модуле обработать уже имеющуюся функцию и получить несколько значений назад. причем каждое из значений передать строго определенным переменным/массивам.
насколько я понимаю нужно смотреть в сторону return в sub, но вот не понимаю как.
например если я напишу так в модуле
sub myfunc {
# Здесь что-то делал с переменными
return ($val1,$val2);
}
А вызывать буду на подобе такого:
our (val1,val2);
&myfunc;
То в модуль сделает все необходимые операции и вернет именно моим, указанным в скрипте, а не модуле $val1,$val2 переменным значение? А как же их тогда объявлять при наличии use struct в модуле?
-
Skif
в модуле:
package MyModule;
...
sub my_func {
my ($var1, $var2) = @_;
...
return ($var1, $var2)
}
в скрипте:
($var1, $var2) = MyModule->my_func($var1, $var2);
Что-то типа того...
Только вот не помню, может в процедуру первая переменная передается имя модуля... навскидку не скажу
-
Спасибо, что хоть так подпихнули, сейчас покопаю дальше, бо стал и не знаю что делать. В скриптах половина функций повторяется. Вот и решил переходить на модули. ;)
-
Phoinix
------------------------------------------------------
package MyModule;
...
sub new
{
my $self={};
bless($self);
return $self;
}
sub my_func {
my $self = shift;
my %HKeys = @_;
my $var1= $HKeys{\'var1\'};
my $var2= $HKeys{\'var2\'};
...
return ($var1, $var2)
}
в скрипте:
use MyModule;
my $MD=MyModule->new();
($var1, $var2) = $MD->my_func(var1=>$var1, var2=>$var2);
или:
use MyModule;
($var1, $var2) = MyModule->my_func(var1=>$var1, var2=>$var2);
-
Тут вот споткнулся на таком, практически не получается достучаться до моего модуля, тобишь все описано, но вот когда пускаю скрипт, где вызывается мой модуль пишет:
skif@server /usr/local/script/testsquid/:./test.pl
Can\'t locate object method "readconfig" via package "module_perl" (perhaps you forgot to load "module_perl"?) at ./test.pl line 5.
skif@server /usr/local/script/testsquid/:
Я его ложил как рядом со своим скриптом, так и к остальным модулям perl-а в системе. У меня они лежат
/usr/local/lib/perl5/5.6.1/
Может нужно как-то "объяснить" перлу, что установлен новый модуль, что бы он включил его в свои переменные окружения?
-
Упс, вопрос снимается. час бился там, где, оказывается проблема выеденного яйца не стоит. - фишка в том, чтьо модуль в коде обозвал по одному, а сам файл по другому.
-
Skif
на будушее используй:
use lib \'.\';
-
Вот в догонку еще вопрос, тоже сейчас мучаюсь. У меня ряд функций ушло в модуль без проблем, они в основном отдают параметры, но мне нужно в модуль передать переменную, как это реализовать.
кострукция вида С\\Delphi не работает :( :
sub some_sub($val1,$val2) {
$val3 = $val1+$val3;
return $val3;
}
Куча ругани и т.д:
skif@server /usr/local/script/testsquid/:./test.pl
Possible attempt to separate words with commas at squiddb.pm line 5.
Global symbol "$val1" requires explicit package name at squiddb.pm line 67.
Global symbol "$val2" requires explicit package name at squiddb.pm line 67.
Compilation failed in require at ./test.pl line 3.
BEGIN failed--compilation aborted at ./test.pl line 3.
-
Тоже снимаю, все проще чем мир
sub mysub (???) {
shift @_; #Вернет имя модуля
my ($result,$val1,$val2);
$val1=shift @_;
$val2=shift @_;
result = $val + $val2;
return $result;
}
-
Я так понял, ООП не используется, тогда какой смысла работать с классами (это именно классы, а не модули), если достаточно обычных пакетов и экспортера?
Кстати, касательно приема параметров. Если знать, что "магический" массив @_ содержит список переданных в функцию / метод параметров, то можно записать все так:
my ($val1, $val2) = @_;
Или, если нужно отбросить инвокант:
my (undef, $val1,$val2) = @_;
-
К сожалениюв той доке, по которой я работаю, а именно "Programming Perl" от o\'Reilly, описана работа с модулями именно так. Для OOП для меня слишком путано и несколько не понятно на данном этапе, посему я отталкивался от основного метода, не ООП, что в итоге вышло, не знаю, но скрипты работают.
Кстати, можете пояснить значение invocant, я никак его понять не могу?
-
commander в своем сообщении привел пример простого класса, состоящего из конструктора и метода. Я бы не советовал использовать ООП там, где в этом нет необходимости. Кроме того, если ты не знаком с ООП его применение в перле без базового изучения может даже навредить.
В кэмэлбуке есть две главы (10 и 11), которые посвящены пакетам и модулям. Этой информации, а так же соответствующей страницы руководства и документации по модулю Exporter вполне достаточно, чтоб получить основную информацию по данному вопросу. Если планируешь тесно работать с перлом, обязательно обзаведись кукбуком. В книге содержится множество ответов на часто задаваемые вопросы, в том числе касательно пакетов и модулей.
Ну и пример простого модуля:
package MyModule;
use strict;
use base Exporter;
# для ранних версий перла
# use Exporter;
# our @ISA = qw(Exporter);
our @EXPORT = qw(foo);
foo
{
my $name = shift;
print "Hi, my name is $name\\n";
}
1;
Пример использования в скрипте. Функция foo автоматически импортируется и ее можно вызывать так, как будто бы она была объявлена в самом скрипте.
use MyModule;
use strict;
foo("2nf");
-
2NetFly
Я бы не советовал использовать ООП там, где в этом нет необходимости. Кроме того, если ты не знаком с ООП его применение в перле без базового изучения может даже навредить.
Что за манера пугать людей ООП?!?! Это не БАБАЙ, которым пугают детей! В Перле ООП вообще элементарная вещь! И ничего страшного от его применения не будет!
-
Если человек не знаком с ООП и начнет его изучения с перла, он может быть немного удивлен, когда встретится с "правильным" ООП в C++ или Java.
Автору темы нужны модули, а не классы, и не стоит его путать. Какой смысл в ООП, если не используется ни одна их трех его основополагающих парадигм? Как говорил Фаулер, нет ничего ужаснее ООП программы в процедурном стиле ;=)
-
с "правильным" ООП в C++ или Java.
ага...? Ну поведай нам тогда чем же правильное ООП (в C++ или Java) отличаеться от "не правильного" (реализованного на PERL)?
-
commander
Ты не прав, ООП в Перл, до версии 6, эмулируемый, о 6 не знаю.
Вот абзац из http://www.manning.com/conway (http://www.manning.com/conway)
What object-oriented Perl isn’t
Perl was not originally designed—or implemented—as an object-oriented language. Its version of
object orientation is simple and well integrated, but not fundamental to the language.1
------------------------------------
1 …as it is in Java, or Eiffel, or Python, for example.
------------------------------------
That evolutionary development shows in the few places where object-oriented features of the
language are still experimental or incomplete. For example, recent versions of the Perl compiler
support weakly typed variables, which provide compile-time checking and optimization for accesses
to the data stored in Perl objects. But the current version of the mechanism doesn’t actually
enforce type safety or proper data encapsulation, nor does it fully support inheritance.
Because Perl wasn’t originally designed as an object-oriented language, object-oriented Perl
isn’t fast. Calling a method through an object is significantly slower than calling a regular Perl subroutine.
Just how much slower is a matter of some debate, and depends on whether you measure
entire software systems or just raw single-call invocation speed.
A single method call is about 30 percent slower than a regular call to the same subroutine
(depending on your hardware, your operating system, the phase of the moon, etc.) But though
they’re individually much slower, method calls are more powerful than regular subroutine calls,
due to a feature known as polymorphism (see chapters 1 and 7). In a larger system, that redresses
the speed imbalance in a little, but, in general, it’s fair to say that an object-oriented implementation
of a system in Perl will almost never be faster than the equivalent non-object-oriented implementation,
and will usually be somewhere between 20 to 50 percent slower.
Those figures are enough to turn many people away from object-oriented Perl, and that’s a
pity because then they miss out on the many compensating benefits of object-oriented design and
implementation: simpler analysis methods, a domain-oriented approach to design, cleaner and
more compact code, more robust implementations, greater code modularity, easier debugging,
more comprehensible interfaces to modules (including operator-based interfaces), better abstraction
of software components, less namespace pollution, greater code reusability, scalability of software,
and better marketability of the final product.2
The sad thing is that people get spooked by the numbers (20 to 50 percent slower!!!) and forget
what that really means (…just as fast in six months time, when processor speeds have doubled).
-
Влад, сэмулированая ОО модель в Перл, имеет три св-ва которые позволяют назвать язык Объектно-Ориентированным это:
- Наследование. присутсвует
(это процесс порождения одного класса из другого класса. В результате этого процесса дочерний класс может использовать методы родительского класса).
- Полиформизм. присутсвует
(это атрибут, позволяющий с помощью одного интерфейса управлять доступом к целому классу методов).
- Инкапсуляция. присутсвует
(это механизм, связывающий воедино код и данные которыми но манипулирует).
эмулированы эти св-ва или нет - это НЕ ВАЖНО! Perl - объектно - ориентированый язык!!!
И когда я читаю подобное:
Если человек не знаком с ООП и начнет его изучения с перла, он может быть немного удивлен, когда встретится с "правильным" ООП в C++ или Java.
меня это искренне удивляет!
-
Перл (в отличие от Ruby, например) изначально не был объектно-ориентированным языком, и поддержка ООП была втиснута в уже сформированный процедурный язык.
Ну поведай нам тогда чем же правильное ООП (в C++ или Java) отличаеться от "не правильного" (реализованного на PERL)?
Лучше меня это поведает Ларри Уолл. В его интервью и статьях о шестой версии перла можно узнать, чем же плох ООП в пятой версии и каким образом он будет приводиться к более правильному виду.
Времена, когда самой используемой фишкой ООП было наследование, а под инкапсуляцией понималось сокрытие данных уже давно прошли. Миром правят Гамма, Фаулер, Бек, Шаллоуей и прочие отцы современного ООП.
-
.
-
[moderator]
commander предупреждение.
Выбирай выражения при общении.
Предупреждаю: тред будет усиленно модерироваться.
-
NeoNox
ok...
запостил с утра, ещё не совсем проснувшись...
2NetFly
Времена, когда самой используемой фишкой ООП было наследование, а под инкапсуляцией понималось сокрытие данных уже давно прошли. Миром правят Гамма, Фаулер, Бек, Шаллоуей и прочие отцы современного ООП.
это всего лишь слова.
более весомые аргументы будут?
-
Перл (в отличие от Ruby, например) изначально не был объектно-ориентированным языком, и поддержка ООП была втиснута в уже сформированный процедурный язык.
Тоже могу сказать и про Си и про паскаль и про... Продолжать?
Насчет ООП (без меня меня женили), не удобно говорить конечно, но все это неплохо работает в моих программах на Delphi/С++ и как то проблем с этим(классы, наследование и т.д.) не встречал. Единственное, что меня смущает - я не понимаю текст "Programming PERL" в главах где объясняется как все это реализуется в perl - ну не слишком хорошо я знаю английский.
А вообще сейчас пошел чистый флейм.
Просто я модуль расцениваю как типичную библиотеку из Си/паскаль, вот и подход у меня к ней соответственный. Может не прав, но это уже другая песня.
-
Не было возможности ответить раньше.
Тоже могу сказать и про Си и про паскаль и про... Продолжать?
Что-то я связи не вижу. C++ - это отдельный язык, Visual Basic - отдельный язык и Object Pascal - тоже отдельный язык и связи между этими языками и их "синтаксическими родителями" практически нет. На базе (не совсем подходящее слово, но лучшего я подобрать не смог) процедурных языков были построены совершенно новые (!) ОО языки со схожим синтаксисом, но совершенно иной концепцией. С перлом же история другая - в процедурный язык была втиснута поддержка ОО модели, причем довольно безобразно (по крайней мере с точки зрения синтаксиса - чего только стоит наследование до версии 5.6).
Насчет знания / незнания ООП. Речь шла о том, что начинать изучение ООП с перла - не есть хорошо, а ни в коме случае не о твоих познаниях в ООП.
это всего лишь слова.
более весомые аргументы будут?
Все аргументы в трудах перечисленных авторов. Вряд ли я смогу выступить эффектнее оных =)