Hi Oleg, > What if we approached the problem form a different angle and simply did > away with parameter linking in HttpCore altogether? Hierarchy building > is used only in a handful of high level protocol classes and always for > representing an ultra-trivial parent / child relationship. > > This would enable us to get rid of a lots of complexity and push the > decision about the specifics of parameter resolution to out of core to > higher level modules such as HttpClient.
That's a change that should be considered by it's own merit. If you feel that a stack approach would reduce complexity and not generate too much garbage, go ahead and change it. > This would also render the > whole 'unsetting parameter' issue an implementation detail each upstream > project can choose to solve differently. Not "can" but "must" choose to solve, or run into problems down the road. And because it isn't addressed in core, every project needs to solve it differently. If we implement the "global null value" approach, that should be done in core so that every project using core can use the same null for all parameters. If we prefer to deal with the problem on a case-by-case basis, then it can be done in each module/component/project that defines a parameter for which it matters. What I do not want to see is a bunch of projects that each define a non-global null value just for their own parameters or HttpParams implementations. As mentioned in my other mail, I believe now that the changes for a global null value in core will be compatible, so this does not block the release of beta1. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
