You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Vincent Massol <vm...@octo.com> on 2001/12/12 18:59:30 UTC
new method Configuration.containsAttribute() ?
Hi,
I am using the org.apache.avalon.framework.configuration.Configuration
object in some of my Configurable components and I find that it is not
very easy to decide whether a Configuration contains an attribute or
not. There is a getAtribute() which takes a default value but that's not
enough.
I'm proposing to add a Boolean containsAttribute(String name). What do
you think ? Should I go ahead a send a patch (in other words, do you
agree to include it in the base Avalon framework) ?
Or is there another that I have missed of doing this ? With the current
code base I can see 2 ways of doing this :
1/ testing for a ConfigurationException, which does not seem a good idea
2/ call getAttributeNames() and iterate to find if the attribute exist,
which is also not that fine.
Thanks
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: new method Configuration.containsAttribute() ?
Posted by Peter Donald <pe...@apache.org>.
On Thu, 13 Dec 2001 07:00, Vincent Massol wrote:
> So, in conclusion, forget my previous proposition and instead, what
> would you think of :
>
> public Hashtable getAttributes();
Hashtable and Vectors are mutable while the Configuration API requires
immutability so ...
--
Cheers,
Pete
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: new method Configuration.containsAttribute() ?
Posted by Vincent Massol <vm...@octo.com>.
Thanks Peter. Berin has already suggested this to me but I didn't like
too much as it was an indirect way of testing for existence, like using
Hashtable.get("key") == null instead of Hashtable.containsKey("key")
which better captures the intent. However, that will do for the time
being ... :-)
Cheers,
-Vincent
> -----Original Message-----
> From: Peter Royal [mailto:proyal@managingpartners.com]
> Sent: 12 December 2001 20:48
> To: Avalon Developers List
> Subject: Re: new method Configuration.containsAttribute() ?
>
> On Wednesday 12 December 2001 03:37 pm, you wrote:
> > I can imagine lots of cases where you would need to verify if an
> > attribute exists because you may want to do something different if
it
> > does than if it does not.
>
> String value = configuration.getAttribute("attr", null);
>
> if (value == null) {
> //there was no attribute
> } else if ("".equals(value)) {
> //exists but empty
> } else {
> //exists and non-empty
> }
>
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
>
> --
> To unsubscribe, e-mail: <mailto:avalon-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-
> help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: new method Configuration.containsAttribute() ?
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 12 December 2001 03:37 pm, you wrote:
> I can imagine lots of cases where you would need to verify if an
> attribute exists because you may want to do something different if it
> does than if it does not.
String value = configuration.getAttribute("attr", null);
if (value == null) {
//there was no attribute
} else if ("".equals(value)) {
//exists but empty
} else {
//exists and non-empty
}
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: new method Configuration.containsAttribute() ?
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: 12 December 2001 21:05
> To: Avalon Developers List
> Subject: Re: new method Configuration.containsAttribute() ?
>
> Vincent Massol wrote:
>
> > Ok. Here is my use case :
> >
> > <configurationFactory>
> >
> > <bundle id="short name1"
> > [language="language1"]
> > [country="Country1"]>
> >
> > /path/to/bundle1
> >
> > </bundle>
> >
> > </configurationFactory>
> >
> > In the implementation code I'd like to take one action if no
> > language/country are specified and another if they are (because
behind
> > the scenes I need to call an API which has 2 signatures, one with a
> > Locale and one without - I don't want to get the default locale and
only
> > use the signature that accepts a locale as this would mean I
override
> > the default implementation of the API I'm referring to as I would
> > introduce my own logic).
>
>
> The single parameter method is only a shortcut for what you are really
> doing. It is not your "own" logic per se.
>
> In your case, the ResourceBundle.getBundle(String) method is exactly
the
> same as:
>
> getBundle(baseName, Locale.getDefault(),
> this.getClass().getClassLoader())
>
> As it says directly in the JavaDocs. The Locale is a bit different if
> you are not using the default because you have to have a language, but
> can further specify it with a country or variant.
hehe doing some extrapolation ... :) I had voluntarily not explained
what I was doing with the Locale in my previous email so that you would
not find a way around ... :) ... but apparently it failed ...
Actually, I'm not doing a ResourceBundle.getBundle() but using another
class which wraps around Bundle. However, I wanted the discussion to be
more generic and simply consider the case where I need to decide what to
do in my code based upon the fact that an attribute exist or not.
>
> In this particular case, I might do something like this:
>
> Locale defLocale = Locale.getDefault();
> String language = conf.getAttribute("language",
defLocale.getLanguage());
> String country = conf.getAttribute("country", defLocale.getCountry());
>
> Locale usedLocale = new Locale(language, country);
> getBundle(baseName, usedLocale);
>
>
> Ideally, you would have a static constants interface that would define
> your
> default language/country:
>
> interface Constants
> {
> String DEFAULT_LANGUAGE = Locale.getDefault().getLanguage();
> String DEFAULT_COUNTRY = Locale.getDefault().getCountry();
> }
>
>
>
> > I can imagine lots of cases where you would need to verify if an
> > attribute exists because you may want to do something different if
it
> > does than if it does not.
>
>
> We would have to vote on adding the "boolean attributeExists()" method
> to Configuration. It might not happen, and I am +0 on it. I'm not
> going to stand in it's way, but not totally convinced it's necessary.
>
The getChild() API has a signature that allows for returning null and
thus testing for existence. Why couldn't we have the same thing for
attributes. However, I'm not going to press this issue as I can always
use the
null == getAttribute("key", null)
construct. Let's forget it then, until someone else needs it ... :)
Thanks for the help.
-Vincent
>
> > Ok about immutability :)
> >
> > Forget about hashtable. Isn't there an ImmutableHashtable in a
utility
> > class anywhere that would have the same API save for the write
methods ?
>
>
> java.util.Collections.unmodifiableMap(Map)
>
> And for this purpose is a hack.
>
> --
>
> "They that give up essential liberty to obtain a little temporary
safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail: <mailto:avalon-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-
> help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: new method Configuration.containsAttribute() ?
Posted by Berin Loritsch <bl...@apache.org>.
Vincent Massol wrote:
> Ok. Here is my use case :
>
> <configurationFactory>
>
> <bundle id="short name1"
> [language="language1"]
> [country="Country1"]>
>
> /path/to/bundle1
>
> </bundle>
>
> </configurationFactory>
>
> In the implementation code I'd like to take one action if no
> language/country are specified and another if they are (because behind
> the scenes I need to call an API which has 2 signatures, one with a
> Locale and one without - I don't want to get the default locale and only
> use the signature that accepts a locale as this would mean I override
> the default implementation of the API I'm referring to as I would
> introduce my own logic).
The single parameter method is only a shortcut for what you are really
doing. It is not your "own" logic per se.
In your case, the ResourceBundle.getBundle(String) method is exactly the
same as:
getBundle(baseName, Locale.getDefault(), this.getClass().getClassLoader())
As it says directly in the JavaDocs. The Locale is a bit different if
you are not using the default because you have to have a language, but
can further specify it with a country or variant.
In this particular case, I might do something like this:
Locale defLocale = Locale.getDefault();
String language = conf.getAttribute("language", defLocale.getLanguage());
String country = conf.getAttribute("country", defLocale.getCountry());
Locale usedLocale = new Locale(language, country);
getBundle(baseName, usedLocale);
Ideally, you would have a static constants interface that would define your
default language/country:
interface Constants
{
String DEFAULT_LANGUAGE = Locale.getDefault().getLanguage();
String DEFAULT_COUNTRY = Locale.getDefault().getCountry();
}
> I can imagine lots of cases where you would need to verify if an
> attribute exists because you may want to do something different if it
> does than if it does not.
We would have to vote on adding the "boolean attributeExists()" method
to Configuration. It might not happen, and I am +0 on it. I'm not
going to stand in it's way, but not totally convinced it's necessary.
> Ok about immutability :)
>
> Forget about hashtable. Isn't there an ImmutableHashtable in a utility
> class anywhere that would have the same API save for the write methods ?
java.util.Collections.unmodifiableMap(Map)
And for this purpose is a hack.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: new method Configuration.containsAttribute() ?
Posted by Vincent Massol <vm...@octo.com>.
Ok. Here is my use case :
<configurationFactory>
<bundle id="short name1"
[language="language1"]
[country="Country1"]>
/path/to/bundle1
</bundle>
</configurationFactory>
In the implementation code I'd like to take one action if no
language/country are specified and another if they are (because behind
the scenes I need to call an API which has 2 signatures, one with a
Locale and one without - I don't want to get the default locale and only
use the signature that accepts a locale as this would mean I override
the default implementation of the API I'm referring to as I would
introduce my own logic).
I can imagine lots of cases where you would need to verify if an
attribute exists because you may want to do something different if it
does than if it does not.
Ok about immutability :)
Forget about hashtable. Isn't there an ImmutableHashtable in a utility
class anywhere that would have the same API save for the write methods ?
Thanks
-Vincent
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: 12 December 2001 20:25
> To: Avalon Developers List
> Subject: Re: new method Configuration.containsAttribute() ?
>
> Vincent Massol wrote:
>
> >
> > ah, that's what I was missing. It never occurred to me that it was
valid
> > to pass a null value ! However, it does not seem a very nice way of
> > doing it as it does not reflect what you're trying to achieve
(checking
> > if an attribute has been defined).
>
>
> <snip/>
>
> > So, in conclusion, forget my previous proposition and instead, what
> > would you think of :
> >
> > public Hashtable getAttributes();
>
>
> -1
>
> The configuration API needs to remain immutable. You also still
didn't
> answer the question of *why* you needed to test if an attribute was
> available.
>
> A component should be able to configure itself with default values,
and
> use the passed in Configuration object to override those defaults. If
> you want to test for a missing attribute, I have to ask what it
affords
> you over defaulting your values.
>
> For instance, if you have a component that will run a background
thread
> depending on the value of an attribute, I would rather see something
> like this:
>
> boolean bgThread = configuration.getAttributeAsBoolean("use-thread",
> false);
>
> Do you see how that works?
>
> I am still trying to imagine *why* you need the attributeExists("use-
> thread");
> type functionality.
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary
safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail: <mailto:avalon-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-
> help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: new method Configuration.containsAttribute() ?
Posted by Berin Loritsch <bl...@apache.org>.
Vincent Massol wrote:
>
> ah, that's what I was missing. It never occurred to me that it was valid
> to pass a null value ! However, it does not seem a very nice way of
> doing it as it does not reflect what you're trying to achieve (checking
> if an attribute has been defined).
<snip/>
> So, in conclusion, forget my previous proposition and instead, what
> would you think of :
>
> public Hashtable getAttributes();
-1
The configuration API needs to remain immutable. You also still didn't
answer the question of *why* you needed to test if an attribute was
available.
A component should be able to configure itself with default values, and
use the passed in Configuration object to override those defaults. If
you want to test for a missing attribute, I have to ask what it affords
you over defaulting your values.
For instance, if you have a component that will run a background thread
depending on the value of an attribute, I would rather see something
like this:
boolean bgThread = configuration.getAttributeAsBoolean("use-thread", false);
Do you see how that works?
I am still trying to imagine *why* you need the attributeExists("use-thread");
type functionality.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: new method Configuration.containsAttribute() ?
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: 12 December 2001 18:13
> To: Avalon Developers List
> Subject: Re: new method Configuration.containsAttribute() ?
>
> Vincent Massol wrote:
>
> > Hi,
> >
> > I am using the
org.apache.avalon.framework.configuration.Configuration
> > object in some of my Configurable components and I find that it is
not
> > very easy to decide whether a Configuration contains an attribute or
> > not. There is a getAtribute() which takes a default value but that's
not
> > enough.
> >
> > I'm proposing to add a Boolean containsAttribute(String name). What
do
> > you think ? Should I go ahead a send a patch (in other words, do you
> > agree to include it in the base Avalon framework) ?
>
>
> Can you provide a use case for such a thing? How do you propose to
use
> the containsAttribute() method? Why *exactly* is the defaulted
version
> of getAttribute() not enough?
>
> I need some more info if I am going to back you on this.
>
see below.
>
>
> > Or is there another that I have missed of doing this ? With the
current
> > code base I can see 2 ways of doing this :
> > 1/ testing for a ConfigurationException, which does not seem a good
idea
> > 2/ call getAttributeNames() and iterate to find if the attribute
exist,
> > which is also not that fine.
>
>
> Why do you need to know if it does not exist?
>
>
> Also have you considered this:
>
> String value = configuration.getAttribute( "name", null );
> if ( null == value )
> {
> // do the processing if it is not here
> }
>
ah, that's what I was missing. It never occurred to me that it was valid
to pass a null value ! However, it does not seem a very nice way of
doing it as it does not reflect what you're trying to achieve (checking
if an attribute has been defined).
It is the same as if you're saying that whenever you want to check if a
value is in a hashtable you were writing :
if (null == hashtable.get("key")
Instead of
if (hashtable.containsKey("key"))
Another option is to return the attributes as a Vector, in addition to
an array of strings (but unfortunately we can't use the same method name
as it would be the same signature...), which would let us write :
If (configuration.getAttributesNamesAsVector().contains("attribute
name"))
Another option: return a hashtable of attributes :
If (configuration.getAttributes().containsKey("attribute name"))
I personally prefer this last option as it let you benefit from all the
API of a hashtable and you don't have to reproduce its API in the
Configuration API.
So, in conclusion, forget my previous proposition and instead, what
would you think of :
public Hashtable getAttributes();
Thanks Berin
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: new method Configuration.containsAttribute() ?
Posted by Berin Loritsch <bl...@apache.org>.
Vincent Massol wrote:
> Hi,
>
> I am using the org.apache.avalon.framework.configuration.Configuration
> object in some of my Configurable components and I find that it is not
> very easy to decide whether a Configuration contains an attribute or
> not. There is a getAtribute() which takes a default value but that's not
> enough.
>
> I'm proposing to add a Boolean containsAttribute(String name). What do
> you think ? Should I go ahead a send a patch (in other words, do you
> agree to include it in the base Avalon framework) ?
Can you provide a use case for such a thing? How do you propose to use
the containsAttribute() method? Why *exactly* is the defaulted version
of getAttribute() not enough?
I need some more info if I am going to back you on this.
> Or is there another that I have missed of doing this ? With the current
> code base I can see 2 ways of doing this :
> 1/ testing for a ConfigurationException, which does not seem a good idea
> 2/ call getAttributeNames() and iterate to find if the attribute exist,
> which is also not that fine.
Why do you need to know if it does not exist?
Also have you considered this:
String value = configuration.getAttribute( "name", null );
if ( null == value )
{
// do the processing if it is not here
}
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>