Ищу аргументы против API вроде следующего (пример на С, хотя в действительности используется другой язык):

struct job {
    char *whatToDo;
    char *howToDo;
    char *parameters;
    char *ready;
    char *succeeded;
    char *failed;
    char *whyFailed;
};

Job *do_job(job *pJob);

Используется это дело примерно так:

    struct job j, *pj;
    j.whatToDo = "Nothing";
    j.howToDo = "QuickAndDirty";
    j.parameters = "A=1;B=2"
    pj = do_job(&j);
    if (pj->failed)
        printf("failed: %s", pj->whyFailed);

Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.

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

[cut]
I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.

Т.е. у самого у тебя нет аргументов в поддержку этой точки зрения?

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

I>Ищу аргументы против API вроде следующего (пример на С, хотя в действительности используется другой язык):

I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.

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

You will always get what you always got
  If you always do  what you always did

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

К>Т.е. у самого у тебя нет аргументов в поддержку этой точки зрения?

Есть, но хочется больше.

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

J>Ну вообще-то все, что общается с внишним миром через строчки, примерно так и работает.

А то, что в одну структуру засунуты входные и выходные данные, это нормально?

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

I>Здравствуйте, Курилка, Вы писали:

К>>Т.е. у самого у тебя нет аргументов в поддержку этой точки зрения?

I>Есть, но хочется больше.

Ну может озвучишь?
Я вот больших проблем не вижу, только если возможно лишнее "заворачивание" параметров + неявный код возврата.

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

I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.

Да элементарно: открываешь википедию, придумываешь термин, скажем ASPP (Absolutely Stupid Parameters Passing). Ну и саму статью в стиле:

Only asses pass parameters into functions in the following way:
struct job {
char *whatToDo;
char *howToDo;
char *parameters;
char *ready;
char *succeeded;
char *failed;
char *whyFailed;
};

Job *do_job(job *pJob);

The foolishness of this approach is obvious to everybody except asses.

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

К>Ну может озвучишь?
К>Я вот больших проблем не вижу, только если возможно лишнее "заворачивание" параметров + неявный код возврата.

Объединение входных и выходных данных в одной структуре.
Избыточность одного из параметров succeeded и failed.
Наличие неиспользуемого параметра ready.
Использование строк вместо перечислений и булевых значений.
Зачем-то возвращается указатель на другую (?) структуру job.

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

К>Я вот больших проблем не вижу

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

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

К>>Ну может озвучишь?
К>>Я вот больших проблем не вижу, только если возможно лишнее "заворачивание" параметров + неявный код возврата.

I>Объединение входных и выходных данных в одной структуре.

Из описания структуры неясно, что есть входной параметр, а что выходной. Может быть эта структура используется в нескольких методах и где-то параметрами служит одно, а где-то другое?

I>Избыточность одного из параметров succeeded и failed.

Надо читать документацию к параметрам\смотреть код. Действительно ли в 100% случаях эти поля содержат (обязаны содержать) противоположные значения? Раз так: что-то одно действительно не нужно.

I>Наличие неиспользуемого параметра ready.

Не используемого кем? В твоём примере? Без информации о том, что задумывал (должен был сделать) автор метода ответить нельзя.

I>Использование строк вместо перечислений и булевых значений.

Да, эт не очень.

I>Зачем-то возвращается указатель на другую (?) структуру job.

Может быть, это "зачем-то" и отвечает на всё вопросы? Задай свои вопросы автору, может, он сумеет просветить.

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

_FR>Из описания структуры неясно, что есть входной параметр, а что выходной. Может быть эта структура используется в нескольких методах и где-то параметрами служит одно, а где-то другое?

Нет.

_FR>Надо читать документацию к параметрам\смотреть код. Действительно ли в 100% случаях эти поля содержат (обязаны содержать) противоположные значения? Раз так: что-то одно действительно не нужно.

_FR>Не используемого кем? В твоём примере? Без информации о том, что задумывал (должен был сделать) автор метода ответить нельзя.

ready используется в имплементации, собственно вся структура job используется в имплементации, с точки зрения последней и succeeded с failed не избыточны, проблема в том, что все это вывешено на обозрение пользователю.

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

_FR>>Не используемого кем? В твоём примере? Без информации о том, что задумывал (должен был сделать) автор метода ответить нельзя.

I>ready используется в имплементации, собственно вся структура job используется в имплементации, с точки зрения последней и succeeded с failed не избыточны, проблема в том, что все это вывешено на обозрение пользователю.

Если у тебя есть реализация метода, то показывай её.

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

I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.

Это не г, это просто сделано не для людей. Для автоматического генератора вызова, например. Сравни с IDispath в COM, с XML-RPC.
Руками такое, конечно, неприятно использовать.

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

I>А то, что в одну структуру засунуты входные и выходные данные, это нормально?

Т.е. любой метод, который и читает и пишет поля класса считается ненормальным?

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

SH>Это не г, это просто сделано не для людей. Для автоматического генератора вызова, например. Сравни с IDispath в COM, с XML-RPC.
SH>Руками такое, конечно, неприятно использовать.

К сожалению это сделано для людей.

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

I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.

Какие требования к этому API? Ведь не случайно же оно такое. ioctl, rpc и т.п. имеют право на существование, потому что разрабатывались с учетом специфических требований.

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

A>Какие требования к этому API? Ведь не случайно же оно такое. ioctl, rpc и т.п. имеют право на существование, потому что разрабатывались с учетом специфических требований.

Нет к нему (пока) никаких требований.

Здравствуйте, igna, Вы писали:
I>А то, что в одну структуру засунуты входные и выходные данные, это нормально?
А почему бы нет?
Можно, конечно, распилить структуру на две части. Но это будет, фактически, шило на мыло.
Прикол в том, что использование для выходных данных переданной тебе структуры (вместо возврата указателя на другую структуру) решает проблемы с управлением памятью. Если вызов возвращает указатель, то кто и как должен его освободить?
Если вызов возвращает структуру по значению, то как расширять эту структуру в случае выхода новых версий протокола?

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

S>Можно, конечно, распилить структуру на две части. Но это будет, фактически, шило на мыло.

Не согласен, но не берусь тебе мое несогласие обосновывать. Собственно потому и ищу статью на тему, потому-что надеюсь найти там весомые и хорошо сформулированные аргументы. (Как нашел в свое время аргументы против наследования от неабстрактных классов, если не ошибаюсь в книге Joshua Bloch, Effective Java.)

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

Нет там этой проблемы.

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

AG>Т.е. любой метод, который и читает и пишет поля класса считается ненормальным?

С чего бы? Под твое определение попадает случай, когда какое-то поле используется как для чтения, так и для записи; но там четкое разделение, одни поля для чтения, другие для записи.