@weaverryan have we consider the chance that helperset embed in an application console (not a symfony one and not the default one) can actually decouple things nicely using it? when you say that the helperset does not make available formats that i follow, but that is always thinking we are using the symfony implementation by default where things are hard coded until this day. However, when i wrote the docu i thought about this and saw it for stand alone console apps where i have extended the application class like in Gush and use the helper (like we also use in one instance at least in Gush) to plug another helper, not a descriptor yet but it is likely for a console standalone app to use this abstraction to carry on and extend their descriptors via helperset and overriding the limitations of the default hard coded stuff. So i think the entry is very valid. This is why in paragraph 1 i explained the history, 2, i emphasize the default usage, 3, the customization door. About the whether extending is better than implementing the interface is not paramount as people are all over the map, because method overriding can be enough sometimes.

We should note that for those using the built-in descriptors via flags on the cli they don't need a cookbook. The entry is for documenting things and well symfony is all about documenting extension points. This is why i like the security documentation @drak wrote, is very good describing what the architecture and extension points are.