Expand your line wrap. The days of 80x25 are gone. ;-) And yes, Java
developers can read and understand
Map<String, Map<String, Callable<? extends Future<? extends
CharSequence>>>>callbacks = new HashMap<String, Map<String, Callable<?
extends Future<? extends CharSequence>>>>()
Ciao
Henning
2009/1/8 Kevin Brown <[email protected]>:
> On Thu, Jan 8, 2009 at 11:52 AM, Eric Tschetter <[email protected]> wrote:
>
>> >> I -1 this patch unless you can sufficiently explain why e.g.
>> >>
>> >>> - tokenData = new HashMap<String, String>(5,1);
>> >>> + tokenData = Maps.newHashMapWithExpectedSize(5);
>> >>
>> >> is better readable to someone with knowledge of the standard Java APIs
>> >> and no knowledge of Google Collections.
>> >
>> > Is it really that hard to understand? Really? Some Junior Devs looked
>> at
>> > that code and easily understood the intent.
>>
>> Did those Junior Devs also understand the initial incantation?
>>
>>
>> >> All that this huge patch IMHO does is making the code harder to read
>> >> for no particular reasons.
>> >
>> > There are reasons. In this case you use the factory methods to not repeat
>> > yourself. Consider the degenerate case:
>> >
>> > Map<Integer, List<Map<Foo,Bar>>> = new
>> > HashMap<Integer,List<Map<Foo,Bar>>>(5,1);
>> >
>> > you can replace the RHS with Maps.newHashMapWithExpectedSize(5)
>>
>> We are entering the realm of religious minutia here, but what is the
>> benefit of taking a mathematical language and replacing it with a
>> natural language? Sure, it makes sense for a small group of people
>> (i.e. internal/personal development) to create and introduce
>> "languages" that they find easier to understand, but when something is
>> being consumed by some unknown plurality, it doesn't make sense to
>> force that plurality to learn your way of doing things when there is a
>> common, accepted way of doing it that they will already know.
>
>
> I think you're missing the point. It's not about using 'natural' language,
> it's about reducing line length.
>
> Of course, in this particular case the line length argument doesn't hold
> because the second form is actually 1 character longer than the first.
> Unless you do a static import, new HashMap<String, String(5, 1); is shorter.
>
> It's really relevant in places where you see things like this:
>
> Map<String, Map<String, Callable<? extends Future<? extends CharSequence>>>>
> callbacks = new HashMap<String, Map<String, Callable<? extends Future<?
> extends CharSequence>>>>()
>
> vs.
>
> Map<String, Map<String, Callable<? extends Future<? extends CharSequence>>>>
> callbacks = Maps.newHashMap();
>
>
>
>>
>> In math, it doesn't make sense to replace ∏ with
>> "multiply-all-numbers-in-the-series" and ∑ with
>> "sum-all-numbers-in-the-series", because the symbols are a part of the
>> "universal" mathematical language. People who understand math will
>> understand the symbols. Switching the names to
>> "multiply-all-numbers-in-the-series" might work well for introducing
>> English speakers to the idea of ∏, but it will do very little for
>> anyone who doesn't speak English. While it's probably true that
>> English permeates Java enough that anyone who can program Java has at
>> least some understanding of English, I don't know why replacing the
>> instantiation of a HashMap with a more flowing, "natural" English
>> method call (i.e. replacing a mathematical language with natural
>> language) is beneficial in an open source project.
>>
>> Of course, if the object it creates isn't just a Java HashMap<...>,
>> then the change isn't related to language but to the actual runtime
>> properties of the system. My understanding, however, is that the Maps
>> method above is just a wrapper around "new HashMap<...>()"
>>
>> --Eric
>>
>
