> > I'm not trying to talk you out of the current Restlet design, > > but I would rather have it described as the result of some > > tough design decisions on trade-offs concerning evolvability > > and implementation inheritance, not as "classes are better > > than interfaces in APIs". > > This is a better description of the subject indeed, and one that reflects > the design process that took place to design the v1 of the Restlet API. For > example, the initial versions had interfaces for all the artifacts. > Feed-back, discussions, readings led me to reconsider this approach. > > I'm open to try a different path for the design of the v2 of the API. At > this point, we will have more experience on our problem domain and we will > be able to afford more radical changes.
I had pushed a little bit against the move away from interfaces. I didn't like it but I understood that a design goal of Restlet was to converge onto an API through experience rather than try to get it right up front. Given that poorly charted territory was being navigated, I felt this was a helpful approach. I am glad to hear Jerome, that you are willing to reconsider the decision about interfaces. Stated differently, maybe when the convergence is over, it will be much safer to move to interfaces. The nearly immutable nature of interfaces won't be such an issue since the API questions will have mostly been answered. Sean
