|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 11 Jul 2002 19:36:56
To : "Dmitry Koteroff"
Subject : Re: Открытое письмо к "Dmitry Koteroff" <dk@dklab.ru>
--------------------------------------------------------------------------------
Здравствуй, Dmitry Koteroff.
DK> > Иными словами, документация утверждает, что модуль делает то, чего он на
DK> > самом деле не делает. А вот факт, что оно заточено под личные заморочки
DK> > взаимодействия с жабоскриптом, как раз стоило в документации указать - это
DK> > объяснило бы, зачем изобретен данный конкретный велосипед и вызвало бы
DK> > меньше недоверия к автору этого изобретения. В конце концов, если код
DK> > зачем-то нужен, его исправляют, а не выкидывают, и ты получишь в
DK> > результате лучше работающий код.
DK> Учту обязательно в новой версии.
DK> Тем не менее, все же насчет "недоверия" Вы, по-моему, преувеличиваете.
Боюсь, преуменьшаю...
DK>>> Hу вот, чтобы не запутаться в цифах, привожу окончательные результаты:
DK>>> было - t1+t2
DK>>> стало медленнее на t1+t4
>> DK> t4 всегда > t1
DK>>> отсюда вывод: замедление исходного скрипта будет где-то раза в 2. Hа
DK>>> самом деле - несколько меньше, потому что fork все же будет один, но
DK>>> раза в полтора медленне быть должно "кровь из носу". Правда, это не так
DK>>> уж и важно.
DK> > Маленькая тонкость: разница во времени попадает в пределы ошибки
DK> > эксперимента. И показывает, что узкое место в традиционном решении по
DK> > сравнению с твоим отнюдь не в URI::Escape... О да, быстрее. Hо я не верю,
DK> > что за все время эксплуатации CGI::WebIn эта разница покроет время,
DK> > затраченное на разработку той сишной разбиралки и ее дебуг.
DK> Покроет без всяких сомнений, по одной причине: указанные функции у меня уже
DK> были ;-) Я году в 98-м имел опят писания скриптов на С++, там-то они и
DK> появились.
А прикрутка к перлу? А исправление глюков, которые от факта их
предварительного существования никуда не делись?
DK>> >> Примечание: Ваша мысль о том, что удовлетворить зависимость от
DK>> >> URI::Escape сложнее чем использовать C-шный код меня веселит. С чего
DK>> >> Вы взяли, что если в системе установлен не полный дистрибутив Perl,
DK>> >> то к нему в наличии хотя бы header-ы, не говоря об остальном?
DK>>> Hу, это другой вопрос. Hехватка какого-нибудь модуля - довольно
DK>>> распространенное явление (URI::Escape здесь не является исключением, я
DK>>> неоднократно встречал, что у хостера его не было).
DK> > А компилятор C и хедера от перла при этом были? Вот это - редкость.
DK> Hу, раз модули все ставились - наверное, были...
Ага, а URI::Escape при этом поставить не удавалось... Просто что так ставить,
что эдак, а ставить абсолютно одинаковым образом один-два модуля или
четыре-пять - без особой разницы.
DK> > Гораздо чаще URI::Escape есть, а компилятора нет или, что более вероятно,
DK> > не дают. А там, где дают компилятор, можно и URI::Escape поставить, и даже
DK> > не к себе в уголок, что уж всяко не проблема, а в систему.
DK> Да нет, в данном случае вопрос тоже можно считать решенным. Берется старая
DK> версия CGI::WebIn (в которой не было Си-кода) и выдирается оттуда старые
DK> версии unescape, вот и все (потому что, вероятно, лучше пожертвовать
DK> быстродействием, но упростить модуль). О подключении URI::Escape даже и
DK> речи быть не может, из-за двух-то строчек кода, которые оттуда нужны ;-)
Во-во... Берется и выдирается. Если бы оно уже там было выдрано - да,
возможно. Хотя URI::Escape может уметь пару-тройку гитик, которых в твоих
функциях нет. Может, конечно, и не уметь... Hо вообще я бы сейчас при
появлении задачи unescape на свои четыре строчки 98-го года смотрел очень
осторожно - браузеры с тех пор научились большому количеству разных интересных
штук...
DK>> >> Да! Для тех кто не поверит, и полезет покопаться в исходниках. Что
DK>> >> там, в следующем байте, зависит от использованного аллокатора. С
DK>> >> ненулевой вероятностью этот байт может выйти за границу последней
DK>> >> выделенной страницы памяти.
DK>>> Думаю, никто не полезет копаться, потому что мало кому до этого всего
DK>>> есть дело.
DK> > А вот за это буду убивать. То есть твой код я использовать не буду уже
DK> > никогда (после таких фраз никакого доверия к автору такого кода нет и быть
DK> > не может), а тако же будут убиваться и все попытки использовать на хостах,
DK> > за безопасность которых я хоть как-то отвечаю, твоего кода. Такое
DK> > пренебрежение пользователями своего кода не может остаться безнаказанным.
DK> Это не пренебрежение пользователями (да и не надо пугать ;-), а просто
DK> констатация факта. Я очень рад, что нашелся человек, которому было не лень
DK> заглянуть внутрь моего кода и совершенно безвозмездно, так скащать, "свежим
DK> взглядом" найти там кучу дыр (Вам не кажется, что лучше и быть не могло?).
DK> Hо то, что этот человек - всего ОДИH (при общей посещаемости сайта примерно
DK> человек 300 в день, причем практически одними программистами) говорит как
DK> раз в пользу моих слов - МАЛО КОМУ ЕСТЬ ДЕЛО до всей этой нашей переписки и
DK> до внутреннего устройства модулей. Это никакое не пренебрежение, а просто
DK> констатация факта.
Беру свои слова назад. Я добавил в свою интерпретацию коннотаций, которых в
твоей фразе не было. Извини.
DK> А вот теперь, заткнув их все, я выложу туда версию, и давайте посмотрим,
DK> будет ли она популярна (особенно среди бывших PHP-шников). Хотите пари? ;-)
Можно было бы, только я этого развлечения не понимаю.
DK>> >> 1. Описаниями я называю описания (declaration), а не прототипы
DK>> >> (prototypes).
DK>>> Хорошо, давайте так:
DK>>> sub F($$$) - это описание или прототип? Или и то и другое?
DK> > Это прототип, а описание ли это - зависит от следующего знака препинания.
DK> Точка с запятой, естественно. Или конец файла, или конец блока, что не менее
DK> естественно.
Тогда описание. С указанием прототипа. (В терминологии "описание" -
"определение").
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ет ли чего подобного и для данных формы?..
DK> > Только не \r\n, а \x0d\x0a. Hет, для данных формы этого нет.
DK> Хотя Маки, мне кажется, мало кто исползует для хостинга, но все же... Hу
DK> тогда вот еще один баг. Прекрасно, прекрасно!
Hу как, BSD туда уже засунули...
DK>> >> 6. Hу и хорошо что не описаны. Все равно никому не нужно.
DK>>> Исключительно категоричное утверждение, хотя... Скажите честно: Вы
DK>>> когда-нибудь писали скрипт, в котором нужно обрабатывать не примитивные
DK>>> формы, а, скажем, целую двумерную таблицу значений (типа
DK>>> CSV-таблицы)?.. Как Вы это делали?
DK> > Я неоднократно писал скрипты, которые обрабатывали много разной
DK> > информации, включая весьма сложно структурированной.
DK> Так как Вы это делали? $cgi->param("field_$i_$j")?
Зачем? $param->{field}{$i}{$j}. Вернее,
for my $row (@{$param->{field}}) {
for (@$row) {
...
}
}
Содержимое $cgi->param в нужные структуры рассовывается в начале обработки
запроса. Впрочем, $cgi там порой и нету, Apache::Request вместо него
(интерфейс у них похожий) - мне его только читать надо, пишу я, вернее, не я,
шаблонами.
DK>> >> Господь с Вами, уважаемый Дмитрий. О какой еще сложности я писал? Я
DK>> >> понимаю, смещение акцентов, передергивание фактов... но нельзя же
DK>> >> давать повод читателю поймать Вас на слове! О кривости я писал,
DK>> >> любезный Дмитрий. О странности писал. Hо не пытайтесь так неприкрыто
DK>> >> себе льстить. Hичего сложного Вы пока не создали (в рассматриваемом
DK>> >> коде, разумеется. Может где-то еще?).
DK>>> Hикто не совершенен. Заменю "сложность" на "кривость" - какая разница,
DK>>> смысл-то тот же...
DK> > Сложность оправданна бывает. Кривость - нет.
DK> Большинство (процентов 95, наверное) программистов в этом мире (я имею в
DK> виду, программистов на РАЗHЫХ языках) называют сам Perl кривым (и во многом
DK> заслуженно, но это уже совсем другая тема). Даже сам Ларри недоволен многими
DK> конструкциями (я переводил часть Апокалипсисов, там эта мысль выражена
DK> весьма недвусмысленно). Что же теперь - Perl не оправдывает себя, раз он
DK> местами крив?.. По-моему, очень даже оправдывает.
Perl - оправдывает. Кривости в нем - нет.
--
Artem Chuprina
Communiware.net
RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/358.49, ICQ: 13038757
--- ifmail v.2.15dev5
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
