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

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

generics puzzle

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

Contents

  generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-17 10:41 +0000
    Re: generics puzzle Steven Simpson <ss@domain.invalid> - 2011-10-17 13:14 +0100
      Re: generics puzzle Tom Anderson <twic@urchin.earth.li> - 2011-10-17 15:14 +0100
      Re: generics puzzle markspace <-@.> - 2011-10-17 07:33 -0700
        Re: generics puzzle Steven Simpson <ss@domain.invalid> - 2011-10-17 16:26 +0100
          Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-18 14:48 +0000
        Re: generics puzzle Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-17 15:36 +0000
      Re: generics puzzle Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-17 08:58 -0700
        Re: generics puzzle Steven Simpson <ss@domain.invalid> - 2011-10-18 10:45 +0100
          Re: generics puzzle Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-18 09:42 -0700
            Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-19 13:25 +0000
              Re: generics puzzle Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-19 10:04 -0700
                Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-20 14:14 +0000
                  Re: generics puzzle Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-20 11:11 -0700
    Re: generics puzzle Robert Klemme <shortcutter@googlemail.com> - 2011-10-17 09:12 -0700
      Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-18 14:49 +0000
        Re: generics puzzle Robert Klemme <shortcutter@googlemail.com> - 2011-10-18 18:27 +0200
          Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-18 17:45 +0000
            Re: generics puzzle Robert Klemme <shortcutter@googlemail.com> - 2011-10-18 22:15 +0200
            Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-18 18:59 -0700
              Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-19 13:28 +0000
                Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-20 17:21 -0700
                  Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-21 16:27 +0000
                    Re: generics puzzle Robert Klemme <shortcutter@googlemail.com> - 2011-10-21 20:34 +0200
                      Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-22 18:50 +0000
                        Re: generics puzzle Tom Anderson <twic@urchin.earth.li> - 2011-10-22 21:02 +0100
                          Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-25 07:04 +0000
                            Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-25 23:25 -0700
                            Re: generics puzzle Tom Anderson <twic@urchin.earth.li> - 2011-10-26 21:56 +0100
                              Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-27 08:59 +0000
                            eclipse shortcuts again (was Re: generics puzzle) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-29 17:05 +0000
                              Re: eclipse shortcuts again (was Re: generics puzzle) Four of Seventeen <fseventeen@gmail.com> - 2011-10-29 19:49 -0700
                                Re: eclipse shortcuts again (was Re: generics puzzle) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-31 11:17 +0000
                                  Re: eclipse shortcuts again (was Re: generics puzzle) Four of Seventeen <fseventeen@gmail.com> - 2011-10-31 05:39 -0700
                    Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-23 01:30 -0700
                      Re: generics puzzle Lew <lewbloch@gmail.com> - 2011-10-23 08:56 -0700
                        Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-24 02:46 -0700
                      Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-25 07:05 +0000
                        Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-25 23:29 -0700
                          Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-31 11:14 +0000
                            Re: generics puzzle Four of Seventeen <fseventeen@gmail.com> - 2011-10-31 05:34 -0700
            Re: generics puzzle markspace <-@.> - 2011-10-18 21:21 -0700
              Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-19 13:29 +0000
                Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-20 17:22 -0700
                  Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-21 16:28 +0000
                Re: generics puzzle Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-21 06:22 -0300
                  Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-21 16:29 +0000
                  Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-23 01:20 -0700
                    Re: generics puzzle Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-23 09:51 +0000
                      Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-23 03:28 -0700
                        Re: generics puzzle Tom Anderson <twic@urchin.earth.li> - 2011-10-23 15:59 +0100
                          Re: generics puzzle Eight of Seventeen <eights17@gmail.com> - 2011-10-24 02:46 -0700
                      Re: generics puzzle Tom Anderson <twic@urchin.earth.li> - 2011-10-23 15:55 +0100
              Re: generics puzzle Tom Anderson <twic@urchin.earth.li> - 2011-10-20 21:00 +0100
            Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-19 13:26 +0000
              Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-25 17:46 +0000
            Re: generics puzzle Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-21 05:57 -0300
              Re: generics puzzle blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-21 16:28 +0000

Page 1 of 3  [1] 2 3  Next page →

#8904 — generics puzzle

I'm having a bit of trouble with generics, and while I've come
up with ways of getting done what I want to get done, I wonder
whether there's some nice solution that isn't occurring to me.

The basic situation is this:

I have an abstract generic class (call it GThing) with type
parameter T, which has a method (call it set()) that takes a
parameter of type T and another method (call it modified()) that
returns a result of type T.  I also have some classes that extend
GThing and specify its type parameter, and code that is meant
to operate on lists of instances of these various subclasses.
What I would *like* to be able to do is construct a list of
GThing<?> objects and then do to each element of it something
like the following:

  element.set(element.modified())

but the compiler objects to that, which I find reasonable enough,
though I'm not enough of a generics expert to really articulate
what the problem is.  (I have a feeling that this "type erasure"
thing, which I understand dimly at best, comes into it.  :-)? )

One fix is to just introduce a method setFromModified() in GThing,
but that doesn't appeal to me.  An ugly-hack fix is to add to
GThing a set() method that takes an Object and typecasts it,
but -- yuck, right?  

In the same code I also have another generic class that "wraps"
GThing (call it GThingWrapper), and a class that among other
things contains a list of objects of the wrapper class (call
it GThingWrapperList).  One thing I want to do is add to that
list of objects a new GThingWrapper constructed from a GThing,
with the type parameter of the GThingWrapper matching the type
parameter of the GThing.  Initially that didn't work either,
which also seems reasonable enough, *but* I discovered (by trial
and error) a way to make it work using a generic method.  Now I'm
wondering whether somehow a generic method could be used to solve
the first problem, but I'm not finding a way to do it.

SSCCEs follow, one for the first situation (with a comment quoting
the error message I get from Oracle's "javac" compiler, version
1.6.0_21 if that matters), and one for the second.

I'd be glad of advice from anyone knowledgeable about generics
and willing to wade through my code ....

==== SSCCE #1 ====

import java.util.ArrayList;
import java.util.List;

public class GenericsProblem {

    public static void main(String[] args) { 
        List<GThing<?>> things = new ArrayList<GThing<?>>();
        things.add(new IntegerThing(1));
        things.add(new IntegerThing(2));
        things.add(new StringThing("hello"));
        things.add(new StringThing("bye"));
        for (GThing<?> t : things) {
            System.out.println(t.get());
        }
        for (GThing<?> t : things) {
            /* 
            t.set(t.modified());
               does not compile:
               set(capture#591 of ?) in 
               GenericsProblem.GThing<capture#591 of ?>
               cannot be applied to (java.lang.Object)
            */
        }
        for (GThing<?> t : things) {
            /* ugly hack!? */
            t.setG(t.modified());
        }
        for (GThing<?> t : things) {
            System.out.println(t.get());
        }
    }

    public static abstract class GThing<T> {
        private T val;
        protected GThing(T v) { val = v; }
        public T get() { return val; }
        public void set(T v) { val = v; }
        /* ugly hack!? */
        @SuppressWarnings("unchecked")
        public void setG(Object v) { val = (T) v; }
        abstract T modified();
    }

    public static class IntegerThing extends GThing<Integer> { 
        public IntegerThing(Integer i) { super(i); }
        @Override
        public Integer modified() { return get() * 2; }
    }
    public static class StringThing extends GThing<String> { 
        public StringThing(String s) { super(s); }
        @Override
        public String modified() { return get() + get(); }
    }
}


==== SSCCE #2 ====

import java.util.ArrayList;
import java.util.List;

public class GenericsProblemSoln {

    public static void main(String[] args) { 
        GThingWrapperList thingWrappers = new GThingWrapperList();
        thingWrappers.add(new IntegerThing(1));
        thingWrappers.add(new IntegerThing(2));
        thingWrappers.add(new StringThing("hello"));
        thingWrappers.add(new StringThing("bye"));
        for (GThingWrapper<?> tw : thingWrappers.elements()) {
            System.out.println(tw.getThing().get());
        }
        for (GThingWrapper<?> tw : thingWrappers.elements()) {
            tw.setModified();
        }
        for (GThingWrapper<?> tw : thingWrappers.elements()) {
            System.out.println(tw.getThing().get());
        }
    }

    public static abstract class GThing<T> {
        private T val;
        protected GThing(T v) { val = v; }
        public T get() { return val; }
        public void set(T v) { val = v; }
        abstract T modified();
    }

   public static class IntegerThing extends GThing<Integer> { 
        public IntegerThing(Integer i) { super(i); }
        @Override
        public Integer modified() { return get() * 2; }
    }
    public static class StringThing extends GThing<String> { 
        public StringThing(String s) { super(s); }
        @Override
        public String modified() { return get() + get(); }
    }

    public static class GThingWrapper<T> {
        private GThing<T> thing;
        public GThingWrapper(GThing<T> t) { thing = t; }
        public GThing getThing() { return thing; }
        public void setModified() {
            thing.set(thing.modified());
        }
    }

    public static class GThingWrapperList {
        private List<GThingWrapper<?>> thingWrappers = 
            new ArrayList<GThingWrapper<?>>();
        public <T> void add(GThing<T> t) {
            thingWrappers.add(new GThingWrapper<T>(t));
        }
        public Iterable<GThingWrapper<?>> elements() {
            return thingWrappers;
        }
    }
}


-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [next] | [standalone]

#8907

On 17/10/11 11:41, blmblm@myrealbox.com wrote:
> One fix is to just introduce a method setFromModified() in GThing,
> but that doesn't appeal to me.

Instead of adding it to GThing, create a static method:

     private static<T>  void setModified(GThing<T>  t) {
	t.set(t.modified());
     }

This bit then compiles:

        for (GThing<?>  t : things)
	    setModified(t);

I think you can see it as temporarily pinning down T to span the two 
calls, but you can only do that for a complete method, not in-line over 
an expression or a few statements.

-- 
ss at comp dot lancs dot ac dot uk

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

#8911

On Mon, 17 Oct 2011, Steven Simpson wrote:

> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>> One fix is to just introduce a method setFromModified() in GThing,
>> but that doesn't appeal to me.
>
> Instead of adding it to GThing, create a static method:
>
>    private static<T>  void setModified(GThing<T>  t) {
> 	t.set(t.modified());
>    }
>
> This bit then compiles:
>
>       for (GThing<?>  t : things)
> 	    setModified(t);
>
> I think you can see it as temporarily pinning down T to span the two 
> calls, but you can only do that for a complete method, not in-line over 
> an expression or a few statements.

+1

We really need a name for this manoeuvre. Can we call it "taming the 
wildcard" or something?

tom

-- 
Per Dementia ad Astra

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

#8912

On 10/17/2011 5:14 AM, Steven Simpson wrote:
> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>> One fix is to just introduce a method setFromModified() in GThing,
>> but that doesn't appeal to me.
>
> Instead of adding it to GThing, create a static method:
>
> private static<T> void setModified(GThing<T> t) {
> t.set(t.modified());
> }


I don't like the T here.  While it compiles, this T is a different T 
than the other T.

public class GThing<T> {

   private static <U> void setModified( GThing<U> t ) {

  ...other T's stay the same.
}

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

#8918

On 17/10/11 15:33, markspace wrote:
> On 10/17/2011 5:14 AM, Steven Simpson wrote:
>> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>>> One fix is to just introduce a method setFromModified() in GThing,
>>> but that doesn't appeal to me.
>>
>> Instead of adding it to GThing, create a static method:
>>
>> private static<T> void setModified(GThing<T> t) {
>> t.set(t.modified());
>> }
>
>
> I don't like the T here.  While it compiles, this T is a different T 
> than the other T.

Ah, T time! ;-)

> public class GThing<T> {
>
>   private static <U> void setModified( GThing<U> t ) {
>
>  ...other T's stay the same.
> }

I meant that the static method didn't belong in GThing at all.  The 
author of the call site factors it out of his code, and keeps it near 
the call site, in order to deal with an issue that arises very 
specifically out of the design of that site.  Ideally, it would be an 
Ada-like local method, but he has to settle for a near-by static.  The 
author of GThing is unaware of it, and is not responsible for it.

-- 
ss at comp dot lancs dot ac dot uk

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

#8951

In article <33utm8-qs4.ln1@news.simpsonst.f2s.com>,
Steven Simpson  <ss@domain.invalid> wrote:
> On 17/10/11 15:33, markspace wrote:
> > On 10/17/2011 5:14 AM, Steven Simpson wrote:
> >> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
> >>> One fix is to just introduce a method setFromModified() in GThing,
> >>> but that doesn't appeal to me.
> >>
> >> Instead of adding it to GThing, create a static method:
> >>
> >> private static<T> void setModified(GThing<T> t) {
> >> t.set(t.modified());
> >> }

Hm, yes, that works; thanks!

> >
> > I don't like the T here.  While it compiles, this T is a different T 
> > than the other T.
> 
> Ah, T time! ;-)
> 
> > public class GThing<T> {
> >
> >   private static <U> void setModified( GThing<U> t ) {
> >
> >  ...other T's stay the same.
> > }
> 
> I meant that the static method didn't belong in GThing at all.  

That was kind of my feeling, but -- I'm kind of ambivalent about
it, because there are a couple of "call sites" (to use your term)
where I seem to need this kind of thing.

> The 
> author of the call site factors it out of his code, and keeps it near 
> the call site, in order to deal with an issue that arises very 
> specifically out of the design of that site.  Ideally, it would be an 
> Ada-like local method, but he has to settle for a near-by static.  The 
> author of GThing is unaware of it, and is not responsible for it.

Wrong gender for the author of the call site here, but okay, pet peeve
of mine, and off-topic, and IIRC discussed recently enough that we
shouldn't repeat it ....

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

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

#8919

markspace <-@> wrote:
> On 10/17/2011 5:14 AM, Steven Simpson wrote:
>> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>>> One fix is to just introduce a method setFromModified() in GThing,
>>> but that doesn't appeal to me.
>> Instead of adding it to GThing, create a static method:
>> private static<T> void setModified(GThing<T> t) {
>> t.set(t.modified());
>> }
> I don't like the T here.  While it compiles, this T is a different T 
> than the other T.

If you want to mix GThing<Apple>s and GThing<Orange>s, then you had 
better go by GThing<Fruit> all the way.

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

#8922

On 10/17/11 5:14 AM, Steven Simpson wrote:
> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>> One fix is to just introduce a method setFromModified() in GThing,
>> but that doesn't appeal to me.
>
> Instead of adding it to GThing, create a static method:
>
> private static<T> void setModified(GThing<T> t) {
> t.set(t.modified());
> }
>
> This bit then compiles:
>
> for (GThing<?> t : things)
> setModified(t);
>
> I think you can see it as temporarily pinning down T to span the two
> calls, but you can only do that for a complete method, not in-line over
> an expression or a few statements.
>



What about the simpler solution:

in the GThing class:

public void setModified() {
    set(modified());
}

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

#8944

On 17/10/11 16:58, Daniel Pitts wrote:
> On 10/17/11 5:14 AM, Steven Simpson wrote:
>> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>>> One fix is to just introduce a method setFromModified() in GThing,
>>> but that doesn't appeal to me.
>>
>> Instead of adding it to GThing, create a static method:
>>
>> private static<T> void setModified(GThing<T> t) {
>> t.set(t.modified());
>> }
>
>
> What about the simpler solution:
>
> in the GThing class:
>
> public void setModified() {
>    set(modified());
> }

It "doesn't appeal" to the OP?  Nor to me.  Not sure I can put my finger 
on it, but if I were the maintainer of GThing, I'd consider its 
specification to be complete without this method.  It doesn't increase 
the value of the class as an abstraction.  Adding it would certainly 
just be a convenience for the caller.  It solves a problem generated by 
the design of the call site, not the design of the class's contract.  
The caller can write his own routine as necessary.

-- 
ss at comp dot lancs dot ac dot uk

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

#8960

On 10/18/11 2:45 AM, Steven Simpson wrote:
> On 17/10/11 16:58, Daniel Pitts wrote:
>> On 10/17/11 5:14 AM, Steven Simpson wrote:
>>> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>>>> One fix is to just introduce a method setFromModified() in GThing,
>>>> but that doesn't appeal to me.
>>>
>>> Instead of adding it to GThing, create a static method:
>>>
>>> private static<T> void setModified(GThing<T> t) {
>>> t.set(t.modified());
>>> }
>>
>>
>> What about the simpler solution:
>>
>> in the GThing class:
>>
>> public void setModified() {
>> set(modified());
>> }
>
> It "doesn't appeal" to the OP? Nor to me. Not sure I can put my finger
> on it, but if I were the maintainer of GThing, I'd consider its
> specification to be complete without this method. It doesn't increase
> the value of the class as an abstraction. Adding it would certainly just
> be a convenience for the caller. It solves a problem generated by the
> design of the call site, not the design of the class's contract. The
> caller can write his own routine as necessary.
>
Possibly, but if it is something that happens frequently, then it seems 
more likely to belong to GThing than externally. Otherwise your 
call-site is suffering from the code smell "feature envy"

One other approach is a "visitor" pattern:


public interface GThingVisitor {
    <T> void visit(GThing<T> gThing);
};


public class SetModifiedGThingVisitor {
      <T> void visit(GThing<T> gThing) {
	gThing.set(gThing.modified());
      }
}

public class GThing<T> {
    public void accept(GThingVisitor visitor) {
	visitor.accept(this);
    }
}

public class CallSite {
    public void setAllModified(Iterable<? extends GThing<?>> things) {
  	GThingVisitor visitor = new SetModifiedGThingVisitor();
         for (GThing<?> thing: things) {
             thing.accept(visitor);
         }
    }
}

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

#8990

In article <M%hnq.3083$Oz5.1691@newsfe16.iad>,
Daniel Pitts  <newsgroup.nospam@virtualinfinity.net> wrote:
> On 10/18/11 2:45 AM, Steven Simpson wrote:
> > On 17/10/11 16:58, Daniel Pitts wrote:
> >> On 10/17/11 5:14 AM, Steven Simpson wrote:
> >>> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
> >>>> One fix is to just introduce a method setFromModified() in GThing,
> >>>> but that doesn't appeal to me.
> >>>
> >>> Instead of adding it to GThing, create a static method:
> >>>
> >>> private static<T> void setModified(GThing<T> t) {
> >>> t.set(t.modified());
> >>> }
> >>
> >>
> >> What about the simpler solution:
> >>
> >> in the GThing class:
> >>
> >> public void setModified() {
> >> set(modified());
> >> }
> >
> > It "doesn't appeal" to the OP? Nor to me. Not sure I can put my finger
> > on it, but if I were the maintainer of GThing, I'd consider its
> > specification to be complete without this method. It doesn't increase
> > the value of the class as an abstraction. Adding it would certainly just
> > be a convenience for the caller. It solves a problem generated by the
> > design of the call site, not the design of the class's contract. The
> > caller can write his own routine as necessary.
> >
> Possibly, but if it is something that happens frequently, then it seems 
> more likely to belong to GThing than externally. Otherwise your 
> call-site is suffering from the code smell "feature envy"
> 
> One other approach is a "visitor" pattern:
> 

I know the "visitor" pattern (vaguely anyway), but ....  I'm not sure
I understand your version of it here, which -- does this compile?
because ....

> 
> public interface GThingVisitor {
>     <T> void visit(GThing<T> gThing);
> };

(Aside:  Hm, a generic method in an interface?!  well, why not,
maybe, but I'm not sure it would have occurred to me to try!)

> public class SetModifiedGThingVisitor {
>       <T> void visit(GThing<T> gThing) {
> 	gThing.set(gThing.modified());
>       }
> }

Was this meant to implement GThingVisitor?

> public class GThing<T> {
>     public void accept(GThingVisitor visitor) {
> 	visitor.accept(this);
>     }
> }

visitor.visit(this)??

> public class CallSite {
>     public void setAllModified(Iterable<? extends GThing<?>> things) {
>   	GThingVisitor visitor = new SetModifiedGThingVisitor();
>          for (GThing<?> thing: things) {
>              thing.accept(visitor);
>          }
>     }
> }
> 

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

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

#9004

On 10/19/11 6:25 AM, blmblm@myrealbox.com wrote:
> In article<M%hnq.3083$Oz5.1691@newsfe16.iad>,
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  wrote:
>> On 10/18/11 2:45 AM, Steven Simpson wrote:
>>> On 17/10/11 16:58, Daniel Pitts wrote:
>>>> On 10/17/11 5:14 AM, Steven Simpson wrote:
>>>>> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>>>>>> One fix is to just introduce a method setFromModified() in GThing,
>>>>>> but that doesn't appeal to me.
>>>>>
>>>>> Instead of adding it to GThing, create a static method:
>>>>>
>>>>> private static<T>  void setModified(GThing<T>  t) {
>>>>> t.set(t.modified());
>>>>> }
>>>>
>>>>
>>>> What about the simpler solution:
>>>>
>>>> in the GThing class:
>>>>
>>>> public void setModified() {
>>>> set(modified());
>>>> }
>>>
>>> It "doesn't appeal" to the OP? Nor to me. Not sure I can put my finger
>>> on it, but if I were the maintainer of GThing, I'd consider its
>>> specification to be complete without this method. It doesn't increase
>>> the value of the class as an abstraction. Adding it would certainly just
>>> be a convenience for the caller. It solves a problem generated by the
>>> design of the call site, not the design of the class's contract. The
>>> caller can write his own routine as necessary.
>>>
>> Possibly, but if it is something that happens frequently, then it seems
>> more likely to belong to GThing than externally. Otherwise your
>> call-site is suffering from the code smell "feature envy"
>>
>> One other approach is a "visitor" pattern:
>>
>
> I know the "visitor" pattern (vaguely anyway), but ....  I'm not sure
> I understand your version of it here, which -- does this compile?
> because ....
>
>>
>> public interface GThingVisitor {
>>      <T>  void visit(GThing<T>  gThing);
>> };
>
> (Aside:  Hm, a generic method in an interface?!  well, why not,
> maybe, but I'm not sure it would have occurred to me to try!)
I've used it in the past, so I know it works.
>
>> public class SetModifiedGThingVisitor {
>>        <T>  void visit(GThing<T>  gThing) {
>> 	gThing.set(gThing.modified());
>>        }
>> }
>
> Was this meant to implement GThingVisitor?
Indeed it was. This entire snippet was typed up in my mail program, so I 
missed a few pieces.
>> public class GThing<T>  {
>>      public void accept(GThingVisitor visitor) {
>> 	visitor.accept(this);
>>      }
>> }
>
> visitor.visit(this)??
Yes, that's what I intended :-)
>
>> public class CallSite {
>>      public void setAllModified(Iterable<? extends GThing<?>>  things) {
>>    	GThingVisitor visitor = new SetModifiedGThingVisitor();
>>           for (GThing<?>  thing: things) {
>>               thing.accept(visitor);
>>           }
>>      }
>> }
>>
>

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

#9026

In article <ZqDnq.5673$UK6.3114@newsfe06.iad>,
Daniel Pitts  <newsgroup.nospam@virtualinfinity.net> wrote:
> On 10/19/11 6:25 AM, blmblm@myrealbox.com wrote:
> > In article<M%hnq.3083$Oz5.1691@newsfe16.iad>,
> > Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  wrote:
> >> On 10/18/11 2:45 AM, Steven Simpson wrote:
> >>> On 17/10/11 16:58, Daniel Pitts wrote:
> >>>> On 10/17/11 5:14 AM, Steven Simpson wrote:
> >>>>> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
> >>>>>> One fix is to just introduce a method setFromModified() in GThing,
> >>>>>> but that doesn't appeal to me.
> >>>>>
> >>>>> Instead of adding it to GThing, create a static method:
> >>>>>
> >>>>> private static<T>  void setModified(GThing<T>  t) {
> >>>>> t.set(t.modified());
> >>>>> }
> >>>>
> >>>>
> >>>> What about the simpler solution:
> >>>>
> >>>> in the GThing class:
> >>>>
> >>>> public void setModified() {
> >>>> set(modified());
> >>>> }
> >>>
> >>> It "doesn't appeal" to the OP? Nor to me. Not sure I can put my finger
> >>> on it, but if I were the maintainer of GThing, I'd consider its
> >>> specification to be complete without this method. It doesn't increase
> >>> the value of the class as an abstraction. Adding it would certainly just
> >>> be a convenience for the caller. It solves a problem generated by the
> >>> design of the call site, not the design of the class's contract. The
> >>> caller can write his own routine as necessary.
> >>>
> >> Possibly, but if it is something that happens frequently, then it seems
> >> more likely to belong to GThing than externally. Otherwise your
> >> call-site is suffering from the code smell "feature envy"
> >>
> >> One other approach is a "visitor" pattern:
> >>
> >
> > I know the "visitor" pattern (vaguely anyway), but ....  I'm not sure
> > I understand your version of it here, which -- does this compile?
> > because ....
> >
> >>
> >> public interface GThingVisitor {
> >>      <T>  void visit(GThing<T>  gThing);
> >> };
> >
> > (Aside:  Hm, a generic method in an interface?!  well, why not,
> > maybe, but I'm not sure it would have occurred to me to try!)
> I've used it in the past, so I know it works.
> >
> >> public class SetModifiedGThingVisitor {
> >>        <T>  void visit(GThing<T>  gThing) {
> >> 	gThing.set(gThing.modified());
> >>        }
> >> }
> >
> > Was this meant to implement GThingVisitor?
> Indeed it was. This entire snippet was typed up in my mail program, so I 
> missed a few pieces.
> >> public class GThing<T>  {
> >>      public void accept(GThingVisitor visitor) {
> >> 	visitor.accept(this);
> >>      }
> >> }
> >
> > visitor.visit(this)??
> Yes, that's what I intended :-)

Typos (thinkos?) happen.

> >> public class CallSite {
> >>      public void setAllModified(Iterable<? extends GThing<?>>  things) {
> >>    	GThingVisitor visitor = new SetModifiedGThingVisitor();
> >>           for (GThing<?>  thing: things) {
> >>               thing.accept(visitor);
> >>           }
> >>      }
> >> }

I can report that this approach works too, though I put the
visitor code directly in CallSite as an anonymous inner class
rather than writing a separate SetModifiedGThingVisitor class.

Overall this approach has for me a certain "can't quite get my head
around it" quality -- not in the sense that I don't understand how it
works, but in the sense that I can't quite sort out how it compares
to the static-method approach.  Thoughts, anyone?

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

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

#9044

On 10/20/11 7:14 AM, blmblm@myrealbox.com wrote:
> In article<ZqDnq.5673$UK6.3114@newsfe06.iad>,
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  wrote:
>> On 10/19/11 6:25 AM, blmblm@myrealbox.com wrote:
>>> In article<M%hnq.3083$Oz5.1691@newsfe16.iad>,
>>> Daniel Pitts<newsgroup.nospam@virtualinfinity.net>   wrote:
>>>> On 10/18/11 2:45 AM, Steven Simpson wrote:
>>>>> On 17/10/11 16:58, Daniel Pitts wrote:
>>>>>> On 10/17/11 5:14 AM, Steven Simpson wrote:
>>>>>>> On 17/10/11 11:41, blmblm@myrealbox.com wrote:
>>>>>>>> One fix is to just introduce a method setFromModified() in GThing,
>>>>>>>> but that doesn't appeal to me.
>>>>>>>
>>>>>>> Instead of adding it to GThing, create a static method:
>>>>>>>
>>>>>>> private static<T>   void setModified(GThing<T>   t) {
>>>>>>> t.set(t.modified());
>>>>>>> }
>>>>>>
>>>>>>
>>>>>> What about the simpler solution:
>>>>>>
>>>>>> in the GThing class:
>>>>>>
>>>>>> public void setModified() {
>>>>>> set(modified());
>>>>>> }
>>>>>
>>>>> It "doesn't appeal" to the OP? Nor to me. Not sure I can put my finger
>>>>> on it, but if I were the maintainer of GThing, I'd consider its
>>>>> specification to be complete without this method. It doesn't increase
>>>>> the value of the class as an abstraction. Adding it would certainly just
>>>>> be a convenience for the caller. It solves a problem generated by the
>>>>> design of the call site, not the design of the class's contract. The
>>>>> caller can write his own routine as necessary.
>>>>>
>>>> Possibly, but if it is something that happens frequently, then it seems
>>>> more likely to belong to GThing than externally. Otherwise your
>>>> call-site is suffering from the code smell "feature envy"
>>>>
>>>> One other approach is a "visitor" pattern:
>>>>
>>>
>>> I know the "visitor" pattern (vaguely anyway), but ....  I'm not sure
>>> I understand your version of it here, which -- does this compile?
>>> because ....
>>>
>>>>
>>>> public interface GThingVisitor {
>>>>       <T>   void visit(GThing<T>   gThing);
>>>> };
>>>
>>> (Aside:  Hm, a generic method in an interface?!  well, why not,
>>> maybe, but I'm not sure it would have occurred to me to try!)
>> I've used it in the past, so I know it works.
>>>
>>>> public class SetModifiedGThingVisitor {
>>>>         <T>   void visit(GThing<T>   gThing) {
>>>> 	gThing.set(gThing.modified());
>>>>         }
>>>> }
>>>
>>> Was this meant to implement GThingVisitor?
>> Indeed it was. This entire snippet was typed up in my mail program, so I
>> missed a few pieces.
>>>> public class GThing<T>   {
>>>>       public void accept(GThingVisitor visitor) {
>>>> 	visitor.accept(this);
>>>>       }
>>>> }
>>>
>>> visitor.visit(this)??
>> Yes, that's what I intended :-)
>
> Typos (thinkos?) happen.
>
>>>> public class CallSite {
>>>>       public void setAllModified(Iterable<? extends GThing<?>>   things) {
>>>>     	GThingVisitor visitor = new SetModifiedGThingVisitor();
>>>>            for (GThing<?>   thing: things) {
>>>>                thing.accept(visitor);
>>>>            }
>>>>       }
>>>> }
>
> I can report that this approach works too, though I put the
> visitor code directly in CallSite as an anonymous inner class
> rather than writing a separate SetModifiedGThingVisitor class.
>
> Overall this approach has for me a certain "can't quite get my head
> around it" quality -- not in the sense that I don't understand how it
> works, but in the sense that I can't quite sort out how it compares
> to the static-method approach.  Thoughts, anyone?
>
Frankly in this case it amounts to the same, but when you have more 
complicated generics definitions, such as:

class A<T extends B<T, F>, F extends C<F, T>, Q extends D<T,F,B>> {
}


If you have an A<?, ?, ?>, I think the static approach fails due to 
being unable to verify the "extends" part. Though I haven't tried it in 
a while.

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

#8923

On Oct 17, 12:41 pm, blm...@myrealbox.com <blmblm.myreal...@gmail.com>
wrote:
> I'm having a bit of trouble with generics, and while I've come
> up with ways of getting done what I want to get done, I wonder
> whether there's some nice solution that isn't occurring to me.
>
> The basic situation is this:
>
> I have an abstract generic class (call it GThing) with type
> parameter T, which has a method (call it set()) that takes a
> parameter of type T and another method (call it modified()) that
> returns a result of type T.  I also have some classes that extend
> GThing and specify its type parameter, and code that is meant
> to operate on lists of instances of these various subclasses.
> What I would *like* to be able to do is construct a list of
> GThing<?> objects and then do to each element of it something
> like the following:
>
>   element.set(element.modified())
>
> but the compiler objects to that, which I find reasonable enough,
> though I'm not enough of a generics expert to really articulate
> what the problem is.  (I have a feeling that this "type erasure"
> thing, which I understand dimly at best, comes into it.  :-)? )

The reason is the ? in the type: the compiler does not know the type.
The very moment you declare a List<GThing<?>> the type of T is unknown
even though it's the same instance.  Unknown types cannot be
compatible yet you try to do invoke a method with argument type ? with
a parameter of type ? and since "? incompatible to ?" it is not
allowed.

You are basically doing this (list1) but bounding does not help
(neither way, list2 and list3); only concrete types are able to ensure
type compatibility:

import java.util.ArrayList;
import java.util.List;

public class GenericsProblemRK {

    public static void main(String[] args) {
	final List<List<?>> list1 = new ArrayList<List<?>>();

	for (final List<?> l : list1) {
	    l.add(l.get(0)); // error
	    final Object x = l.get(0); // OK
	    l.add(x); // error
	}

	final List<List<? extends String>> list2 = new ArrayList<List<?
extends String>>();

	for (final List<? extends String> l : list2) {
	    l.add(l.get(0)); // error
	    final Object x = l.get(0); // OK
	    l.add(x); // error
	}

	final List<List<? super String>> list3 = new ArrayList<List<? super
String>>();

	for (final List<? super String> l : list3) {
	    l.add(l.get(0)); // error
	    final Object x = l.get(0); // OK
	    l.add(x); // error
	}

	final List<List<String>> list4 = new ArrayList<List<String>>();

	for (final List<String> l : list4) {
	    l.add(l.get(0)); // OK
	}
    }

}

> One fix is to just introduce a method setFromModified() in GThing,
> but that doesn't appeal to me.  An ugly-hack fix is to add to
> GThing a set() method that takes an Object and typecasts it,
> but -- yuck, right?  

In your case since apparently you want to update internally why not
just introduce

public void update() {
  set(modified());
}

This will safely compile.  Basically this is what you did with
setModified() in the wrapper class.  All other approaches will be
hacky (i.e. involve explicit casting, using Object parameters or
return values etc.).

Kind regards

robert

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

#8953

In article <45bfae98-a142-469b-9b8b-9aa8a59391f1@n13g2000vbv.googlegroups.com>,
Robert Klemme  <shortcutter@googlemail.com> wrote:
> On Oct 17, 12:41 pm, blm...@myrealbox.com <blmblm.myreal...@gmail.com>
> wrote:
> > I'm having a bit of trouble with generics, and while I've come
> > up with ways of getting done what I want to get done, I wonder
> > whether there's some nice solution that isn't occurring to me.
> >
> > The basic situation is this:
> >
> > I have an abstract generic class (call it GThing) with type
> > parameter T, which has a method (call it set()) that takes a
> > parameter of type T and another method (call it modified()) that
> > returns a result of type T.  I also have some classes that extend
> > GThing and specify its type parameter, and code that is meant
> > to operate on lists of instances of these various subclasses.
> > What I would *like* to be able to do is construct a list of
> > GThing<?> objects and then do to each element of it something
> > like the following:
> >
> >   element.set(element.modified())
> >
> > but the compiler objects to that, which I find reasonable enough,
> > though I'm not enough of a generics expert to really articulate
> > what the problem is.  (I have a feeling that this "type erasure"
> > thing, which I understand dimly at best, comes into it.  :-)? )
> 
> The reason is the ? in the type: the compiler does not know the type.
> The very moment you declare a List<GThing<?>> the type of T is unknown
> even though it's the same instance.  Unknown types cannot be
> compatible yet you try to do invoke a method with argument type ? with
> a parameter of type ? and since "? incompatible to ?" it is not
> allowed.

Nice job of putting into words my vague idea about what's wrong;
thanks!

> You are basically doing this (list1) but bounding does not help
> (neither way, list2 and list3); only concrete types are able to ensure
> type compatibility:
> 
> import java.util.ArrayList;
> import java.util.List;
> 
> public class GenericsProblemRK {
> 
>     public static void main(String[] args) {
> 	final List<List<?>> list1 = new ArrayList<List<?>>();
> 
> 	for (final List<?> l : list1) {
> 	    l.add(l.get(0)); // error
> 	    final Object x = l.get(0); // OK
> 	    l.add(x); // error
> 	}
> 
> 	final List<List<? extends String>> list2 = new ArrayList<List<?
> extends String>>();
> 
> 	for (final List<? extends String> l : list2) {
> 	    l.add(l.get(0)); // error
> 	    final Object x = l.get(0); // OK
> 	    l.add(x); // error
> 	}
> 
> 	final List<List<? super String>> list3 = new ArrayList<List<? super
> String>>();
> 
> 	for (final List<? super String> l : list3) {
> 	    l.add(l.get(0)); // error
> 	    final Object x = l.get(0); // OK
> 	    l.add(x); // error
> 	}
> 
> 	final List<List<String>> list4 = new ArrayList<List<String>>();
> 
> 	for (final List<String> l : list4) {
> 	    l.add(l.get(0)); // OK
> 	}
>     }
> 
> }
> 
> > One fix is to just introduce a method setFromModified() in GThing,
> > but that doesn't appeal to me.  An ugly-hack fix is to add to
> > GThing a set() method that takes an Object and typecasts it,
> > but -- yuck, right?  
> 
> In your case since apparently you want to update internally why not
> just introduce
> 
> public void update() {
>   set(modified());
> }

I'm not sure I can say why this doesn't appeal to me -- something
about not wanting to clutter up GThing with unnecessary methods.

> This will safely compile.  Basically this is what you did with
> setModified() in the wrapper class.  All other approaches will be
> hacky (i.e. involve explicit casting, using Object parameters or
> return values etc.).

Yeah, maybe ....  In my "real" code (quotation marks because it's
a toy project embarked on for entertainment and a bit of education)
the method in the wrapper class does more than just call modified()
and then set().  I don't know that that matters much, though.  I do
have a couple of different "call sites" (to use another poster's term)
that need similar functionality, so maybe it *does* go in GThing.
Well, like I said, "entertainment and a bit of education", and for
me that seems to involve -- the coding equivalent of periodically
rearranging the furniture, maybe.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

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

#8958

On 10/18/2011 04:49 PM, blmblm@myrealbox.com wrote:
> In article<45bfae98-a142-469b-9b8b-9aa8a59391f1@n13g2000vbv.googlegroups.com>,
> Robert Klemme<shortcutter@googlemail.com>  wrote:
>> On Oct 17, 12:41 pm, blm...@myrealbox.com<blmblm.myreal...@gmail.com>
>> wrote:

> Nice job of putting into words my vague idea about what's wrong;
> thanks!

Thank _you_.

>> In your case since apparently you want to update internally why not
>> just introduce
>>
>> public void update() {
>>    set(modified());
>> }
>
> I'm not sure I can say why this doesn't appeal to me -- something
> about not wanting to clutter up GThing with unnecessary methods.

Why is it unnecessary?  It seems this provides a proper abstraction.  As 
your example shows and concluding from what you write below you do 
already have two or more uses for it.  So by having the method you can 
actually reduce redundancy.  That's a common pattern: we find we do 
something over and over again, we turn it into a method or procedure.

>> This will safely compile.  Basically this is what you did with
>> setModified() in the wrapper class.  All other approaches will be
>> hacky (i.e. involve explicit casting, using Object parameters or
>> return values etc.).
>
> Yeah, maybe ....  In my "real" code (quotation marks because it's
> a toy project embarked on for entertainment and a bit of education)
> the method in the wrapper class does more than just call modified()
> and then set().  I don't know that that matters much, though.  I do
> have a couple of different "call sites" (to use another poster's term)
> that need similar functionality, so maybe it *does* go in GThing.
> Well, like I said, "entertainment and a bit of education", and for
> me that seems to involve -- the coding equivalent of periodically
> rearranging the furniture, maybe.

That's called "refactoring" - and is quite frequent with "real" code in 
my experience. :-)  Certainly not something to be afraid of - with 
proper tools it can even be fun. :-)

I think you're on the right track: best learning experience is by having 
a toy project and trying out different things.  That way you see what 
works and what not - and you get the satisfaction of having found out 
yourself.

Kind regards

	robert

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

#8962

In article <9g5nnhFahuU1@mid.individual.net>,
Robert Klemme  <shortcutter@googlemail.com> wrote:
> On 10/18/2011 04:49 PM, blmblm@myrealbox.com wrote:
> > In article<45bfae98-a142-469b-9b8b-9aa8a59391f1@n13g2000vbv.googlegroups.com>,
> > Robert Klemme<shortcutter@googlemail.com>  wrote:
> >> On Oct 17, 12:41 pm, blm...@myrealbox.com<blmblm.myreal...@gmail.com>
> >> wrote:
> 
> > Nice job of putting into words my vague idea about what's wrong;
> > thanks!
> 
> Thank _you_.
> 
> >> In your case since apparently you want to update internally why not
> >> just introduce
> >>
> >> public void update() {
> >>    set(modified());
> >> }
> >
> > I'm not sure I can say why this doesn't appeal to me -- something
> > about not wanting to clutter up GThing with unnecessary methods.
> 
> Why is it unnecessary?  It seems this provides a proper abstraction.  As 
> your example shows and concluding from what you write below you do 
> already have two or more uses for it.  So by having the method you can 
> actually reduce redundancy.  That's a common pattern: we find we do 
> something over and over again, we turn it into a method or procedure.

Yeah, maybe.  I'll look some more at my actual code.

> >> This will safely compile.  Basically this is what you did with
> >> setModified() in the wrapper class.  All other approaches will be
> >> hacky (i.e. involve explicit casting, using Object parameters or
> >> return values etc.).
> >
> > Yeah, maybe ....  In my "real" code (quotation marks because it's
> > a toy project embarked on for entertainment and a bit of education)
> > the method in the wrapper class does more than just call modified()
> > and then set().  I don't know that that matters much, though.  I do
> > have a couple of different "call sites" (to use another poster's term)
> > that need similar functionality, so maybe it *does* go in GThing.
> > Well, like I said, "entertainment and a bit of education", and for
> > me that seems to involve -- the coding equivalent of periodically
> > rearranging the furniture, maybe.
> 
> That's called "refactoring" - and is quite frequent with "real" code in 
> my experience. :-)  Certainly not something to be afraid of - with 
> proper tools it can even be fun. :-)

Well, I obviously think it's fun, or I wouldn't do so much of
it?  I do know the term "refactoring", but to me it suggests an
activity somehow more purposeful than what I feel like I'm doing.
Good to know, by the way, that it does happen with real code --
I've been away from professional programming for a long time and
don't keep up as well as I might with current practices.

(About tools -- I'm a long-time vim user, more than a little
fanatical about my text editor of choice, but more and more for
Java code I find myself also starting Eclipse to do some of the
things *it* does well, and finding more and more things in that
category -- automatic generation of imports and boilerplate code,
renaming of classes, etc.)

> I think you're on the right track: best learning experience is by having 
> a toy project and trying out different things.  That way you see what 
> works and what not - and you get the satisfaction of having found out 
> yourself.

True.  (For what it's worth -- I may be less of a novice than I'm
coming across as, having written my first program in 1970-something.
But the learning doesn't stop, or shouldn't?)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

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

#8963

On 10/18/2011 07:45 PM, blmblm@myrealbox.com wrote:
> In article<9g5nnhFahuU1@mid.individual.net>,

> Well, I obviously think it's fun, or I wouldn't do so much of
> it?  I do know the term "refactoring", but to me it suggests an
> activity somehow more purposeful than what I feel like I'm doing.

I think any rearrangement of code can be called "refactoring". 
Sometimes you need to try out different arrangements until you arrive at 
one which leads to satisfactory results.

> Good to know, by the way, that it does happen with real code --
> I've been away from professional programming for a long time and
> don't keep up as well as I might with current practices.
>
> (About tools -- I'm a long-time vim user, more than a little
> fanatical about my text editor of choice, but more and more for
> Java code I find myself also starting Eclipse to do some of the
> things *it* does well, and finding more and more things in that
> category -- automatic generation of imports and boilerplate code,
> renaming of classes, etc.)

For me it's the other way round: I normally use Eclipse and use vim from 
time to time - mostly for editing scripts or other text files that I 
need to work with. :-)

>> I think you're on the right track: best learning experience is by having
>> a toy project and trying out different things.  That way you see what
>> works and what not - and you get the satisfaction of having found out
>> yourself.
>
> True.  (For what it's worth -- I may be less of a novice than I'm
> coming across as, having written my first program in 1970-something.
> But the learning doesn't stop, or shouldn't?)

Then you certainly started earlier than me. :-)

Kind regards

	robert

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

#8968

On Oct 18, 1:45 pm, blm...@myrealbox.com <blmblm.myreal...@gmail.com>
wrote:
> (About tools -- I'm a long-time vim user, more than a little
> fanatical about my text editor of choice, but more and more for
> Java code I find myself also starting Eclipse to do some of the
> things *it* does well, and finding more and more things in that
> category -- automatic generation of imports and boilerplate code,
> renaming of classes, etc.)

Ah. Progress at last.

Though I did notice some kooky recommendations about "screen" in
another thread. Did you really say you liked it for its providing a
somewhat-broken, but maybe somewhat-usable, implementation of cross-
app cut and paste? When, of course, graphical apps have had working
universal clipboards for, well, forever, that aren't limited to one
screenful at a time and aren't likely to capture crud like
foo^]]E^]]D^Hquux ...

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web