Недавно вышла новая статья Herb Sutter'а "Prefer Futures to Baked-In "Async APIs" , в которой он анализирует различные варианты как предоставлять асинхронность операций API. В конце статьи Саттер приходит к выводу, что лучше такого не предоставлять отдельное асинхронное API, т.к. любая реализация будет мешать пользователю библиотеки, и тогда разработчик, который пользуется этой библиотекой, сможет сделать асинхронность так, как удобно именно ему, а не какому-то стороннему дяде (привет Adobe с их C++ PDF API), и только для тех функций, которые нужны ему в асинхронном виде. Как один из плюсов такого подхода, Саттер приводит остановку бессмысленного раздувания программных библиотек.
Вот интересно, а сам Саттер понимал, что его статья подтолкнёт программистов, которые используют сторонние библиотеки, к удобной им реализации асинхронности функций, даже в ущерб уже доступному асинхронному API? И зная Саттера с его стремлением к concurrent коду и эффективной реализации многопоточности, можно сказать, что он сознательно провоцирует на это.
Читайте Саттера, кто этого ещё не делает, и обдумывайте прочитанное - возможно самое вкусное вы пока не заметили.
Сообщения
Комментариев нет:
Отправить комментарий