News for hackers. Stuff that matters.
Re:Pitfalls of Callback-Based APIs by rian on Tuesday December 23, 2014 @09:09PM (#8791231)
Yes, the core issue in the database logger example is that it's a circular dependency.

The point of the article is that callback-based APIs like this obscure the actual problems (like circular dependencies).

You're right that constrained designs prevents issues like these but callback-based APIs aren't inherently constrained. They allow anything to happen, which is why they conversely encourage errors like these (and are subject to pitfalls).

Re:Pitfalls of Callback-Based APIs by groby_b on Tuesday December 23, 2014 @09:42PM (#8791317)
What would be an inherently constrained API, then? I've successfully managed to create circular dependencies in quite a few different styles, so I'd love to find one that saves me from myself ;)
Re:Pitfalls of Callback-Based APIs by rian on Tuesday December 23, 2014 @10:05PM (#8791372)
Maybe inherently was the wrong word. Though you can imagine a logger API that was like this:

    typedef enum {
        CONSOLE_LOGGER,
        DATABASE_LOGGER,
        /* etc. */
    } LoggerType;

    void add_logger(LoggerType);
In this API you're constrained by what loggers you can add. It's not the totally unchecked free-for-all that a callback-based API provides. The user is strictly unable to shoot themselves in the foot.

But this limits the expressive power that callbacks provide. Sorry I don't have any other API recommendations. The only way I can think of to stay expressive while safeguarding against unintended abuse is to include code analysis.