PAF отвечает в форуме
Александр Петросян (PAF) 15.05.2002 11:49
> вот коллекция вопросов, замечаний, предложений на сегодня.
ура!
>1. Про ^table.append:
>И почему нельзя?
>3. Таблицы -- штука полезная.
потому, что было решено оставить таблицу возможно более простой,
переложив основную нагрузку на sql сервер = каждый должен заниматься тем,
что умеет больше всего.
уверен, вам бы понравился вариант parser2, в котором по таблицам можно было средствами parser делать запросы, похожим на sql языком. было принято этого всего не делать.
> 5. Метод line не описан в документации, хотя и используется там,
например, в описании метода fields класса table.
>3. Таблицы -- штука полезная.
мм.. описан?
http://parser.ru/docs/lang/tableline.htm [Дата обновления: 24.04.2002]
> 1. Есть преобразование таблицы к хешу, но нет построения таблицы из хеша.
> А помогло бы.
сделать можно, однако не вижу реального примера, где становится что-то удобнее.
menu/foreach — суть одно и то же.
> 1. Даты в таблице
как уже говорил, таблица приспособлена для вывода уже подготовленных sql сервером данных.
и работа с датами идёт в строчном формате.
собственно, таблица умеет хранить только строки.
соответственно, это делает её очень простой, за что и боремся.
диагноз: хранить дату в текстовом формате.
если есть экземпляр даты, он переводится в текстовый формат ^date.sql-string[]]
> $enow[^eval($now)]
> работает и пишет вещественное число.
> "11817.9"... -- почему-то одно и то же...
здесь у eval не задан формат вывода.
по-умолчанию 6 знаков, чего недостаточно, чтобы показать минуты, видно только, что происходит дело в конце дня: 9 десятых дня уже прошло.
> есть ^date.sql-string[]
> Однако обратного метода нет (преобразование к формату даты), и очень жаль.
уже есть[в cvs, головная ветка], бинарники в дороге.
> 1. Имена переменных. Минус (тире) в них -- явно лишняя возможность.
> Достаточно было бы иметь подчерк. А так лишние сложности и конфликты.
> (Зачем делали -- понятно, для простого включения запросов типа
> $Content-type, но стоит ли оно того?)
разумная удобная простая альтернатива?
> 2. Форматные строки -- очень ограниченны. Хотелось бы и %s, и т.п.
> Все равно обработка идет через C++, так и поставить sprintf("...", )...
ну и что будет по printf("%s", 5)? :)
любой сложности форматные строки пишутся самим при помощи match, миша публиковал свой date time format модуль, там хороший пример.
> 3. Чувствительность к пробелам при вводе операторов
> ^if(){}{} -- работает
> ^if (){}{} -- НЕ работает
> Возможно, оптимальным решением было бы игнорировать whitespaces между соотв.
> скобками.
^if(условие){текст} [вася]
здесь "[вася]", это буквы такие, или код else?
неясно = зависит от замысла кодера, а parser не чтец мыслей.
было принято решение быть строже но однозначнее.
> 4. Пустые строки внутри сложных конструкций могут сделать их неработающими.
не очень понял, пример?
>5. @USE -- конструкция из другого мира. Ничего аналогичного нет нигде больше
>в парсере, ее синтаксис описан вскользь, в сравнеии с ^use[]...
>Синтаксис отличается от иснтаксиса остальных операторов.
намеренное уменьшение количества букв на единицу выраженной мысли.
в духе parser2.
>Какие еще есть похожие вещи?
@CLASS
@BASE
>Каковы в общем случае возможности @USE?
см. /docs
>6. Важнейшая возможность любого форматирования в общем случае -- полное
>отключение такового редактирования. (доп.) Можно предложить такое: при
>появлении команды ^noparser[] обработка текущего файла прекращается,
>остаток выдается как есть.
конкретный пример, когда это полезно?
>7. (доп.) А по команде ^end[] (или __END__) прекращается обработка (ввод)
>текущего файла (как в Perl).
конкретный пример, когда это полезно?
> 8. Возможно, работа с классами в парсере -- вещь совершенно излишняя.
не согласен.
> 9. Скобки. Их расположение имеет решающее значение, а понять, что же не так,
> из документации невозможно, напр., вот это -- не работает:
уже описал выше: скобки должны идти впритык.
>Ошибки такого рода ловить крайне сложно, с точки зрения доки это одно и то же.
>Получается, что здесь очень сложный несвободный формат записи.
это вопрос привычки, синтаксические ошибки ловить всяко проще, чем любые остальные.
> 10. Очень запутанно со скобками () [] {} и с обращениями . : ::
в приводимом примере мог бы указать очевидные затыки, но не буду.
я понапридумывал кучи вариантов синтаксиса,
только так получилось читабельно, однозначно и удобно.
>11. Точка после переменной или вызова может дать плохой эффект,
>даже если после них никаких конструкций не идет.
безусловно, это одна из мелочей, обуславливаемая погруженностью языка в текст.
> Найдено ответов: $n.
> Правильное решение
> Найдено ответов: ${n}.
> но оно приходит с опытом (т.е. с набитыми шишками и потерянным временем);
хорошо описано в доке.
> это всегда так, но на таких-то конструкциях можно бы и сэкономить :)
внёс в faq.
> 12. Включение файлов.
> Нужна команда -- "включить файл с обработкой". Пока что сильно косвенно...
см. faq про include.
> 1. Работа с формами. Все рассчитано на то, что форма одна.
почитайте стандарт http. формат submit'ится одна.
> 2. УРЛы. Пример из доки:
> $request:uri
> /news/index.html?year=2000&month=05&day=27 ".
> Лучше бы сия функция выдавала строку ДО "?".
функция соответствует своему имени.
любой разбор можно огранизовать средствами parser.
match, lsplit, rsplit.
> 1. Установка, особенно для новичков, весьма сложна.
если кто-то возьмётся и напишет parser3setup.exe для windows, я буду рад опубликовать ссылку на его в download.
> 2. Полезно было бы иметь библиотеку стандартных процедур.
> Типа coounter, color...
по мере написания публикуйте написанное, делитесь с коллегами.
лучшие куски кода будут собираться и публиковаться отдельно.
> 3. Очень плохо в новой версии урезать возможности программы.
возможности сильно расширены.
> 4. ... Планируется ли периодическое выкладывание новых версий бинарников на сайт,
непременно.
> 5. Установка парсера на расширение .html представляется не очень правильной методически.
> М.б. сразу ориентироваться на .p2 для parser2, .p3 для parser3, и т.п.
на какое хотите расширение, на такое и ассоциируйте, всё в ваших руках.
> 6. Сложности ввода и вывода в форуме.
> 90.2. История сообщений
> 90.3. Хорошо бы иметь несколько подфорумов
90.4. М.б. sns-serifs
напишите письмо misha@design.ru, он подумает, что можно улучшить
> 90.1. Полезно наличие раздела на сайте, где можно было бы выкладывать полезные решения,
> найденные разработчиками и авторами программы.
> например, библиотеки макросов.
"найденными пользователями parser3".
такой раздел будет создан, как только накопится сколько-то полезных примеров форуме.
*** 99. Опечатки в доке
> 99.1. В документации про math:random:
> 99.2. try. Перехват и обработка ошибок
99.3. try.
fixed
PAF
- myke спрашивает в почте, Александр Петросян (PAF) [M] 15.05.2002 11:48
- PAF отвечает в форуме, Александр Петросян (PAF) [M] 15.05.2002 11:49