Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8844 > unrolled thread

constructing a constant HashMap

Back to article view | Back to comp.lang.java.programmer

Contents

  constructing a constant HashMap Roedy Green <see_website@mindprod.com.invalid> - 2011-10-15 18:14 -0700
    Re: constructing a constant HashMap Arne Vajhøj <arne@vajhoej.dk> - 2011-10-15 21:36 -0400
      Re: constructing a constant HashMap Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-10-16 16:51 +0200
    Re: constructing a constant HashMap markspace <-@.> - 2011-10-15 18:59 -0700
      Re: constructing a constant HashMap Roedy Green <see_website@mindprod.com.invalid> - 2011-10-15 19:25 -0700
    Re: constructing a constant HashMap Roedy Green <see_website@mindprod.com.invalid> - 2011-10-15 19:19 -0700
    Re: constructing a constant HashMap Patricia Shanahan <pats@acm.org> - 2011-10-16 06:07 +0100
      Re: constructing a constant HashMap B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-16 01:29 -0400
        Re: constructing a constant HashMap Tom Anderson <twic@urchin.earth.li> - 2011-10-17 00:57 +0100
          Re: constructing a constant HashMap Patricia Shanahan <pats@acm.org> - 2011-10-17 01:02 +0100
        Re: constructing a constant HashMap Arne Vajhøj <arne@vajhoej.dk> - 2011-10-16 22:20 -0400
          Re: constructing a constant HashMap B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-17 21:35 -0400
            Re: constructing a constant HashMap Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-18 09:28 -0700
              Re: constructing a constant HashMap David Lamb <dalamb@cs.queensu.ca> - 2011-10-20 12:55 -0400
            Re: constructing a constant HashMap Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 16:16 -0500
              Re: constructing a constant HashMap Lew <lewbloch@gmail.com> - 2011-11-06 14:37 -0800
                Re: constructing a constant HashMap Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 18:00 -0500
                  Re: constructing a constant HashMap Ian Pilcher <arequipeno@gmail.com> - 2011-11-06 18:34 -0600
                    Re: constructing a constant HashMap Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 19:47 -0500
              Re: constructing a constant HashMap B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-11-07 12:23 -0500
      Re: constructing a constant HashMap Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-16 11:11 -0300
    Re: constructing a constant HashMap Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-16 10:39 -0700

Page 1 of 2  [1] 2  Next page →

#8844 — constructing a constant HashMap

What is your preferred way of building a HashMap when all the values
are known at compile time?
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [next] | [standalone]

#8845

On 10/15/2011 9:14 PM, Roedy Green wrote:
> What is your preferred way of building a HashMap when all the values
> are known at compile time?

new
multiple put's
Collection unmodifiableMap

and move on to something more important.

Arne

[toc] | [prev] | [next] | [standalone]

#8865

On 16/10/2011 03:36, Arne Vajhøj allegedly wrote:
> On 10/15/2011 9:14 PM, Roedy Green wrote:
>> What is your preferred way of building a HashMap when all the values
>> are known at compile time?
> 
> new
> multiple put's
> Collection unmodifiableMap
> 
> and move on to something more important.
> 
> Arne

+1

[toc] | [prev] | [next] | [standalone]

#8851

On 10/15/2011 6:14 PM, Roedy Green wrote:
> What is your preferred way of building a HashMap when all the values
> are known at compile time?


EnumMap is one possibility.

But I think the answer depends on how many values, how you intend to use 
them, efficiency concerns, how the values are "known," etc.

In other words, it depends on requirements.

[toc] | [prev] | [next] | [standalone]

#8853

On Sat, 15 Oct 2011 18:59:45 -0700, markspace <-@.> wrote, quoted or
indirectly quoted someone who said :

>EnumMap is one possibility.

what does your init code look like?
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [prev] | [next] | [standalone]

#8852

On Sat, 15 Oct 2011 18:14:13 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>What is your preferred way of building a HashMap when all the values
>are known at compile time?

I have posted some options at
http://mindprod.com/jgloss/hashmap.html#INITIALISATION
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [prev] | [next] | [standalone]

#8855

Roedy Green wrote:
> What is your preferred way of building a HashMap when all the values
> are known at compile time?

If the map is a field, I often use an instance or static initializer
immediately after the map's declaration:

Map<String,String> myMap = new HashMap<String,String>();
{
   myMap.put("aaa", "bbb");
   ...
}

Patricia

[toc] | [prev] | [next] | [standalone]

#8856

On 16/10/2011 1:07 AM, Patricia Shanahan wrote:
> Roedy Green wrote:
>> What is your preferred way of building a HashMap when all the values
>> are known at compile time?
>
> If the map is a field, I often use an instance or static initializer
> immediately after the map's declaration:
>
> Map<String,String> myMap = new HashMap<String,String>();
> {
> myMap.put("aaa", "bbb");
> ...
> }
>
> Patricia

This works in ANY setting where an expression of type Map<String,String> 
is appropriate:

new HashMap<String,String> () {
     {
         put("aaa", "bbb");
         ...
     }}

-- 
A fatal exception 0E has occurred at 0028:C0011E36 in VXD VMM(01)
00010E36. The current application will be terminated.

* Press any key to terminate the current application.

[toc] | [prev] | [next] | [standalone]

#8881

On Sun, 16 Oct 2011, B1ll Gat3s wrote:

> On 16/10/2011 1:07 AM, Patricia Shanahan wrote:
>> Roedy Green wrote:
>>> What is your preferred way of building a HashMap when all the values
>>> are known at compile time?
>> 
>> If the map is a field, I often use an instance or static initializer
>> immediately after the map's declaration:
>> 
>> Map<String,String> myMap = new HashMap<String,String>();
>> {
>> myMap.put("aaa", "bbb");
>> ...
>> }

For static final variables (suggested by "all the values are known at 
compile time"), i would suggest a slight variation:

static final Map<String,String> myMap;
static {
 	Map<String,String> tmpMap = new HashMap<String,String>();
 	tmpMap.put("aaa", "bbb");
 	myMap = Collections.unmodifiableMap(tmpMap);
}

> This works in ANY setting where an expression of type Map<String,String> is 
> appropriate:
>
> new HashMap<String,String> () {
>    {
>        put("aaa", "bbb");
>        ...
>    }}

This is called a 'double brace initializer', and it is a very useful but 
also highly surprising construct (i love dropping one in front of my pair 
when pair programming, and watching their brains trying to work out what's 
going on - it takes a while to realise it's not a special syntax, just a 
combination of two other bits of syntax). See:

http://c2.com/cgi/wiki?DoubleBraceInitialization

I use this form a lot in unit tests, when i need to set up a map quickly, 
but less so in 'real' code. It creates lots of anonymous subclasses, which 
i am nervous about doing.

tom

-- 
So the moon is approximately 24 toasters from Scunthorpe.

[toc] | [prev] | [next] | [standalone]

#8882

Tom Anderson wrote:
> On Sun, 16 Oct 2011, B1ll Gat3s wrote:
> 
>> On 16/10/2011 1:07 AM, Patricia Shanahan wrote:
>>> Roedy Green wrote:
>>>> What is your preferred way of building a HashMap when all the values
>>>> are known at compile time?
>>>
>>> If the map is a field, I often use an instance or static initializer
>>> immediately after the map's declaration:
>>>
>>> Map<String,String> myMap = new HashMap<String,String>();
>>> {
>>> myMap.put("aaa", "bbb");
>>> ...
>>> }
> 
> For static final variables (suggested by "all the values are known at 
> compile time"), i would suggest a slight variation:
> 
> static final Map<String,String> myMap;
> static {
>     Map<String,String> tmpMap = new HashMap<String,String>();
>     tmpMap.put("aaa", "bbb");
>     myMap = Collections.unmodifiableMap(tmpMap);
> }

Yes, that is indeed an improvement, given the lack of intent to modify
the map after its creation.

Patricia

[toc] | [prev] | [next] | [standalone]

#8892

On 10/16/2011 1:29 AM, B1ll Gat3s wrote:
> On 16/10/2011 1:07 AM, Patricia Shanahan wrote:
>> Roedy Green wrote:
>>> What is your preferred way of building a HashMap when all the values
>>> are known at compile time?
>>
>> If the map is a field, I often use an instance or static initializer
>> immediately after the map's declaration:
>>
>> Map<String,String> myMap = new HashMap<String,String>();
>> {
>> myMap.put("aaa", "bbb");
>> ...
>> }
>
> This works in ANY setting where an expression of type Map<String,String>
> is appropriate:
>
> new HashMap<String,String> () {
> {
> put("aaa", "bbb");
> ...
> }}

But it is way more difficult to read and therefore be more
costly to maintain.

Will most likely be slower and use more memory (for the class).

And it may break some code that does a bad test on class.

Not a very attractive solution.

Arne

[toc] | [prev] | [next] | [standalone]

#8936

On 16/10/2011 10:20 PM, Arne Vajhøj wrote:
> On 10/16/2011 1:29 AM, B1ll Gat3s wrote:
>> This works in ANY setting where an expression of type Map<String,String>
>> is appropriate:
>>
>> new HashMap<String,String> () {
>> {
>> put("aaa", "bbb");
>> ...
>> }}
>
> But it is way more difficult to read

No it isn't.

-- 
A fatal exception 0E has occurred at 0028:C0011E36 in VXD VMM(01)
00010E36. The current application will be terminated.

* Press any key to terminate the current application.

[toc] | [prev] | [next] | [standalone]

#8959

On 10/17/11 6:35 PM, B1ll Gat3s wrote:
> On 16/10/2011 10:20 PM, Arne Vajhøj wrote:
>> On 10/16/2011 1:29 AM, B1ll Gat3s wrote:
>>> This works in ANY setting where an expression of type Map<String,String>
>>> is appropriate:
>>>
>>> new HashMap<String,String> () {
>>> {
>>> put("aaa", "bbb");
>>> ...
>>> }}
>>
>> But it is way more difficult to read
>
> No it isn't.
>
That is opinion.

The syntax in question is a bit esoteric and would therefor have a 
greater potential to confuse maintainers with less experience.

Also, if someone doesn't think hard about what that really is doing, 
they may not fully understand the consequences of that approach.

The more I think about this "problem", the more I think that a 
properties file may be more appropriate than an "in code" solution for 
most cases.

[toc] | [prev] | [next] | [standalone]

#9037

On 18/10/2011 12:28 PM, Daniel Pitts wrote:
> The more I think about this "problem", the more I think that a
> properties file may be more appropriate than an "in code" solution for
> most cases.

I also think you're right -- there's a basic principle of "late binding" 
of decisions so they're easier to change, and "separation of concerns" 
(so, for example, you keep the code separate from its data).

[toc] | [prev] | [next] | [standalone]

#9677

On 10/17/2011 9:35 PM, B1ll Gat3s wrote:
> On 16/10/2011 10:20 PM, Arne Vajhøj wrote:
>> On 10/16/2011 1:29 AM, B1ll Gat3s wrote:
>>> This works in ANY setting where an expression of type Map<String,String>
>>> is appropriate:
>>>
>>> new HashMap<String,String> () {
>>> {
>>> put("aaa", "bbb");
>>> ...
>>> }}
>>
>> But it is way more difficult to read
>
> No it isn't.

Yes - it is.

Read what Tom wrote:

#and it is a very useful but also highly surprising construct (i love
#dropping one in front of my pair when pair programming, and watching
#their brains trying to work out what's going on - it takes a while to
#realise it's not a special syntax, just a combination of two other
#bits of syntax).

Arne

[toc] | [prev] | [next] | [standalone]

#9688

Arne Vajhøj wrote:
> B1ll Gat3s wrote:
>> Arne Vajhøj wrote:
>>> B1ll Gat3s wrote:
>>>> This works in ANY setting where an expression of type Map<String,String>
>>>> is appropriate:
>>>>
>>>> new HashMap<String,String> () {
>>>> {
>>>> put("aaa", "bbb");
>>>> ...
>>>> }}
>>>
>>> But it is way more difficult to read
>>
>> No it isn't.
>
> Yes - it is.
> 
> Read what Tom wrote:
> 
> #and it is a very useful but also highly surprising construct (i love
> #dropping one in front of my pair when pair programming, and watching
> #their brains trying to work out what's going on - it takes a while to
> #realise it's not a special syntax, just a combination of two other
> #bits of syntax).

Yeah, but once you're used to it it's quite readable.  So you're both right.

The question of "readability" shouldn't be treated like an absolute - it is or it ain't.  Readability is relative to experience and cognitive style.  To someone not trained in computer programmers, none of it is readable.  To a junior programmer, anonymous classes are rather "unreadable".  Should you eschew them for that reason?  To a slightly less junior programmer the anonymous-class/initializer combination cited here is strange, but should you really code to his level?  Or maybe should that programmer up their skill a little and stop being so namby-pamby about legitimate, useful syntax?

There's also a relative readability between that idiom and alternatives to load a Map.  There's gotta be an initializer somewhere, folks!

Personally, I don't like the overly-clever anonymous/initializer idiom.  I prefer a stodgy old separate initializer block and a non-subclasses HashMap.  I think it's more readable that way than the tricky subclass way presented here.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9695

On 11/6/2011 5:37 PM, Lew wrote:
> Arne Vajhøj wrote:
>> B1ll Gat3s wrote:
>>> Arne Vajhøj wrote:
>>>> B1ll Gat3s wrote:
>>>>> This works in ANY setting where an expression of type Map<String,String>
>>>>> is appropriate:
>>>>>
>>>>> new HashMap<String,String>  () {
>>>>> {
>>>>> put("aaa", "bbb");
>>>>> ...
>>>>> }}
>>>>
>>>> But it is way more difficult to read
>>>
>>> No it isn't.
>>
>> Yes - it is.
>>
>> Read what Tom wrote:
>>
>> #and it is a very useful but also highly surprising construct (i love
>> #dropping one in front of my pair when pair programming, and watching
>> #their brains trying to work out what's going on - it takes a while to
>> #realise it's not a special syntax, just a combination of two other
>> #bits of syntax).
>
> Yeah, but once you're used to it it's quite readable.  So you're both right.
>
> The question of "readability" shouldn't be treated like an absolute - it is or it ain't.  Readability is relative to experience and cognitive style.  To someone not trained in computer programmers, none of it is readable.  To a junior programmer, anonymous classes are rather "unreadable".  Should you eschew them for that reason?  To a slightly less junior programmer the anonymous-class/initializer combination cited here is strange, but should you really code to his level?  Or maybe should that programmer up their skill a little and stop being so namby-pamby about legitimate, useful syntax?
>
> There's also a relative readability between that idiom and alternatives to load a Map.  There's gotta be an initializer somewhere, folks!
>
> Personally, I don't like the overly-clever anonymous/initializer idiom.  I prefer a stodgy old separate initializer block and a non-subclasses HashMap.  I think it's more readable that way than the tricky subclass way presented here.

Readability is relative to the reader.

But let me rephrase to: this construct will puzzle significant
more developers than the other solutions suggested.

Arne

[toc] | [prev] | [next] | [standalone]

#9706

On 11/06/2011 05:00 PM, Arne Vajhøj wrote:
> But let me rephrase to: this construct will puzzle significant
> more developers than the other solutions suggested.

Since that seems to be the goal of so many developers, the "double
brace" solution is obviously the best.

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================

[toc] | [prev] | [next] | [standalone]

#9708

On 11/6/2011 7:34 PM, Ian Pilcher wrote:
> On 11/06/2011 05:00 PM, Arne Vajhøj wrote:
>> But let me rephrase to: this construct will puzzle significant
>> more developers than the other solutions suggested.
>
> Since that seems to be the goal of so many developers, the "double
> brace" solution is obviously the best.

Then the conclusion must be that there are too few axe murderers
around!

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#9748

On 06/11/2011 4:16 PM, Arne Vajhøj wrote:
> On 10/17/2011 9:35 PM, B1ll Gat3s wrote:
>> On 16/10/2011 10:20 PM, Arne Vajhøj wrote:
>>> On 10/16/2011 1:29 AM, B1ll Gat3s wrote:
>>>> new HashMap<String,String> () {
>>>> {
>>>> put("aaa", "bbb");
>>>> ...
>>>> }}
>>>
>>> But it is way more difficult to read
>>
>> No it isn't.
>
> Yes - it is.

No - it's not.

-- 
A fatal exception 0E has occurred at 0028:C0011E36 in VXD VMM(01)
00010E36. The current application will be terminated.

* Press any key to terminate the current application.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web