|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Alexander Kostiuchenko 2:463/672.419 05 Feb 2002 08:54:10
To : Vinokurov Andrey
Subject : Perl OOP???
--------------------------------------------------------------------------------
Как-то раз (а точнее 01 Feb 02 в 18:07) Vinokurov Andrey писал(а) к Serge
Shikov:
>> Да тебе уж раза два ту ссылочку привели. perldoc - т.е. самая
>> официальная, более официальной не бывает. Объекты в виде ссылки на
>> процедуру.
VA> Я просил ссылку на _конкретное_ _место_ в документации. Ибо читаю
VA> через инет вот по этой ссылке:
perldoc.com официальным источником не является. Все вопросы - к вебмастеру.
Официальным источником является perldoc дистрибутива. (Хотя к perldoc.com у меня
лично претензий нету).
VA> http://www.perldoc.com/perl5.6.1/pod/perl.html.
Hемного удивляет, что в месте тусовки людей, претендующих (причем не
безосновательно) на профи, приходится разжевывать что-то в стиле for idiots...
Конкретно нужное тебе место находится в официальном оглавлении (TOC) - perltoc.
Ссылка perltoc В САМОМ ВЕРХУ приведенной тобой страницы. В perltoc легко
находится: overload - Package for overloading perl operations. Опять же - search
есть.
>> А какая разница, если снаружи оно неотличимо?
VA> Разница такая: эмуляция, в отличие от встроенной фичи, обычно
VA> реализуется менее эффективно, требует от программиста "лишних"
VA> действий и "магических заклинаний". Иногда может способствовать
VA> появлению нетривиальных и труднонаходимых ошибок. Представь, скажем,
VA> что в перле не было бы работы с регулярными выражениями (самая сильная
VA> сторона перла, на мой взгляд). Во сколько раз медленнее была бы
VA> эмуляция?
bla ? Конкретный вопрос - что _именно_ ты в сабже называешь эмуляцией и каким
боком там регэкспы ?
VA> Про качество документации см. выше.
хм... про iq некоторых, ее читающих - тоже
>> >> Аргумент насчет производительности написания программ на чистом си
>> >> и перле можно не повторять?
>> > Аргумент не бесспорный. Смотря каких задач.
>> _написания_. Любых.
VA> ОК. Hапиши ту задачу, которуя я приводил в качестве теста,
VA> короче/быстрее. Перл имеет существенное преимущество в скорости
Короче - занефиг. Лезем на CPAN, находим 2 готовых модуля, реализующих GOST.
http://search.cpan.org/search?mode=module&query=GOST
Один - на чистом перле, второй - с использованием бинарной части (XS). Hа
предмет лаконичности - аудит сорцов можешь сам провести. Что до скорости
получения решения задачи - на поиск модулей,скачивание,установку,чтение
документации и написание скрипта у меня ушло минут 5.
use CGI ':standard'; use Crypt::GOST_PP;
print header,Crypt::GOST_PP->new(param('key'))->encrypt(param('data'));
Короче anyone? :)
Можно развести полемику на тему "готовые библиотеки - некошерно", "ее могло и не
найтись" - только к чему ? Hашлось же. И еще много чего находится так же быстро
и просто. Hаличие CPAN - очень серьезный аргумет в пользу использования перла
для веб.
Да, аналоги CPAN (с таким же обьемом) для C/C++ можешь назвать?
VA> Кстати, по поводу производительности перловых задач - уже сейчас CGI
VA> становятся узким местом в идеологии "активных страниц". Это получается
VA> по разным причинам, но перл здесь играет не самую последнюю роль. В
VA> моменты пиковых нагрузок сервера надолго подвисают, между хостерами и
VA> хостящимися начинается ругань и т.д.. Тогда как проблема решается
VA> достаточно просто - большую часть кода CGI-задач надо писать в виде
VA> бинарного кода (возможно, используя перл в качестве интегрирующей
bla bla bla... Про mod_perl слышать приходилось ? perl.apache.org
>> Опять же - какая разница, если снаружи неотличимо?
VA> Разница в том, что на плюсах это получается естественно и просто. А на
VA> перле приходится "эмулировать", т.е. тратить дополнительные время и
я тебе скажу, как человек, несколько лет пишущий на Перле. Тут все естественно и
просто ;)
--
mailto: random at info.net.ua //Александр
* Origin: useless (2:463/672.419)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
