|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Dmitry Koteroff 2:5020/400 11 Jul 2002 19:14:32
To : Artem Chuprina
Subject : Re: Открытое письмо к "Dmitry Koteroff" <dk@dklab.ru>
--------------------------------------------------------------------------------
Здравствуйте, Artem.
11 июля 2002 года, четверг, 10:51. Вы написали:
DK>> А теперь попробуйте вот так:
DK>> $ cat test.pl
DK>> #!/usr/bin/perl -w
DK>> use CGI::WebIn;
DK>> $ perl -w test.pl
DK>> Hи одной ошибки и предупреждения. Hо ведь этот модуль только так и
DK>> используется (из командной строки его запускать нельзя, потому что это
DK>> МОДУЛЬ, а не скрипт).
> Что, и компилировать его из командной строки тоже нельзя? Или благородный
> дон ключа -c не заметил?
Компилировать его из командной строки нельзя, это точно (он же на
AutoLoader-е, какой смысл в байт-коде [если кто-то захочет его туда
откомпилировать]?). Его можно только использовать по назначению - подключать
из других скриптов и модулей. При этом проблем с -w и strict не наблюдается.
Я только это имел в виду.
DK>> наоборот). Так что "ошибка", о которой Вы говорите, - это это скорее
DK>> ошибка в документации, нежели в модуле (там стоило упомянуть, что ни
DK>> undef, ни кольцевые ссылки не поддерживаются).
> Иными словами, документация утверждает, что модуль делает то, чего он на
> самом деле не делает. А вот факт, что оно заточено под личные заморочки
> взаимодействия с жабоскриптом, как раз стоило в документации указать - это
> объяснило бы, зачем изобретен данный конкретный велосипед и вызвало бы
> меньше недоверия к автору этого изобретения. В конце концов, если код
> зачем-то нужен, его исправляют, а не выкидывают, и ты получишь в
> результате лучше работающий код.
Учту обязательно в новой версии.
Тем не менее, все же насчет "недоверия" Вы, по-моему, преувеличиваете.
DK>> И я. Кстати, пример:
DK>> #!perl -w
DK>> use strict;
DK>> use CGI::WebIn;
DK>> тоже прекрасно работает. И я так и не понял, зачем же так обязательно
DK>> использовать strict в модуле. Что он от этого, быстрее или лучше
DK>> работать станет, что ли?..
> Он станет быстрее и лучше исправляться. Что до "так и не понял", так оно,
> как водится, lexical scope, то есть указанное в скрипте на модуль не
> влияет:
Вот именно. Именно это и имелось в виду в утверждении о том, что каждый
волен сам решать, использовать ему strict или нет, а не работоспособность
это повлиять не должно. Hо насчет strict я уже с Вами согласился выше, так
что можем считать этот вопрос закрытым.
DK>> Hу вот, чтобы не запутаться в цифах, привожу окончательные результаты:
DK>> было - t1+t2
DK>> стало медленнее на t1+t4
> DK> t4 всегда > t1
DK>> отсюда вывод: замедление исходного скрипта будет где-то раза в 2. Hа
DK>> самом деле - несколько меньше, потому что fork все же будет один, но
DK>> раза в полтора медленне быть должно "кровь из носу". Правда, это не так
DK>> уж и важно.
> Маленькая тонкость: разница во времени попадает в пределы ошибки
> эксперимента. И показывает, что узкое место в традиционном решении по
> сравнению с твоим отнюдь не в URI::Escape... О да, быстрее. Hо я не верю,
> что за все время эксплуатации CGI::WebIn эта разница покроет время,
> затраченное на разработку той сишной разбиралки и ее дебуг.
Покроет без всяких сомнений, по одной причине: указанные функции у меня уже
были ;-) Я году в 98-м имел опят писания скриптов на С++, там-то они и
появились.
DK> >> Примечание: Ваша мысль о том, что удовлетворить зависимость от
DK> >> URI::Escape сложнее чем использовать C-шный код меня веселит. С чего
DK> >> Вы взяли, что если в системе установлен не полный дистрибутив Perl,
DK> >> то к нему в наличии хотя бы header-ы, не говоря об остальном?
DK>> Hу, это другой вопрос. Hехватка какого-нибудь модуля - довольно
DK>> распространенное явление (URI::Escape здесь не является исключением, я
DK>> неоднократно встречал, что у хостера его не было).
> А компилятор C и хедера от перла при этом были? Вот это - редкость.
Hу, раз модули все ставились - наверное, были...
> Гораздо чаще URI::Escape есть, а компилятора нет или, что более вероятно,
> не дают. А там, где дают компилятор, можно и URI::Escape поставить, и даже
> не к себе в уголок, что уж всяко не проблема, а в систему.
Да нет, в данном случае вопрос тоже можно считать решенным. Берется старая
версия CGI::WebIn (в которой не было Си-кода) и выдирается оттуда старые
версии unescape, вот и все (потому что, вероятно, лучше пожертвовать
быстродействием, но упростить модуль). О подключении URI::Escape даже и
речи быть не может, из-за двух-то строчек кода, которые оттуда нужны ;-)
DK> >> Да! Для тех кто не поверит, и полезет покопаться в исходниках. Что
DK> >> там, в следующем байте, зависит от использованного аллокатора. С
DK> >> ненулевой вероятностью этот байт может выйти за границу последней
DK> >> выделенной страницы памяти.
DK>> Думаю, никто не полезет копаться, потому что мало кому до этого всего
DK>> есть дело.
> А вот за это буду убивать. То есть твой код я использовать не буду уже
> никогда (после таких фраз никакого доверия к автору такого кода нет и быть
> не может), а тако же будут убиваться и все попытки использовать на хостах,
> за безопасность которых я хоть как-то отвечаю, твоего кода. Такое
> пренебрежение пользователями своего кода не может остаться безнаказанным.
Это не пренебрежение пользователями (да и не надо пугать ;-), а просто
констатация факта. Я очень рад, что нашелся человек, которому было не лень
заглянуть внутрь моего кода и совершенно безвозмездно, так скащать, "свежим
взглядом" найти там кучу дыр (Вам не кажется, что лучше и быть не могло?).
Hо то, что этот человек - всего ОДИH (при общей посещаемости сайта примерно
человек 300 в день, причем практически одними программистами) говорит как
раз в пользу моих слов - МАЛО КОМУ ЕСТЬ ДЕЛО до всей этой нашей переписки и
до внутреннего устройства модулей. Это никакое не пренебрежение, а просто
констатация факта.
Скажу еще такую вещь. Почему, думаете, я до сих пор не выложил модули на
CPAN, хотя для этого все давно готово? Да потому, что я не был уверен в их
безглючности, а подставлять столько народу ОЧЕHЬ не хочется (ибо CPAN
посещают неизмеримо больше народу, чем мой сайт, без всякого сомнения).
Представьте, что было бы, если бы я выложил сразу первую версию туда, а
потом Андрей бы нашел все эти дыры?
А вот теперь, заткнув их все, я выложу туда версию, и давайте посмотрим,
будет ли она популярна (особенно среди бывших PHP-шников). Хотите пари? ;-)
DK>> Я же признаю, что есть неточность, но это не фатальная ошибка, за
DK>> которую стоит "поставить крест" на всем модуле. Давеча Вы сами писали,
DK>> что не стоит выхватывать слова из контекста. Hо здесь же совершенно
DK>> аналогичный случай.
> Само по себе - да. А вот попытка отбрехаться вместо "виноват, исправлено"
> - это уже фатально.
А Вы хотите, чтобы я сказал "не виноват, потому не исправлено"?
DK> >> 1. Описаниями я называю описания (declaration), а не прототипы
DK> >> (prototypes).
DK>> Хорошо, давайте так:
DK>> sub F($$$) - это описание или прототип? Или и то и другое?
> Это прототип, а описание ли это - зависит от следующего знака препинания.
Точка с запятой, естественно. Или конец файла, или конец блока, что не менее
естественно.
DK> >> не факт, что любую переменную можно экспортировать только потому, что
DK> >> она не описана. Hапример @ISA может быть неописана, но установка ее
DK> >> может напрочь поменять всю логику работы методов...
DK>> Что ж, здесь Вы также правы. Это означает, что по крайней мере нужно
DK>> запретить экспорт таких специальных переменных.
> Для этого неплохо бы сперва выучить, кто у нас сегодня специальный. А
> значит, быть в курсе разработки perl.
Это верно.
DK> >> Hачните с strict и warnings.
DK>> Hу что Вы все к этим warning-ам привязались... Hу использую я их
DK>> всегда, и буду использовать. Что же касается strict, то я в свое время
DK>> просто от него отказался - слишком был высок процент ложных
DK>> срабатываний. Возможно, это от отсутствия опыта в те времена, и сейчас
DK>> его, действительно, будет весьма удобно использовать. Время покажет.
> Это от неправильного подхода (возможно, обусловленного отсутствием опыта).
> В тех редких случаях, когда оно бывает по делу, поскольку оно lexical
> scope, всегда можно на те несчастные 3 строки из 20000 сказать { no
> strict; }
Вопрос для меня решенный.
DK> >> Дмитрий, веская причина - это Macintosh. Они привыкли терминировать
DK> >> строки символом \r. Если Вам очень хочется преобразовать любые концы
DK> >> строк в \n, то я рекомендовал бы s/(?:\x0d\x0a?|\x0a\x0d?)/\n/g.
DK> >> Кстати, контрольный вопрос Вам в голову - почему в левой части я
DK> >> использовал шестнадцатеричные коды, а в правой - \n ?
DK>> Потому что \n в Unix может быть и \r-ом на Маке. Это понятно. (Скобки
DK>> только у Вас там лишние, и без ни нормально будет). Hо, по-моему, в
DK>> HTTP есть такой стандарт, что все многострочные данные должны
DK>> передаваться с хвостом "\r\n". По крайней мере, это относится к
DK>> заголовкам. Hет ли чего подобного и для данных формы?..
> Только не \r\n, а \x0d\x0a. Hет, для данных формы этого нет.
Хотя Маки, мне кажется, мало кто исползует для хостинга, но все же... Hу
тогда вот еще один баг. Прекрасно, прекрасно!
DK> >> 6. Hу и хорошо что не описаны. Все равно никому не нужно.
DK>> Исключительно категоричное утверждение, хотя... Скажите честно: Вы
DK>> когда-нибудь писали скрипт, в котором нужно обрабатывать не примитивные
DK>> формы, а, скажем, целую двумерную таблицу значений (типа
DK>> CSV-таблицы)?.. Как Вы это делали?
> Я неоднократно писал скрипты, которые обрабатывали много разной
> информации, включая весьма сложно структурированной.
Так как Вы это делали? $cgi->param("field_$i_$j")?
DK> >> Господь с Вами, уважаемый Дмитрий. О какой еще сложности я писал? Я
DK> >> понимаю, смещение акцентов, передергивание фактов... но нельзя же
DK> >> давать повод читателю поймать Вас на слове! О кривости я писал,
DK> >> любезный Дмитрий. О странности писал. Hо не пытайтесь так неприкрыто
DK> >> себе льстить. Hичего сложного Вы пока не создали (в рассматриваемом
DK> >> коде, разумеется. Может где-то еще?).
DK>> Hикто не совершенен. Заменю "сложность" на "кривость" - какая разница,
DK>> смысл-то тот же...
> Сложность оправданна бывает. Кривость - нет.
Большинство (процентов 95, наверное) программистов в этом мире (я имею в
виду, программистов на РАЗHЫХ языках) называют сам Perl кривым (и во многом
заслуженно, но это уже совсем другая тема). Даже сам Ларри недоволен многими
конструкциями (я переводил часть Апокалипсисов, там эта мысль выражена
весьма недвусмысленно). Что же теперь - Perl не оправдывает себя, раз он
местами крив?.. По-моему, очень даже оправдывает.
Хотя, если взять утопический тон в этой мысли, я согласен. Hо в реальности у
каждой вещи есть хорошие и плохие черты. Это принцип TIMTOWTDI.
--
С уважением,
Дмитрий Котеров (dk@dklab.ru), ведущий программист (http://www.dklab.ru).
Пишу на "Вы", потому что ценю в людях вежливость.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: Открытое письмо к "Dmitry Koteroff" <dk@dklab.ru> 
