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

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

Immutable Datastructures with good Sharing

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

Contents

  Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 04:03 +0100
    Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 12:42 +0100
      Re: Immutable Datastructures with good Sharing markspace <-@.> - 2011-11-05 09:35 -0700
        Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 19:33 +0100
          Re: Immutable Datastructures with good Sharing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 14:42 -0400
            Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 19:52 +0100
              Re: Immutable Datastructures with good Sharing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-05 19:32 +0000
              Re: Immutable Datastructures with good Sharing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 15:31 -0400
                Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 20:50 +0100
                  Re: Immutable Datastructures with good Sharing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 16:26 -0400
                    Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 21:35 +0100
                      Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 21:38 +0100
                        Re: Immutable Datastructures with good Sharing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 16:59 -0400
                          Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 22:06 +0100
                      Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-05 16:41 -0400
                        Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 21:42 +0100
                    Re: Immutable Datastructures with good Sharing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 17:11 -0400
              Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-05 16:20 -0400
                Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 21:33 +0100
                  Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-05 16:38 -0400
                    Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 21:41 +0100
                      Re: Immutable Datastructures with good Sharing markspace <-@.> - 2011-11-05 17:20 -0700
                        Re: Immutable Datastructures with good Sharing Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-05 22:13 -0300
                          Re: Immutable Datastructures with good Sharing markspace <-@.> - 2011-11-05 20:05 -0700
                            Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 10:27 +0100
                        Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 10:14 +0100
      Re: Immutable Datastructures with good Sharing Lew <lewbloch@gmail.com> - 2011-11-05 10:06 -0700
        Re: Immutable Datastructures with good Sharing Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-11-05 10:55 -0700
          Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 19:30 +0100
            Re: Immutable Datastructures with good Sharing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 18:16 -0400
              Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 23:20 +0100
              Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 23:38 +0100
          Re: Immutable Datastructures with good Sharing Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-05 17:47 -0300
          Re: Immutable Datastructures with good Sharing Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-11-05 14:26 -0700
        Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-05 16:14 -0400
    Re: Immutable Datastructures with good Sharing Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-11-05 14:35 -0700
      Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 22:42 +0100
        Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 22:50 +0100
        Re: Immutable Datastructures with good Sharing Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-11-05 14:51 -0700
          Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 22:58 +0100
            Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 23:03 +0100
              Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-05 23:07 +0100
              Re: Immutable Datastructures with good Sharing Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-11-06 09:44 +0200
                Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 10:22 +0100
                  Re: Immutable Datastructures with good Sharing Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-06 09:05 -0400
                    Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 14:16 +0100
                    Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 14:22 +0100
                      Re: Immutable Datastructures with good Sharing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-06 14:30 +0000
                        Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 16:02 +0100
                        Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 16:08 +0100
                        Re: Immutable Datastructures with good Sharing Giovanni Azua <bravegag@hotmail.com> - 2011-11-06 16:18 +0100
                          Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 16:54 +0100
                            Re: Immutable Datastructures with good Sharing Giovanni Azua <bravegag@hotmail.com> - 2011-11-06 17:31 +0100
                              Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 22:33 +0100
                                Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 16:47 -0500
                          Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-06 16:58 +0100
                            Re: Immutable Datastructures with good Sharing Tom Anderson <twic@urchin.earth.li> - 2011-11-07 01:01 +0000
                              Re: Immutable Datastructures with good Sharing Lew <lewbloch@gmail.com> - 2011-11-06 17:26 -0800
                                Re: Immutable Datastructures with good Sharing Tom Anderson <twic@urchin.earth.li> - 2011-11-07 23:45 +0000
                          Re: Immutable Datastructures with good Sharing Lew <lewbloch@gmail.com> - 2011-11-06 14:44 -0800
                            Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 17:51 -0500
                            Re: Immutable Datastructures with good Sharing Giovanni Azua <bravegag@hotmail.com> - 2011-11-07 01:28 +0100
                              Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 19:50 -0500
                                Re: Immutable Datastructures with good Sharing Giovanni Azua <bravegag@hotmail.com> - 2011-11-07 02:13 +0100
                                  Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 20:20 -0500
                              Re: Immutable Datastructures with good Sharing Lew <lewbloch@gmail.com> - 2011-11-06 17:29 -0800
                                Re: Immutable Datastructures with good Sharing Giovanni Azua <bravegag@hotmail.com> - 2011-11-07 11:22 +0100
                          Re: Immutable Datastructures with good Sharing Tom Anderson <twic@urchin.earth.li> - 2011-11-06 23:02 +0000
                            Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-07 00:32 +0100
                              Re: Immutable Datastructures with good Sharing Giovanni Azua <bravegag@hotmail.com> - 2011-11-07 01:10 +0100
                                Re: Immutable Datastructures with good Sharing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-07 10:24 +0000
                                  Re: Immutable Datastructures with good Sharing Giovanni Azua <bravegag@hotmail.com> - 2011-11-07 11:52 +0100
                                    Re: Immutable Datastructures with good Sharing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-07 11:12 +0000
                                    Re: Immutable Datastructures with good Sharing Arne Vajhøj <arne@vajhoej.dk> - 2011-11-07 17:24 -0500
                            Re: Immutable Datastructures with good Sharing Giovanni Azua <bravegag@hotmail.com> - 2011-11-07 02:08 +0100
                              Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-07 05:03 +0100
                                Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-07 05:13 +0100
                              Re: Immutable Datastructures with good Sharing Tom Anderson <twic@urchin.earth.li> - 2011-11-07 23:38 +0000
                                Re: Immutable Datastructures with good Sharing Tom Anderson <twic@urchin.earth.li> - 2011-11-09 22:06 +0000
                                  Re: Immutable Datastructures with good Sharing Gene Wirchenko <genew@ocis.net> - 2011-11-09 18:02 -0800
    Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-07 00:28 +0100
      Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-07 00:39 +0100
        Re: Immutable Datastructures with good Sharing Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-06 20:57 -0400
          Re: Immutable Datastructures with good Sharing Jan Burse <janburse@fastmail.fm> - 2011-11-07 04:58 +0100
            Re: Immutable Datastructures with good Sharing Silvio Bierman <silvio@moc.com> - 2011-11-07 15:13 +0100
              Re: Immutable Datastructures with good Sharing Cthun <cthun_202@qmail.net.au> - 2011-11-07 12:54 -0500
                Re: Immutable Datastructures with good Sharing "B1ll Gat3s" <wm.g4t3s@m1cr0s0f7.c0m> - 2011-11-07 18:07 -0500
                  Re: Immutable Datastructures with good Sharing B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-11-07 22:07 -0500
                    Re: Immutable Datastructures with good Sharing "B1ll Gat3s" <wm.g4t3s@m1cr0s0f7.c0m> - 2011-11-08 00:17 -0500
                      Re: Immutable Datastructures with good Sharing thoolen <th00len@th0lenbot.thorium> - 2011-11-08 16:03 -0500
                  Re: Immutable Datastructures with good Sharing Cthun <cthun_202@qmail.net.au> - 2011-11-08 15:49 -0500
                    Re: Immutable Datastructures with good Sharing "B1ll Gat3s" <wm.g4t3s@m1cr0s0f7.c0m> - 2011-11-08 18:01 -0500
                      Re: Immutable Datastructures with good Sharing thoolen <th00len@th0lenbot.thorium> - 2011-11-08 20:46 -0500
                        Re: Immutable Datastructures with good Sharing "Cthun" <cthun_202@qmail.net.au> - 2011-11-08 22:43 -0500
                          Re: Immutable Datastructures with good Sharing thoolen <th00len@th0lenbot.thorium> - 2011-11-09 08:28 -0500
                  Re: Immutable Datastructures with good Sharing thoolen <th00len@th0lenbot.thorium> - 2011-11-08 16:00 -0500
    Re: Immutable Datastructures with good Sharing Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-07 08:46 -0800

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#9693

On 11/6/2011 5:44 PM, Lew wrote:
> Giovanni Azua wrote:
>> I haven't read/followed the whole OP Thread discussion but I thought it was
>> worth mentioning/recommending the Google "Guava Project":
>> http://code.google.com/p/guava-libraries/
>>
>> I think they really "went to town" on that one. You have strongly typed
>> Immutable Collection definitions for all Java Collection types e.g.
>> ImmutableMap.Builder, ImmutableList.Builder. The design is awesome e.g. the
>> Builder pattern as prescribed in Effective Java (last edition) and the
>> performance gains are noticeable as well e.g. In a distributed system I have
>> been working on lately, switching the attribute instances of the DTO Beans
>> from ArrayList Java Collection to use instead the implementation from Guava
>> gave some noticeable 15-20% Serialization performance gain e.g. Test case
>> involving 1-Echo-Server and 1K-Clients.
>>
>> I really enjoy the improvement in code readability as well, it suits the
>> appropriate template types e.g.
>>
>> // from
>> List<RequestData>  requests = new ArrayList<RequestData>();
>>
>> // to
>> List<RequestData>  requests = Lists.newArrayList();
>>
>> Guava really rocks! Would this be the Java Collections design debt now
>> finally paid by Joshua Bloch?
>
> I'm not saying anything against Guava, but I fail to see the advantage of that particular idiom.  'Lists.newArrayList' vs. 'new ArrayList<>' - eh, mezza mezz'.
>
> Whatever floats your boat.

I guess it is Block consider factory over constructor.

But I om with you on this one.

I don't understand this weird trend to try and write "new free"
code.

Arne

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

#9705

Hi Lew,

On 11/6/11 11:44 PM, in article
16628826.552.1320619468157.JavaMail.geo-discussion-forums@prlm15, "Lew"
<lewbloch@gmail.com> wrote:
>> I really enjoy the improvement in code readability as well, it suits the
>> appropriate template types e.g.
>> 
>> // from
>> List<RequestData> requests = new ArrayList<RequestData>();
>> 
>> // to
>> List<RequestData> requests = Lists.newArrayList();
>> 
> 
> I'm not saying anything against Guava, but I fail to see the advantage of that
> particular idiom.  'Lists.newArrayList' vs. 'new ArrayList<>' - eh, mezza
> mezz'.
> 
I don't blame you. I had the same resistant first reaction when I was
proposed to use Guava. Then something magical happened :) I realized that
when you use new with Collections, generally you have to tell the compiler
two times what you want namely the generic parameter. I think that having to
do the same thing two times in development is always a bad thing: two times
harder to maintain, two times the amount of possible mistakes and in short,
two times the amount of work.

// two times having to type RequestData ... no big deal
List<RequestData> requests = new ArrayList<RequestData>();

// making the problem more explicit ...
List<Map<TpchWorkload,Map<String,List<Object>>>> parameters = new
ArrayList<Map<TpchWorkload,Map<String,List<Object>>>>();

// simply beautiful
List<Map<TpchWorkload,Map<String,List<Object>>>> parameters =
Lists.newArrayList();

Now tell me, how much time have you spent in your life fixing the small
mistakes that originate from getting the LHS out of sync with the RHS? This
alone is one of those small details that make your daily development work
enjoyable rather than painful.

Guava rocks!

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

#9709

On 11/6/2011 7:28 PM, Giovanni Azua wrote:
> On 11/6/11 11:44 PM, in article
> 16628826.552.1320619468157.JavaMail.geo-discussion-forums@prlm15, "Lew"
> <lewbloch@gmail.com>  wrote:
>>> I really enjoy the improvement in code readability as well, it suits the
>>> appropriate template types e.g.
>>>
>>> // from
>>> List<RequestData>  requests = new ArrayList<RequestData>();
>>>
>>> // to
>>> List<RequestData>  requests = Lists.newArrayList();
>>>
>>
>> I'm not saying anything against Guava, but I fail to see the advantage of that
>> particular idiom.  'Lists.newArrayList' vs. 'new ArrayList<>' - eh, mezza
>> mezz'.
>>
> I don't blame you. I had the same resistant first reaction when I was
> proposed to use Guava. Then something magical happened :) I realized that
> when you use new with Collections, generally you have to tell the compiler
> two times what you want namely the generic parameter. I think that having to
> do the same thing two times in development is always a bad thing: two times
> harder to maintain, two times the amount of possible mistakes and in short,
> two times the amount of work.
>
> // two times having to type RequestData ... no big deal
> List<RequestData>  requests = new ArrayList<RequestData>();
>
> // making the problem more explicit ...
> List<Map<TpchWorkload,Map<String,List<Object>>>>  parameters = new
> ArrayList<Map<TpchWorkload,Map<String,List<Object>>>>();
>
> // simply beautiful
> List<Map<TpchWorkload,Map<String,List<Object>>>>  parameters =
> Lists.newArrayList();
>
> Now tell me, how much time have you spent in your life fixing the small
> mistakes that originate from getting the LHS out of sync with the RHS? This
> alone is one of those small details that make your daily development work
> enjoyable rather than painful.
>
> Guava rocks!

That particular argument is somewhat obsolete with Java 1.7.

And I am not so sure that avoiding typing is a good goal in
programming, but that is a different discussion.

Arne

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

#9715

On 11/7/11 1:50 AM, in article 4eb72b3a$0$285$14726298@news.sunsite.dk,
"Arne Vajhøj" <arne@vajhoej.dk> wrote:
> That particular argument is somewhat obsolete with Java 1.7.
>
I haven't looked into Java 1.7 yet, enlighten me please? :)
 
> And I am not so sure that avoiding typing is a good goal in
> programming, but that is a different discussion.
> 
I was referring to doing/specifying the same thing twice which is not the
same thing as avoiding typing.

The whole point is not avoid typing but:
1) avoid specifying the same thing twice
2) avoid making mistakes
3) while at it, having the code a lot more readable.
4) easier to maintain e.g. changing N declarations once rather than 2*N

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

#9716

On 11/6/2011 8:13 PM, Giovanni Azua wrote:
>
> On 11/7/11 1:50 AM, in article 4eb72b3a$0$285$14726298@news.sunsite.dk,
> "Arne Vajhøj"<arne@vajhoej.dk>  wrote:
>> That particular argument is somewhat obsolete with Java 1.7.
>>
> I haven't looked into Java 1.7 yet, enlighten me please? :)

Java 1.7 support:

         List<String> list = new ArrayList<>();
         Map<String,String> map = new HashMap<>();

Arne

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

#9720

Giovanni Azua wrote:
> Lew wrote:
>> Giovanni Azua wrote:
>>> I really enjoy the improvement in code readability as well, it suits the
>>> appropriate template types e.g.
>>> 
>>> // from
>>> List<RequestData> requests = new ArrayList<RequestData>();
>>> 
>>> // to
>>> List<RequestData> requests = Lists.newArrayList();
>>> 
>> 
>> I'm not saying anything against Guava, but I fail to see the advantage of that
>> particular idiom.  'Lists.newArrayList' vs. 'new ArrayList<>' - eh, mezza
>> mezz'.
>> 
> I don't blame you. I had the same resistant first reaction when I was
> proposed to use Guava. Then something magical happened :) I realized that
> when you use new with Collections, generally you have to tell the compiler
> two times what you want namely the generic parameter. I think that having to
> do the same thing two times in development is always a bad thing: two times
> harder to maintain, two times the amount of possible mistakes and in short,
> two times the amount of work.

The diamond operator mitigates that, and the two characters of it are smaller than the overhead of pulling in a whole other class.

I think pulling in a whole utility class at runtime because you're too lazy to type two extra characters, or even a dozen, is silly.  Roofers are laughing at your idea of too much work.

But that's just me.

-- 
Lew

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

#9730

On 11/7/11 2:29 AM, in article
9709923.273.1320629370704.JavaMail.geo-discussion-forums@prhp27, "Lew"
<lewbloch@gmail.com> wrote:
>> I don't blame you. I had the same resistant first reaction when I was
>> proposed to use Guava. Then something magical happened :) I realized that
>> when you use new with Collections, generally you have to tell the compiler
>> two times what you want namely the generic parameter. I think that having to
>> do the same thing two times in development is always a bad thing: two times
>> harder to maintain, two times the amount of possible mistakes and in short,
>> two times the amount of work.
> 
> The diamond operator mitigates that, and the two characters of it are smaller
> than the overhead of pulling in a whole other class.
>
Excellent, same idea but built in the language doesn't seem such a silly
concept after all.
 
> I think pulling in a whole utility class at runtime because you're too lazy to
> type two extra characters, or even a dozen, is silly.  Roofers are laughing at
> your idea of too much work.
>
When I start using 1.7 then the utility is not needed anymore but you failed
to realize the advantage and then you laugh? I laughed too but more about
your ignorance :) 

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

#9696

On Sun, 6 Nov 2011, Giovanni Azua wrote:

> I haven't read/followed the whole OP Thread discussion but I thought it was
> worth mentioning/recommending the Google "Guava Project":
> http://code.google.com/p/guava-libraries/
>
> I think they really "went to town" on that one. You have strongly typed 
> Immutable Collection definitions for all Java Collection types e.g. 
> ImmutableMap.Builder, ImmutableList.Builder.

If you had read the whole thread, or indeed just the OP's initial post, 
you would understand that these classes are not helpful. They are 
certainly immutable, they don't have the sharing properties that Jan is 
after. They also don't expose any methods for doing the quasi-mutation he 
needs to do.

To recap, Jan wants to be able to say:

ImmutableStack<String> a = new ImmutableStack<String>(); // empty
ImmutableStack<String> b = a.push("foo");
assert a.isEmpty();
assert b.size() == 1;

That is, the quasi-mutation creates a new instance exhibiting the change, 
rather than changing an existing instance.

The Guava Immutable* classes do not have such methods.

> The design is awesome e.g. the Builder pattern as prescribed in 
> Effective Java (last edition)

I find the builder pattern immensely annoying, myself.

> and the performance gains are noticeable as well e.g. In a distributed 
> system I have been working on lately, switching the attribute instances 
> of the DTO Beans from ArrayList Java Collection to use instead the 
> implementation from Guava gave some noticeable 15-20% Serialization 
> performance gain e.g. Test case involving 1-Echo-Server and 1K-Clients.

That is a respectable gain!

> I really enjoy the improvement in code readability as well, it suits the
> appropriate template types e.g.
>
> // from
> List<RequestData> requests = new ArrayList<RequestData>();
>
> // to
> List<RequestData> requests = Lists.newArrayList();

I see absolutely no improvement in the code here, only unhelpful 
obfuscation.

tom

-- 
Taking care of business

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

#9701

Tom Anderson schrieb:
> I see absolutely no improvement in the code here, only unhelpful
> obfuscation.

I guess it requires JDK 1.7 or so for the parameter
type inference. Not sure, picked something up like
that...

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

#9704

On 11/7/11 12:32 AM, in article j975e4$t80$2@news.albasani.net, "Jan Burse"
<janburse@fastmail.fm> wrote:

> Tom Anderson schrieb:
>> I see absolutely no improvement in the code here, only unhelpful
>> obfuscation.
> 
> I guess it requires JDK 1.7 or so for the parameter
> type inference. Not sure, picked something up like
> that...
> 
Nop, it doesn't need 1.7. I can confirm it works just fine with JDK 1.6.x

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

#9731

Giovanni Azua <bravegag@hotmail.com> wrote:
> On 11/7/11 12:32 AM, in article j975e4$t80$2@news.albasani.net, "Jan Burse"
><janburse@fastmail.fm> wrote:
>> Tom Anderson schrieb:
>>> I see absolutely no improvement in the code here, only unhelpful
>>> obfuscation.
>> I guess it requires JDK 1.7 or so for the parameter
>> type inference. Not sure, picked something up like
>> that...
> Nop, it doesn't need 1.7. I can confirm it works just fine with JDK 1.6.x

Generic type inference has been done in two steps:
 - for static methods in 1.6
 - for instance creation (i.e. "new ...") in 1.7

If you're stuck to 1.6 now, there might be some temptation to resort
to tricks for gaining generic type inference even for the second, but
be aware, that this is not exactly a "future investment" for the
maintainability of your code.

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

#9735

On 11/7/11 11:24 AM, in article slrnjbfceh.fvg.avl@gamma.logic.tuwien.ac.at,
"Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> wrote:
> If you're stuck to 1.6 now, there might be some temptation to resort
> to tricks for gaining generic type inference even for the second, but
> be aware, that this is not exactly a "future investment" for the
> maintainability of your code.
>
Am I stuck to 1.6? static methods with generics in Java 1.6 is a "trick" and
obsolete in 1.7?

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

#9737

Giovanni Azua <bravegag@hotmail.com> wrote:
> On 11/7/11 11:24 AM, in article slrnjbfceh.fvg.avl@gamma.logic.tuwien.ac.at,
> "Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> wrote:
>> If you're stuck to 1.6 now, there might be some temptation to resort
>> to tricks for gaining generic type inference even for the second, but
>> be aware, that this is not exactly a "future investment" for the
>> maintainability of your code.
> Am I stuck to 1.6?

I'd expect you to know. ;-)   (surely, "if X ..." doesn't mean to imply X)
If you're not, then my advice would be to use 1.7 and use
 "new Foobar<>(...)" instead of some static newFoobar(...).

> static methods with generics in Java 1.6 is a "trick" and
> obsolete in 1.7?

Static methods that do nothing but wrap a "new ..." for the
sole reason of saving retyping of generic parameters, that is.
Yes, I'd call those obsolete in 1.7  - "obsolete" in the same way
as an eventually self-written type-safe IntegerList back in 1.4 days
is meanwhile obsoleted by 1.5's generic List.

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

#9752

On 11/7/2011 5:52 AM, Giovanni Azua wrote:
> On 11/7/11 11:24 AM, in article slrnjbfceh.fvg.avl@gamma.logic.tuwien.ac.at,
> "Andreas Leitgeb"<avl@gamma.logic.tuwien.ac.at>  wrote:
>> If you're stuck to 1.6 now, there might be some temptation to resort
>> to tricks for gaining generic type inference even for the second, but
>> be aware, that this is not exactly a "future investment" for the
>> maintainability of your code.
>>
> Am I stuck to 1.6? static methods with generics in Java 1.6 is a "trick" and
> obsolete in 1.7?

Unless that static factory does more than just new, then I
would consider it "old style" with "new style" being
the 1.7 diamond operator.

What exactly the difference if any between "old style" and
"obsolete" is somewhat subjective.

Arne

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

#9714

On 11/7/11 12:02 AM, in article
alpine.DEB.2.00.1111062256510.4201@urchin.earth.li, "Tom Anderson"
<twic@urchin.earth.li> wrote:
> If you had read the whole thread, or indeed just the OP's initial post,
> you would understand that these classes are not helpful. They are
>
Indeed it was a lucky shot but read on ...

> To recap, Jan wants to be able to say:
> 
> ImmutableStack<String> a = new ImmutableStack<String>(); // empty
> ImmutableStack<String> b = a.push("foo");
> assert a.isEmpty();
> assert b.size() == 1;
> 
> That is, the quasi-mutation creates a new instance exhibiting the change,
> rather than changing an existing instance.
> 
> The Guava Immutable* classes do not have such methods.
> 
Would this check the box?

ImmutableMap<String, Integer> a = ImmutableMap.of("A", 1, "B", 2, "C", 3);
ImmutableMap<String, Integer> b =
     new ImmutableMap.Builder<String, Integer>().
          putAll(a).put("D", 4).build();


>> I really enjoy the improvement in code readability as well, it suits the
>> appropriate template types e.g.
>> 
>> // from
>> List<RequestData> requests = new ArrayList<RequestData>();
>> 
>> // to
>> List<RequestData> requests = Lists.newArrayList();
> 
> I see absolutely no improvement in the code here, only unhelpful
> obfuscation.
> 
When you say it like this, any function can be labeled as "unhelpful
obfuscation" :)

Giovanni

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

#9725

Giovanni Azua schrieb:
> Would this check the box?
>
> ImmutableMap<String, Integer>  a = ImmutableMap.of("A", 1, "B", 2, "C", 3);
> ImmutableMap<String, Integer>  b =
>       new ImmutableMap.Builder<String, Integer>().
>            putAll(a).put("D", 4).build();

I guess the putAll() results in cloning, therefore
no good sharing, therefore not a solution to the
problem at hand.

But I might be wrong.

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

#9726

Jan Burse schrieb:
> I guess the putAll() results in cloning, therefore
> no good sharing, therefore not a solution to the
> problem at hand.
>
> But I might be wrong.
>
>

Yep it is of no use.

First we have behind newArrayList the following:

   public static <E> ArrayList<E> newArrayList() {
     return new ArrayList<E>();
   }

 
http://code.google.com/p/google-collections/source/browse/trunk/src/com/google/common/collect/Lists.java

Then we have behind put and putAll():

     public static class Builder<K, V> {
        final List<Entry<K, V>> entries = Lists.newArrayList();

        public Builder<K, V> put(K key, V value) {
           entries.add(entryOf(key, value));
           return this;
        }

        public Builder<K, V> putAll(Map<? extends K, ? extends V> map) {
           for (Entry<? extends K, ? extends V> entry : map.entrySet()) {
             put(entry.getKey(), entry.getValue());
           }
           return this;
        }

 
http://www.docjar.com/html/api/com/google/inject/internal/ImmutableMap.java.html

So the whole thing, in version 1.0, doesn't make
much sense, except that it has the label
Google on it.

Bye

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

#9756

[Multipart message — attachments visible in raw view] — view raw

On Mon, 7 Nov 2011, Giovanni Azua wrote:

> On 11/7/11 12:02 AM, in article
> alpine.DEB.2.00.1111062256510.4201@urchin.earth.li, "Tom Anderson"
> <twic@urchin.earth.li> wrote:
>
>>> I really enjoy the improvement in code readability as well, it suits the
>>> appropriate template types e.g.
>>>
>>> // from
>>> List<RequestData> requests = new ArrayList<RequestData>();
>>>
>>> // to
>>> List<RequestData> requests = Lists.newArrayList();
>>
>> I see absolutely no improvement in the code here, only unhelpful
>> obfuscation.
>
> When you say it like this, any function can be labeled as "unhelpful 
> obfuscation" :)

Touché! I would agree that any function is obfuscation; whether it is 
helpful or unhelpful obfuscation varies.

tom

-- 
There is no violence or enmity in the LEGO universe until you, the
builder, decide what to build with the pieces. -- Pyrogenic

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

#9805

[Multipart message — attachments visible in raw view] — view raw

On Tue, 8 Nov 2011, Stefan Ram wrote:

> Supersedes: <obfuscation-20111108031530@ram.dialup.fu-berlin.de>
>
> Tom Anderson <twic@urchin.earth.li> writes:
>
>> Touché! I would agree that any function is obfuscation; whether it is
>> helpful or unhelpful obfuscation varies.
>
>  A well-known function name is not obfuscation, for example,
>
> y = sin x,
>
>  compared to
>
> y = uht x

It *is* obfuscation, because you can't look at that statement and 
immediately see what it does. You rely on your general knowledge of the 
sine function - and of what angle unit this particular implementation 
happens to be using, what it does for out-of-range values, and so on. I 
would readily agree that calling it uht would make it even more mysterious 
to an oligolingual programmer such as myself, but the fact is that hiding 
the implementation behind any name is obfuscation.

The point is that obfuscation is not necessarily a bad thing! It's just 
that when we think it's a good thing, we tend to call it 'encapsulation'.

tom

-- 
The trouble with eating German cuisine is that 3 days later, you are
hungry again! -- Graham, uk.food+drink.misc

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

#9812

On Wed, 9 Nov 2011 22:06:46 +0000, Tom Anderson <twic@urchin.earth.li>
wrote:

[snip]

>The point is that obfuscation is not necessarily a bad thing! It's just 
>that when we think it's a good thing, we tend to call it 'encapsulation'.

     The two are not the same.  Making something more difficult to
understand is not the same as hiding it.

Sincerely,

Gene Wirchenko

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web