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

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

VD>>Ты действительно не понял о чем я говрил?

A>О неком непреложном правиле. Нет?

Бывает. Объясняю...

Я говорил, о том, что не нужно использовать тип char (как врочем и любые другие примитивные типы) для возрата некого перечислимого результата.

Если lex и yacc делают так же, то несомненно это кривой дизайн. Но, насколько мне известно, они так не делают. Они используют char для возврата символов.

Здравствуйте, Павел Кузнецов, Вы писали:

Так что же помешало использовать паттерн "Стратегия" для решения данной задачи? Только отговорку — объем кода не нужно приводить. Я тут еще раз подумал и пришел к выводу, что общий объем кода даже сократится.

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

VD>Так что же помешало использовать паттерн "Стратегия" для решения данной задачи? Только отговорку — объем кода не нужно приводить. Я тут еще раз подумал и пришел к выводу, что общий объем кода даже сократится.

Именно объем кода, приводящий к осложнению понимания происходящего, что осложняет дальнейшее сопровождение (вопреки изначальному желанию это упростить).

Каким образом при этом предполагается уменьшить объем кода? Пока что я вижу, что, скажем, вместо (код сильно упрощен, но ключевые моменты -- связь выполняемых действий с контекстом -- должны быть более-менее видны):

. . .

if ( file_exists( destination_path ) )
{
  CommunicatorAnswer< communicator_cancel | communicator_skip | communicator_overwrite >
    a = communicator.destination_file_already_exists( destination_path );

  if ( a == communicator_overwrite )
  {
    this->delete_file( destination_path );
  }
  else
  {
    this->mark_failed( source_path );

    return a == communicator_cancel
      ? operation_dont_process_remaining_files
      : operation_process_remaining_files;
  }
}

this->copy_file( source_path, destination_path );
this->update_db( file_id );

. . .

надо будет навернуть класс, в который нужно будет как-то передавать контекст исполнения (например, чтоб вызвать mark_failed), да еще и как-то заботиться о том, чтобы из него потом все равно получить в том или ином виде информацию о том, нужно ли продолжать исполнение и т.п. И, главное, зачем, если реальная проблема (неожиданное добавление новых возвращаемых значний в destination_file_already_exists) решается просто, не требуя никаких дополнительных усилий у пользователей функции?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Каким образом при этом предполагается уменьшить объем кода? Пока что я вижу, что, скажем, вместо (код сильно упрощен, но ключевые моменты -- связь выполняемых действий с контекстом -- должны быть более-менее видны):
ПК>

ПК>. . .

ПК>if ( file_exists( destination_path ) )
ПК>{
ПК>  CommunicatorAnswer< communicator_cancel | communicator_skip | communicator_overwrite >
ПК>    a = communicator.destination_file_already_exists( destination_path );

ПК>  if ( a == communicator_overwrite )
ПК>  {
    this->>delete_file( destination_path );
ПК>  }
ПК>  else
ПК>  {
    this->>mark_failed( source_path );

ПК>    return a == communicator_cancel
ПК>      ? operation_dont_process_remaining_files
ПК>      : operation_process_remaining_files;
ПК>  }
ПК>}

this->>copy_file( source_path, destination_path );
this->>update_db( file_id );

ПК>. . .
ПК>

ПК>надо будет навернуть класс, в который нужно будет как-то передавать контекст исполнения (например, чтоб вызвать mark_failed), да еще и как-то заботиться о том, чтобы из него потом все равно получить в том или ином виде информацию о том, нужно ли продолжать исполнение и т.п. И, главное, зачем, если реальная проблема (неожиданное добавление новых возвращаемых значний в destination_file_already_exists) решается просто, не требуя никаких дополнительных усилий у пользователей функции?

Проблема не решается. И ты это знашь. Вынесение реакции в отдельный класс только разгрзит прикладной код в котором останется всего лишь вызов этого класса. Ну, и главное. Проблема дейсвительно будет решена. И не какими-то малопонятными равартотами, а примитивным и стало быть всем понятным ООП.

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

VD>Если lex и yacc делают так же, то несомненно это кривой дизайн. Но, насколько мне известно, они так не делают. Они используют char для возврата символов.

А вот и не для возврата символов! Для передачи лексем, которые в исходном коде представляются одиночными символами. То есть, с формальной точки зрения, дизайн некорректный. А с практической — вполне удобный.

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

A>А вот и не для возврата символов! Для передачи лексем, которые в исходном коде представляются одиночными символами. То есть, с формальной точки зрения, дизайн некорректный. А с практической — вполне удобный.

Ой, давно я их смотрел. Но что-то мне подсказывает, что там используется int. И никаких запаковок констант в символы не происходит.

Но пользоваться Яками не очень удобно. Схема принятая в CocoR или ANTLR намного лучше (там можно просто объявлять именованные переменные и возвращать параметры из правил).