On 1/31/08 2:51 PM, in article [EMAIL PROTECTED], "Howard Lewis Ship" <[EMAIL PROTECTED]> wrote:
> I have also though about adding additional methods to the > Configuration interfaces, override() methods that would operate on a > second pass after the add() methods have their chance. But then you > fall off a cliff .. how do you detect and handle override() conflicts? > Do you need override2(), override3()? > > Probably a single level of override() would be nice. > > For OrderedConfiguration, some ability to override just the ordering > of an existing named element might be handy. Yeah, it's definitely tricky, especially given how easy it is for modules to add configurations. Some ideas that are coming to mind are: - Maybe dump configuration additions / overrides to the console at startup, much like the service status. This could be turned off for production mode. - Endorse a naming convention for disambiguity within external modules. - Endorse a practice of only using add() in distributable modules, expecting end users to alias(key, key) for an override, if necessary. - Single level override (you already said it, but it seems like a good idea) - Add an optional third parameter that indicates a failure should be thrown if a key has already been overridden (similar to previous point, but allows end user to override another module that may override another, and so forth). I haven't fleshed these out in detail. In was more a flow of thoughts. I'll consider them a bit more and follow-up later. -- Kevin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
