Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.
[cut] I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.
Т.е. у самого у тебя нет аргументов в поддержку этой точки зрения?
Здравствуйте, igna, Вы писали:
I>Ищу аргументы против API вроде следующего (пример на С, хотя в действительности используется другой язык):
I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.
Ну вообще-то все, что общается с внишним миром через строчки, примерно так и работает.
Просто эти строчки обычно приходят из конфигов, по сети или еще как-нибудь, а не прямо в коде растут, если это не код юнит теста, конечно же.
Здравствуйте, 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.
лэт ми спик фром май харт
Re[4]: Ищу статью на тему, какой API является плохим
Здравствуйте, Курилка, Вы писали:
К>Ну может озвучишь? К>Я вот больших проблем не вижу, только если возможно лишнее "заворачивание" параметров + неявный код возврата.
Объединение входных и выходных данных в одной структуре.
Избыточность одного из параметров succeeded и failed.
Наличие неиспользуемого параметра ready.
Использование строк вместо перечислений и булевых значений.
Зачем-то возвращается указатель на другую (?) структуру job.
Re[4]: Ищу статью на тему, какой API является плохим
Здравствуйте, igna, Вы писали:
К>>Ну может озвучишь? К>>Я вот больших проблем не вижу, только если возможно лишнее "заворачивание" параметров + неявный код возврата.
I>Объединение входных и выходных данных в одной структуре.
Из описания структуры неясно, что есть входной параметр, а что выходной. Может быть эта структура используется в нескольких методах и где-то параметрами служит одно, а где-то другое?
I>Избыточность одного из параметров succeeded и failed.
Надо читать документацию к параметрам\смотреть код. Действительно ли в 100% случаях эти поля содержат (обязаны содержать) противоположные значения? Раз так: что-то одно действительно не нужно.
I>Наличие неиспользуемого параметра ready.
Не используемого кем? В твоём примере? Без информации о том, что задумывал (должен был сделать) автор метода ответить нельзя.
I>Использование строк вместо перечислений и булевых значений.
Да, эт не очень.
I>Зачем-то возвращается указатель на другую (?) структуру job.
Может быть, это "зачем-то" и отвечает на всё вопросы? Задай свои вопросы автору, может, он сумеет просветить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Re[6]: Ищу статью на тему, какой API является плохим
Здравствуйте, _FRED_, Вы писали:
_FR>Из описания структуры неясно, что есть входной параметр, а что выходной. Может быть эта структура используется в нескольких методах и где-то параметрами служит одно, а где-то другое?
Нет.
_FR>Надо читать документацию к параметрам\смотреть код. Действительно ли в 100% случаях эти поля содержат (обязаны содержать) противоположные значения? Раз так: что-то одно действительно не нужно.
_FR>Не используемого кем? В твоём примере? Без информации о том, что задумывал (должен был сделать) автор метода ответить нельзя.
ready используется в имплементации, собственно вся структура job используется в имплементации, с точки зрения последней и succeeded с failed не избыточны, проблема в том, что все это вывешено на обозрение пользователю.
Re[7]: Ищу статью на тему, какой API является плохим
Здравствуйте, igna, Вы писали:
_FR>>Не используемого кем? В твоём примере? Без информации о том, что задумывал (должен был сделать) автор метода ответить нельзя.
I>ready используется в имплементации, собственно вся структура job используется в имплементации, с точки зрения последней и succeeded с failed не избыточны, проблема в том, что все это вывешено на обозрение пользователю.
Если у тебя есть реализация метода, то показывай её.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, igna, Вы писали:
I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.
Это не г, это просто сделано не для людей. Для автоматического генератора вызова, например. Сравни с IDispath в COM, с XML-RPC.
Руками такое, конечно, неприятно использовать.
Делай что должно, и будь что будет
Re[3]: Ищу статью на тему, какой API является плохим
Здравствуйте, SergH, Вы писали:
SH>Это не г, это просто сделано не для людей. Для автоматического генератора вызова, например. Сравни с IDispath в COM, с XML-RPC. SH>Руками такое, конечно, неприятно использовать.
Здравствуйте, igna, Вы писали:
I>Хорошо бы поиметь ссылку на какую-нибудь авторитетную статью на английском языке, в которой подобный API торжественно объявляется чем-нибудь на букву г.
Какие требования к этому API? Ведь не случайно же оно такое. ioctl, rpc и т.п. имеют право на существование, потому что разрабатывались с учетом специфических требований.
Re[2]: Ищу статью на тему, какой API является плохим
Здравствуйте, alexeiz, Вы писали:
A>Какие требования к этому API? Ведь не случайно же оно такое. ioctl, rpc и т.п. имеют право на существование, потому что разрабатывались с учетом специфических требований.
Нет к нему (пока) никаких требований.
Re[3]: Ищу статью на тему, какой API является плохим
Здравствуйте, igna, Вы писали: I>А то, что в одну структуру засунуты входные и выходные данные, это нормально?
А почему бы нет?
Можно, конечно, распилить структуру на две части. Но это будет, фактически, шило на мыло.
Прикол в том, что использование для выходных данных переданной тебе структуры (вместо возврата указателя на другую структуру) решает проблемы с управлением памятью. Если вызов возвращает указатель, то кто и как должен его освободить?
Если вызов возвращает структуру по значению, то как расширять эту структуру в случае выхода новых версий протокола?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Ищу статью на тему, какой API является плохим
Здравствуйте, Sinclair, Вы писали:
S>Можно, конечно, распилить структуру на две части. Но это будет, фактически, шило на мыло.
Не согласен, но не берусь тебе мое несогласие обосновывать. Собственно потому и ищу статью на тему, потому-что надеюсь найти там весомые и хорошо сформулированные аргументы. (Как нашел в свое время аргументы против наследования от неабстрактных классов, если не ошибаюсь в книге Joshua Bloch, Effective Java.)
S>Прикол в том, что использование для выходных данных переданной тебе структуры (вместо возврата указателя на другую структуру) решает проблемы с управлением памятью. Если вызов возвращает указатель, то кто и как должен его освободить? S>Если вызов возвращает структуру по значению, то как расширять эту структуру в случае выхода новых версий протокола?
Нет там этой проблемы.
Re[4]: Ищу статью на тему, какой API является плохим
Здравствуйте, Alexander G, Вы писали:
AG>Т.е. любой метод, который и читает и пишет поля класса считается ненормальным?
С чего бы? Под твое определение попадает случай, когда какое-то поле используется как для чтения, так и для записи; но там четкое разделение, одни поля для чтения, другие для записи.