VW>> Ну, во первых на C Apache конфмгурить можно. На чем по-вашему написан
Ну-ка ну-ка, как это я на C могу конфигурить Апач? Именно не модуль
писать, а сам файл конфигурации?
VW>> код разбора существующего конфигурационного файла? mod_charset здесь ни
VW>> при чем. Он решает свою отдельную задачу, жрет ресурсов не более, чем для
VW>> этой задачи потребно, и, кстати, неплохо конфигурится.
А разве есть еще задачи кроме конфигуренья Апача? По Вашей предыдущей речи
этого заметно не было. :)
VW>> Вот у себя в communiware мы проводим четкое разграничение между
VW>> программистами, дизайнерами и авторами контента. php эти вещи
VW>> смешивает. Что ни к чему, кроме дыр в секьюрити привести не может. Нет,
PHP ничего не смешивает. Смешивает (или не смешивает - по желанию) сам
программер. Именно по желанию, в соответствии с поставленой задачей -
сваять формочку для приема мейлов или же многоуровневую систему онлайновой
публикации.
VW>> Ах, уже больше десятка? Ну тогда стоит посмотреть на этот код еще раз.
http://www.php.net/version4/credits.php
В CVS там собссно человек 50 записано :), но реально работают человек 10,
я думаю, остальные по мелочам.
VW>> В тот раз, когда я на него смотрел, там вроде меньше народу было. Увидел я
VW>> что конструкцию вида ?FOO=bar&FOO=baz оно не обрабатывает и дальше пошел -
VW>> как же мне без груп чекбоксов-то.
Собссно доки читать полезно. Там написано, как группы чекбоксов делают.
Честно, написано.
VW>> А я ему, кстати писал, и объяснял свою точку зрения. Которая заключается в
VW>> том, что основным выигрышным пунктом tcl по сравнению с perl является
VW>> система safe-интерпретаторов, которая была бы незаменимой в
VW>> web-приложениях, будь она туда корректно присобачена.
А также совершенно невероятная тормознутость, проистекающая, видимо, из
того же. Или из другого, но проистекающая в полный рост. А также
совершенная неудобоваримость писания на этом языке, не будучи воспитанным
с ним с младенческого возраста. У него все слишком уж концептуально. Пока
сообразишь, как цикл оформить, позеленеешь.
VW>> Я ненавижу perl. Я зарабатываю деньги посредством писания на нем, и с
VW>> удовольствием писал бы все то же самое на tcl, если бы это было возможно.
А я perl люблю :) А пишу для веба все больше на PHP. Потому как
эффективный инструмент. А вот для администрации, например, или обработки
данных, на Perl пишу. А на TCL совсем не пишу с тех пор, как
университетский курс по нему отбарабанил. Опротивел он мне с тех пор :) Уж
кому что душе ближе. Но к "давить" пока не зову.
VW>> 2. Существенно более стройная система локализации переменных
Вот тут у PHP небольшая проблема - там есть переменные только локальные и
глобальные, типа как в C. Иногда мешает. Но, боюсь, не дорос еще PHP до
другого. Перлу вон сколько времени понадобилось, пока my появился...
VW>> 3. Гибкий синтаксис - в большинстве случаев не нужно писать парсеры
VW>> проблемно ориентированных языков - можно обойтись парсером Tcl и набором
VW>> проблемно-ориентированных процедур. Ну, может еще парочка регекспов,
Дык а соббсно PHP тоже так же построен. Language engine плюс куча функций
плюс layer, который с сервером болтает.
VW>> как в случае парсера HTML.
VW>> 4. safe interpreters.
А можно поподробнее все-таки, без "давить", что это такое-то?
VW>> приложением, либо куча геммороя при переносе его на другой SQL-сервер.
VW>> кстати, php это тоже касается.
См. десяток DB-abstraction layers разного качества. Мне, например, DB_Sql
из PHPLIB вполне хватает. Но есть проект сделать это посерьезней, типа
DBI. Проект начат, но за его продвижением, увы, не следил - времени нет
совсем.
--
frodo@xxxxxxxxxxxx \/ There shall be counsels taken
Stanislav Malyshev /\ Stronger than Morgul-spells
phone +972-3-9316425 /\ JRRT LotR.
http://sharat.co.il/frodo/ whois:!SM8333
=============================================================================
= Apache-Talk@xxxxxxxxxxxxx mailing list =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
= Archive avaliable at http://www.lexa.ru/apache-talk =
"Russian Apache" includes software developed
by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/) See
Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C)
1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.