Здравствуйте,

в программе читается текстовый файл простого формата.
В нём есть два вида лексем:
1. команды
2. аргументы команд

Есть два класса:
1. tokenizer — разбивает строки на лексемы
2. parser — парсит команды

у меня есть функция is_command(), которая определяет является ли лексема коммандой
вот я и думаю куда эту функцию правильнее поместить в токенайзер или парсер?

Здравствуйте, korzhik, Вы писали:

K>Здравствуйте,

K>в программе читается текстовый файл простого формата.
K>В нём есть два вида лексем:
K>1. команды
K>2. аргументы команд

K>Есть два класса:
K>1. tokenizer — разбивает строки на лексемы
K>2. parser — парсит команды

K>у меня есть функция is_command(), которая определяет является ли лексема коммандой
K>вот я и думаю куда эту функцию правильнее поместить в токенайзер или парсер?

Если работа с tokenizer'ом происходит последовательно, то было бы лучше иметь метод, который возвращает тип лексемы на каждом шаге
(что-нибудь типа getTokenType()). В данном случае неудачная идея делать команды типа isCommand(), т.к. могут появиться иные типы токенов, и на каждый придется делать по методу.

Если не последовательно, то это уже наверное и не tokenizer получается, а парсер .
В общем при таком подходе, я бы сделал некоторое представление (класс), которое по команде getCommands() возвращало бы коллекцию команд.
А у каждой команды сделал бы метод getParameters().

Здравствуйте, A_Gura, Вы писали:

A_G>Если работа с tokenizer'ом происходит последовательно, то было бы лучше иметь метод, который возвращает тип лексемы на каждом шаге
A_G>(что-нибудь типа getTokenType()). В данном случае неудачная идея делать команды типа isCommand(), т.к. могут появиться иные типы токенов, и на каждый придется делать по методу.

это правильно. так и сделаю

A_G>Если не последовательно, то это уже наверное и не tokenizer получается, а парсер .
A_G>В общем при таком подходе, я бы сделал некоторое представление (класс), которое по команде getCommands() возвращало бы коллекцию команд.
A_G>А у каждой команды сделал бы метод getParameters().
то есть получается типа DOM?
не мне это не подходит

Здравствуйте, korzhik, Вы писали:

K>Здравствуйте,

K>в программе читается текстовый файл простого формата.
K>В нём есть два вида лексем:
K>1. команды
K>2. аргументы команд

Уж больно высокоуровневые получились лесемы.

Здравствуйте, V.Petrovski, Вы писали:

VP>Здравствуйте, korzhik, Вы писали:

K>>Здравствуйте,

K>>в программе читается текстовый файл простого формата.
K>>В нём есть два вида лексем:
K>>1. команды
K>>2. аргументы команд

VP>Уж больно высокоуровневые получились лесемы.

поясните пожалуйста, я не понял

Здравствуйте, korzhik, Вы писали:

K>Здравствуйте, V.Petrovski, Вы писали:

VP>>Здравствуйте, korzhik, Вы писали:

K>>>Здравствуйте,

K>>>в программе читается текстовый файл простого формата.
K>>>В нём есть два вида лексем:
K>>>1. команды
K>>>2. аргументы команд

VP>>Уж больно высокоуровневые получились лесемы.

K>поясните пожалуйста, я не понял

лекс. анализатор должен разбирать терминальные символы (такие как число, имя, операторные скобки),
а уж что команда, и тем более аргументы команд должен синт. анализатор
Пример (математическое выражение)
cos(1), последовательность лексем: имя, левая скобка, число, правая скобка; на основании этих лексем
парсер решает, что это вызов функции.