On Sat, 10 Nov 2001 21:47, Jeff Turner wrote:
> > > Is there a reason for returning an empty child Configuration, or is
> > > this a bug?
> >
> > Its a feature so that we can support a pattern like
> >
> > c = getChild("foo").getChild("bar").getChild("baz");
>
> If /foo/bar exists, that will work under either system. If /foo or /foo/bar
> doesn't exist, isn't it a logical error for the program to assume it
> does?
maybe. Not sure. It was originally implemented like this when we were talking
about default values for things in config tree. Then people started using the
below construct and we got stuck with it ;)
> What can be done with an empty 'c' object?
s =
getChild("foo").getChild("bar").getChild("baz").getValue("default-value");
will always return a string value (using "default-value" - even if a
intermediate config doesn't exist.
>
> And to gain this "feature", one gives up the logical way to check for a
> subelement's presence (a null check). Though I guess it can still be
> done with:
>
> if (conf.getChid("foo", false) == null) {
> // ..
> }
>
> Anyway, if it's being used in the way you say, the issue probably isn't
> worth breaking everyone's code over.
I got a new funky acronym for that - it's BCS - Backwards Compatability
Syndrome ;]
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
