Home > Archive > Java Help > September 2006 > typesafe java.util.Map construction and initialization
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
typesafe java.util.Map construction and initialization
|
|
| Josef Svitak 2006-09-19, 7:05 pm |
| If I have:
public class foo {
private interface BarIF { }
private class BarImplOne implements BarIF { public BarImplOne() {} }
private class BarImplTwo implements BarIF { public BarImplTwo() {} }
private java.lang.String keys[] = { "key1", "key2" };
private final bars[] = { new BarImplOne(), new BarImplTwo() };
private final java.util.Map<String, BarIF> theMap;
public foo() {
// Can I do this... (doesn't work)
theMap = new java.util.HashMap( keys, bars );
// instead of this? (works)
theMap.add( "key1", new BarImplOne() );
}
javac complains of not having a ctor for HashMap(String[], BarIF[]).
josef
| |
| Tor Iver Wilhelmsen 2006-09-19, 7:05 pm |
| Josef Svitak <jsvitak@gmail.com> writes:
> // Can I do this... (doesn't work)
> theMap = new java.util.HashMap( keys, bars );
No, there is no auto-fill constructor. Use
theMap = new java.util.HashMap<String,BarIF>();
assert(keys.length == bars.length);
for (int i = 0; i < keys.length; i++) {
theMap.put(keys[i], bars[i]);
}
| |
|
| > Josef Svitak <jsvitak@gmail.com> writes:
>
Tor Iver Wilhelmsen wrote:[color=darkred]
> No, there is no auto-fill constructor. Use
>
> theMap = new java.util.HashMap<String,BarIF>();
> assert(keys.length == bars.length);
> for (int i = 0; i < keys.length; i++) {
> theMap.put(keys[i], bars[i]);
> }
The assert is only useful if the keys and bars arrays are under the control of
the class, not parameters passed from the outside. Asserts enforce provable
conditions in an algorithm, and are not suitable for, e.g., argument checking.
In other words, the assert makes sense if it enforces that your own code has
already guaranteed that the lengths are equal.
As part of a short newsgroup example, the assert lets you know that you should
have guaranteed the condition - i.e., the poster is warning you to make sure
the assert holds, not suggesting that you use assert to check that the lengths
are equal.
http://java.sun.com/j2se/1.4.2/docs...ang/assert.html
- Lew
| |
| Josef Svitak 2006-09-21, 10:01 pm |
| Tor Iver Wilhelmsen wrote:
> Josef Svitak <jsvitak@gmail.com> writes:
>
>
> No, there is no auto-fill constructor. Use
>
> theMap = new java.util.HashMap<String,BarIF>();
> assert(keys.length == bars.length);
> for (int i = 0; i < keys.length; i++) {
> theMap.put(keys[i], bars[i]);
> }
I thought I had seen a ctor with 2 Strings work but, looking more
closely, I see it was local to the application.
Thanks,
josef
| |
| Josef Svitak 2006-09-21, 10:01 pm |
| Lew wrote:
>
> Tor Iver Wilhelmsen wrote:
>
> The assert is only useful if the keys and bars arrays are under the
> control of the class, not parameters passed from the outside. Asserts
> enforce provable conditions in an algorithm, and are not suitable for,
> e.g., argument checking.
Given that the arrays _are_ under control of the class, is it true that
the assert should appear as early as possible in the object
construction? This class is actually a singleton (not as shown in OP)
so theMap must be initialized lazily during the call to getInstance, but
I suspect the assert should appear in the foo() ctor of which theMap is
a part.
-josef
>
> In other words, the assert makes sense if it enforces that your own code
> has already guaranteed that the lengths are equal.
>
> As part of a short newsgroup example, the assert lets you know that you
> should have guaranteed the condition - i.e., the poster is warning you
> to make sure the assert holds, not suggesting that you use assert to
> check that the lengths are equal.
>
> http://java.sun.com/j2se/1.4.2/docs...ang/assert.html
>
> - Lew
| |
|
| >>
[color=darkred]
> Lew wrote:
Josef Svitak wrote:[color=darkred]
> Given that the arrays _are_ under control of the class, is it true that
> the assert should appear as early as possible in the object
> construction? This class is actually a singleton (not as shown in OP)
> so theMap must be initialized lazily during the call to getInstance, but
> I suspect the assert should appear in the foo() ctor of which theMap is
> a part.
The 'assert' should appear at a point in the code where you can prove that the
arrays are of equal length and before different lengths would mess up the
algorithm. It is possible that this particular assertion could occur at the
end of your constructor as a postcondition; without knowing your constructor
there is no way for me to know.
Generally, assertions should appear at points of invariant conditions in your
algorithm, such as preconditions and postconditions. As an example, if one
were calculating a square root of a value 'val', the assertion
assert val >= 0;
should occur after the code that guarantees that val is non-negative and
before the square root calculation.
There are some tricky specialized uses of the 'assert' keyword as well.
Assertions are *not* a runtime check mechanism; that's the purview of
Exceptions, if (...) statements and so forth. Assertions are an
algorithm-proving mechanism.
Read the Sun article; it covers several important points, including that the
program cannot count on assertions being enabled at runtime. Check around for
general information on algorithm invariants also.
[color=darkred]
- Lew
|
|
|
|
|