"Be conservative in APIs & langs design: what you're allowing to do today could be less important than what you're preventing to do tomorrow." @Mario Fusco
"Be conservative in APIs & langs design: what you're allowing to do today could be less important than what you're preventing to do tomorrow." @Mario Fusco
#MakeDelphiGreatAgain, just kidding :D
#MakeDelphiGreatAgain, just kidding :D
Using this slogan you will get some very furious reaction. I'm not one of them though :-)
ReplyDeleteIf you first add "safety nets" then you can be more optimistic adding new things, without getting stuck on deciding. Many times minor features open unexpected progress paths you didn't know before
ReplyDeleteHe would like it: it is both catchy and nonsensical, makes one sound wise, and like one can predict the future while still being conservative. Misses an expletive at the end, though.
ReplyDeleteg,d&r
Eric Grange The post needs to be entirely in orange font for full effect.
ReplyDeleteIt is certainly very important to think deep into the API you are going to expose. It helps to have a checklist of design goals and usability goals you want to achieve. Finally, exposing only the ones that pass the checklist. It is also useful to think about how APIs can grow in future without breaking user code, because needs are going to grow and new ideas are going to coming from all directions. A small example I can give about growing without breaking is with events. Using an object such as EventArgs and sending all the info to the event through this, rather than having multiple arguments of primitive data types, allows you to send new info to the event in future without breaking code: OnBegin(Sender: TObject; EventArgs: TBeginJobEventArgs). This may of course be more useful in specific domains, but it won't hurt in general it seems. So conservative may not be the word, but it's important to not spoil an API and early in the dev cycle is crucial.
ReplyDeleteGirish Patil EventArgs is a good tip. Changed method params, at least the compiler will raise an error so its detectable at compile time.
ReplyDeleteAnother very useful "safety net" is DefineProperties. And deprecated clauses.
I wish the ide had more sophisticated mechanisms to resolve forward changes, maybe using special attributes to refactor changes automatically with just minor confirmation yes/no questions to the developer.
Similar to when opening inherited forms, problems are asked to resolve with a dialog.
With all these help, an api can evolve faster