I should add a final note... I haven't tested this, but it may not be
the builder vs non-builder that is at fault here, but hierachical
(since builder uses this via combined configuration) vs non-
hierachical (since the test case uses this - via BaseConfiguration)
On 11/02/2007, at 11:54 PM, Brett Porter wrote:
Well, it has become even more confusing :) My assessment is that it
should be left as it is currently for 1.4 (see below).
I've attached some unit tests to the issue.
I've found that under 1.3, the same configurations constructed
using a builder behave differently to those constructed by hand.
This meant that:
- using a builder, you could resolve a key within the subset when
interpolating in that subset, but that you could not do this when
not using a builder
- using a builder, you could not resolve a key from the parent in a
subset (this is what CONFIGURATION-242 fixes), but you could outside.
Under 1.4, everything behaves consistently, between builder and non-
builder. This is achieved by changing the first point above so that
it doesn't work under either scenario (which is what I considered a
regression).
You could consider this the correct behaviour, though - it is now
consistent, and if it did work as before (even if it were under
both builder and non-builder), there was another inconsistency:
under both 1.3 and 1.4 if you lookup the same key from the parent,
the variable is resolved against the parent only, causing an
inconsistency when you look it up.
So...
* the behaviour is now consistent, and I think that's worthwhile
retaining for a 1.4 release. The changes should be noted in the
release notes - ie, you can no longer lookup within a subset.
* it *may* be worth filing an future enhancement to restore this
behaviour, in such a way that it applies to both builder and non-
builder, and so that if looked up from the parent it still resolves
the same (by remembering which subset the interpolation belongs to
- perhaps by automatically adding an optional prefix to any
expressions inside subsets such that the interpolator first looks
inside the subset, then into the root if not found)
I hope that makes sense - it's rather difficult to explain, but
hopefully the attached sample does a better job :)
- Brett
On 11/02/2007, at 3:13 AM, Oliver Heger wrote:
Brett Porter wrote:
Hi,
I tested out 1.4 on some code I have using 1.3, which has some
expressions that resolve within the same configuration, but which is
located at a different prefix (via config-at). This broke under
1.4, as
it now assumes all interpolations need to happen in the parent.
The feature is definitely useful - but should it first look
inside the
subset, and then go to the parent if not found, rather than
skipping
the subset altogether?
Cheers,
Brett
Brett,
can you provide a short example code fragment (or even better a unit
test) that demonstrates this behavior? I will have a look.
Thank you.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
