myke спрашивает в почте

Александр Петросян (PAF) 15.05.2002 11:48

День добрый,

вот коллекция вопросов, замечаний, предложений на сегодня.
Кое-что было в форуме, кое-что еще нет, оставлено для письма.
На некоторые уже есть ответы, но их стоит оставить -- для пролносты картины,
и еще потому, что сами проблемы все равно не решены.
Это jFYI, не критика, пожелания по улучшению хорошей вещи, которой я пользуюсь.

$myke parser3 bad.txt 20020500 20020514 0203

* Непонятки в Парсере3

*** Таблицы

1. Про ^table.append:
"Пример использования:
$stuff[^table::create{name pos
Alexander boss
Sergey coder
}]
^stuff.append{Nikolay designer}
^stuff.save[stuff.txt]
Пример добавит в таблицу stuff новую запись и сохранит таблицу на диске.
При этом внутри кода примера получить значение третьего столбца добавленной
записи нельзя, однако, его можно увидеть в файле stuff.txt."
Строки, наверное?
И почему нельзя?

2. См. Хеши.1.

3. Таблицы -- штука полезная.
Но почему не сделать их более полнофункциональными?
Допускается чтение элементов таблиц, но нет записи,
напр., есть
"Получение содержимого столбца
$таблица.поле
Возвращает содержимое столбца поле из текущей строки таблицы.
Пример использования:
$tab.name
Пример вернет значение, определенное в колонке name текущей строки таблицы. "
но нет
$таблица.поле[новое_значение]
а это было бы очень полезным.

4. См. Хеши.1.

5. Метод line не описан в документации, хотя и используется там,
например, в описании метода fields класса table.

*** Хеши

1. Есть преобразование таблицы к хешу, но нет построения таблицы из хеша.
А помогло бы. Поскольку таблицы фактически являются константами, а с хешами
все же можно работать на запись.
Порядок формирования нвоой таблицы можно делать произвольным, поскольку
в общем случае порядок элементов в хеше не определен.
(Хотя, по аналогии с Tie::IxHash Perl'а можно иметь и хеш в порядке вставки
элементов, либо сделать метод с сортировкой по опред. полю при формировании
таблицы).

*** Даты

1. Даты в таблице
$now[^date::now[]]
$online[^table::load[$root/data/online.tab]]
^online.append{$uid $who $now}
дает:
"contains illegal assignment attempt of date to MAIN code_frame, use constructor
now
c:/apache/htdocs/mis/spec/check.html(24)
exception.type=parser.runtime "
Нельзя работать с датами в таблице?
Сказано:
"Числовое значение объекта класса date равно числу суток с 01.01.1970 до
даты, заданной в объекте.",
и приводятся примеры с арифм. сложением/ вычитанием и сравнением.
Но -- неужели это не положить в таблицу?
Впрочем, такое
$enow[^eval($now)]
^online.append{$uid $who $enow}
работает и пишет вещественное число.
"11817.9"... -- почему-то одно и то же...

2. Вообще, однонаправленность преобразований удивляет,
напр., есть
" ^date.sql-string[]
Метод преобразует дату к виду ГГГГ-ММ-ДД ЧЧ:ММ:СС, который принят для
хранения дат в СУБД. Использование данного метода позволяет вносить в базы
данных значения дат без дополнительных преобразований. "
Однако обратного метода нет (преобразование к формату даты), и очень жаль.

*** Синтакис

1. Имена переменных. Минус (тире) в них -- явно лишняя возможность.
Достаточно было бы иметь подчерк. А так лишние сложности и конфликты.
(Зачем делали -- понятно, для простого включения запросов типа
$Content-type, но стоит ли оно того?)

2. Форматные строки -- очень ограниченны. Хотелось бы и %s, и т.п.
Все равно обработка идет через C++, так и поставить sprintf("...", )...

3. Чувствительность к пробелам при вводе операторов
^if(){}{} -- работает
^if (){}{} -- НЕ работает
Возможно, оптимальным решением было бы игнорировать whitespaces между соотв.
скобками.

4. Пустые строки внутри сложных конструкций могут сделать их неработающими.

5. @USE -- конструкция из другого мира. Ничего аналогичного нет нигде больше
в парсере, ее синтаксис описан вскользь, в сравнеии с ^use[]...
Синтаксис отличается от иснтаксиса остальных операторов.
Какие еще есть похожие вещи? Каковы в общем случае возможности @USE?

6. Важнейшая возможность любого форматирования в общем случае -- полное
отключение такового редактирования. (доп.) Можно предложить такое: при
появлении команды ^noparser[] обработка текущего файла прекращается,
остаток выдается как есть.

7. (доп.) А по команде ^end[] (или __END__) прекращается обработка (ввод)
текущего файла (как в Perl).

8. Возможно, работа с классами в парсере -- вещь совершенно излишняя.
Тем более, что сделана она с существенными ограничениями по сравнению с классикой.
Однако объектный синтаксис в вызове функций вполне оправдан (через точку).
Ограничение языка сложной макрообработкой было бы вполне уместно,
иерархическое наследование макросов вполне решило бы большинство (или все)
желаемые цели.

9. Скобки. Их расположение имеет решающее значение, а понять, что же не так,
из документации невозможно, напр., вот это -- не работает:
===
Результат работы:<br>
^try{
Hello!
^throw[bad.command;$command;Wrong command $command, good are add&delete]}
{
Увы, ответ отрицательный. Совсем...
$exception.comment
$exception.handled(1)
}
===
а это -- работает:
===
Результат работы:<br>
^try{
Hello!
^throw[bad.command;$command;Wrong command $command, good are add&delete]
}{
Увы, ответ отрицательный. Совсем...
$exception.comment
$exception.handled(1)
}
===
Ошибки такого рода ловить крайне сложно, с точки зрения доки это одно и то же.
Получается, что здесь очень сложный несвободный формат записи.

10. Очень запутанно со скобками () [] {} и с обращениями . : ::
Например, почему просто переменная -- это $var, а применение к ней метода
дает ^var.method? Странно получается и в конструкциях типа
^var.item.method[], где item -- поле переменной (напр., элемент таблицы),
а method -- применяемая функция.
На с.д. лучше (м.б.) было бы иметь только "птичку" ^, а то, что вызывается,
определялось бы типом того, к чему идет обращение:
^var
^var.item
^var.method[]
^var.item.method[]
и пр.
Заодно можно убрать различие между переменными, объектами, макросами и пр. --
все это вполне укладывается в одно понятие на уровне макропроцессора.

11. Точка после переменной или вызова может дать плохой эффект,
даже если после них никаких конструкций не идет.
Напр.,
===
Найдено ответов: $n.
===
будет обругано, и пользователь (разработчик, который, как утверждается,
м.б. даже и не программистом) будет долго гадать, в чем дело. IMHO тут надо
иметь квалификацию разработчика трансляторов, чтобы понять, что точка в
конце предложения воспринята как обращение к несуществующему элементу (или методу)
оъекта $n.
А вот
===
Найдено ответов: $n .
===
сработает, но даст некрасивый отступ, при котором точка может быть и перенесена.
Правильное решение
===
Найдено ответов: ${n}.
===
но оно приходит с опытом (т.е. с набитыми шишками и потерянным временем);
это всегда так, но на таких-то конструкциях можно бы и сэкономить :)

12. Включение файлов.
Нужна команда -- "включить файл с обработкой". Пока что сильно косвенно...

*** Формы, вызовы, интерактивные функции

1. Работа с формами. Все рассчитано на то, что форма одна.
А в реальных документах их может быть несколько, с разными именами и
разными обработчиками.
<form name=form1... >... </form>
Как с этим работать? Будет ли поддержка такого? В доке нет.

2. УРЛы. Пример из доки:
"Тогда:
$request:uri
вернет:
/news/index.html?year=2000&month=05&day=27 ".
Как правило, нас интересует именно адрес страницы, к которой в данный момент
производится обращение, а не строка со всеми параметрами (к тому же не
разобранными).
Лучше бы сия функция выдавала строку ДО "?".
Те паче, что разбор строки на составляющие в парсере не вполне удобен, и
достигается некоторыми неочевидными манипуляциями (это явно стоит сделать
более простым, поскольку очень часто встречается в реальной работе).
Возможно, стоит иметь несколько функций, причем прежнюю НЕ переименовывать,
ибо поломаются уже работающие страницы,
одну -- для выдачи только адреса,
другую -- для выдачи полной строки запроса,
третью -- для строки краткой строки запроса,
четвертую -- для получения только параметров
(поименно параметры получаются через (пока что единственную и анонимную) форму
$form:имя).

*** Организация и установка

1. Установка, особенно для новичков, весьма сложна.
На порядок сложнее, чем для парсера-2.
Нужна более четкая инструкция, с готовыми файламии примерами для разных
серверов под разные платформы.

2. Полезно было бы иметь библиотеку стандартных процедур.
Типа coounter, color...

3. Очень плохо в новой версии урезать возможности программы.
Можно изменить синтаксис и сообщить, как в новом реализовать старые
возможности.
Например, вынести их в стандартные библиотеки.
Примеры: ^counter, ^color.

4. Результаты обсуждения и отсылки багрепортов иногда вызывают сообщения типа
"исправили уже после выкладывания бинарника". Собрать из исходников --
задача не для каждого юзера.
Планируется ли периодическое выкладывание новых версий бинарников на сайт,
прежде всего -- под винды, где эта сборка особенно нетипична и нетривиальна?
М.б. иметь версии типа юниксных ("Новость. Вышла новая нестабильная версия
парсера-3 parser-3.5.27. Новичков просим не беспокоиться, а экспертов --
присылать багрепорты на адрес..."). Тем паче, что разработка идет на CVS,
и подобные вещи д.б. тривиальны.

5. Установка парсера на расширение .html представляется не очень правильной методически.
М.б. сразу ориентироваться на .p2 для parser2, .p3 для parser3, и т.п.
(особенно с учетом того, что
а) команды парсера, случайно встретившиеся в постороннем файле, могут привести к
неработоспособности других страниц на сервере,
б) синтаксис даже разных версий парсера полностью несовместим,
а режима совместимости (как, например, в LaTeX'е) здесь нет (и не будет?).
Сложность с обращением к index.HTML по умолчанию легко обходится.
Желающие могут ставить и на обработку .html, но уже добровольно.
(У меня действильно ыли небольшие сложности, когда перестали работать
старые стрнаицы из-за _похожих_ на парсерные констукции в них.)

6. Сложности ввода и вывода в форуме.
То, что вводится, существенно отличается от того, что выводится (показывается на
странице форума).
Например, плывет все форматирование.
При сохранении по cut&paste все тексты -- поабзацно в одну строку.
Увы, потом это трудно читать (особенно с учетом пункта Синтаксис.9).

*** 90. Обратная связь. Сайт и форум

90.1. Полезно наличие раздела на сайте, где можно было бы выкладывать полезные решения,
найденные разработчиками и авторами программы.
например, библиотеки макросов.

90.2. История сообщений крайне мала. Найти нужное сообщение обчень трудно.
Стоит иметь полноценный поиск и выдачу любых прошедших сообщений.

90.3. Хорошо бы иметь несколько подфорумов. Т.е. в одном месте обсуждаются
организационные проблемы, в другом синтаксические, а в третьем -- пожелания на будущее
и альфа- и бета-тестирование.

90.4. М.б. sns-serifs (verdana, tahoma) смотрелись бы луше на сайте?

*** 99. Опечатки в доке

99.1. В документации про math:random:
^math:random(верхняя_граница)
Метод возвращает псевдослучайное число, попадающее в интервал от 0 до
заданного числа, не включая само число.
Пример использования:
$math:random(1000)
Получим псевдослучайное число из диапазона от 0 до 999.
Так ^math:random или $math:random?
Д.б. ^math:random.

99.2. try. Перехват и обработка ошибок
"xml
^xdoc::create{<forgot?>}
ошибочных XML код или операция"
надо: "ошибочный"

99.3. try.
"Если ошибка так и не будет обработана, если есть, вызывается метод
unhandled_exception и ему передается информация об ошибке, стек вызовов,
приведших к ошибке, и выдаются результаты его работы. Также ошибка
записывается в журнал ошибок веб-сервера. А также производится запись в
журнал ошибок веб-сервера."
Последние 2 фразы -- одно и то же.

\bye
myke

---