generics puzzle

[blmblm]

Yes, I used to be a fan of vim also, but modern IDEs, at least in the
Java space, do too much to ignore them. Macros/templates, automatic
generation of source code, automatic test environments, automatic
interfacing with SCC systems, etc.

Yeah, as I say, "more and more things" ....

Vim just can't keep up. Emacs might
be able to keep up, but I was never an emacs fan, and I don't intend to
learn an older IDE.

Eh. If I had it to do over again I'd probably choose to "bond"
with emacs rather than vi(m), because the odds of its being able to
keep up, in this sense, do seem better. It's mildly interesting
to speculate on why that's so -- is the user community larger, or
more determined, or is there something about the tool itself? --
but only mildly. As for whether there's any value to switching
to emacs at this point -- nah, flamebait topic, IMO.

Try to learn a couple of IDEs, it'll help your Java career immensely.

s/career/something/ (I'm not a professional programmer these days.)

I find the interface of a typical IDE to be *WAY* too cluttered for
my tastes. But then that's true of a lot of programs with graphical
interfaces. Probably a YMMV thing.

 

[Daniel Pitts]

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


(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.

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.

visitor.visit(this)??

Yes, that's what I intended

 

[blmblm]

I've used it in the past, so I know it works.
Indeed it was. This entire snippet was typed up in my mail program, so I
missed a few pieces.
Yes, that's what I intended

Typos (thinkos?) happen.

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?

 

[Daniel Pitts]

Typos (thinkos?) happen.


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.

 

[Tom Anderson]

Yes, I used to be a fan of vim also, but modern IDEs, at least in the
Java space, do too much to ignore them. Macros/templates, automatic
generation of source code, automatic test environments, automatic
interfacing with SCC systems, etc. Vim just can't keep up.

Here's Vim keeping up:

http://eclim.org/

Emacs might be able to keep up

Might be able to keep up with Vim:

http://www.emacswiki.org/emacs/EmacsEclim

tom

 

[Eight of Seventeen]

"At last"?

Yes. After years of your promoting primitive text-mode tools as
purportedly superior to everything else, you have begun to see the
light regarding at least 1 GUI app.

One of the things I like about it is that it provides a mechanism
for cut and paste, yes.  Why do you call it "somewhat-broken"?

Well, since it's not a true application-integrated clipboard, it's
necessarily going to be limited, basically to what the app's currently
displaying at one time. You won't be able to go into a screen-oriented
editor and start a selection, go down two pages, end the selection
there, and copy. The "screen" program will only see a maximum of one
page at a time. With a line-oriented editor and a backscroll buffer of
some sort you could get more, except, well, line-oriented editor.
Bletch!

(Be advised that I'm talking about the GNU version of "screen",
not the non-GNU version, which I haven't used in a while but
which I seem to remember as having fewer features and little if
any documentation.)

There're two of them? And they didn't think to give them distinct
names? Typical.

The cut-and-paste provided by "screen" is not limited to one
screenful at a time.

If the underlying app is screen-oriented then it must be. There'd be
no way for "screen" to know about scrolling or selections in that app,
and selections in itself will be limited to the current contents of
the app's display, and scrolling in itself won't work with screen-
oriented underlying apps.

and aren't likely to capture crud like
foo^]]E^]]D^Hquux ...

I have no idea what that "crud like ...." phrase is meant to convey;
it doesn't resemble anything I've observed happening with "screen".

Well, the only other way to make "screen"'s clipboard work, besides to
copy parts of the app's display output, is to copy either parts of the
app's raw output or its input. But the latter two will be full of
escape and control characters, at least in the case where the app is
screen-oriented, which will then tend to print like the garbage above.

 

[Eight of Seventeen]

Eh.  If I had it to do over again I'd probably choose to "bond"
with emacs rather than vi(m), because the odds of its being able to
keep up, in this sense, do seem better.

What about "bonding" with a GUI?

I find the interface of a typical IDE to be *WAY* too cluttered for
my tastes.  But then that's true of a lot of programs with graphical
interfaces.  Probably a YMMV thing.

DEFINITELY a YMMV thing.

 

[Arved Sandstrom]

Robert Klemme <[email protected]> wrote:

[ SNIP ]

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.

[ SNIP ]

"Refactoring", simply put, does not change the functionality of the
code. Leastways it's not supposed to.

Refactoring is done to achieve more clarity and simplicity and
maintainability (and perhaps testability). It could be as simple as
renaming a variable actually. That's purposeful refactoring.

AHS

 

[Arved Sandstrom]

[ SNIP ]

s/career/something/ (I'm not a professional programmer these days.)

I find the interface of a typical IDE to be *WAY* too cluttered for
my tastes. But then that's true of a lot of programs with graphical
interfaces. Probably a YMMV thing.

Not to start a war here (I use vi/vim a fair bit myself, GUI programming
text editors quite a lot, *and* also full-blown IDEs), but what do _you_
consider to be an IDE exactly?

I just now separated "full-blown" IDEs from other categories, but that's
just because people seem to think that vim/emacs are somehow
intrinsically different from Notepad++/TextMate are somehow
intrinsically different from Eclipse/NetBeans/MonoDevelop/Code::Blocks.

Again, not to start a war here, but an IDE is an Integrated Development
Environment. It doesn't have to involve any GUI programs at all, in
theory. For example, I occasionally write Clojure in vim, and execute
snippets by sending them to a REPL in another terminal window using
screen. That's an IDE.

Being GUI or somewhat GUI or not GUI at all is an orthogonal question.
IDE != GUI.

For that matter, given that GUI usually means WIMP (window, icon, menu,
pointer), and one may be disposed to be critical of GUIs, what exactly
is one critical of? Especially when sporting a customized emacs
installation with windows, menus, text-based pseudo-icons, and a
rapidly-moveable cursor? ;-)

Let me put it this way, if we are arguing for simplicity of interface,
I've seen a lot of emacs setups that weren't.

AHS

 

[blmblm]

Yes. After years of your promoting primitive text-mode tools as
purportedly superior to everything else, you have begun to see the
light regarding at least 1 GUI app.

If I could find a text-mode tool that did as much as Eclipse did I'd
probably use it. What I like about Eclipse is not its interface --
I find it cluttered and not as keyboard-drivable as I like -- but
its features.

(You're starting to sound rather familiar, but I don't recognize the
name you're using. Have you used another name to post here?)

(And I decline to take the flamebait I think is implicit in "promoting"
and "purportedly superior".)

Well, since it's not a true application-integrated clipboard, it's
necessarily going to be limited, basically to what the app's currently
displaying at one time. You won't be able to go into a screen-oriented
editor and start a selection, go down two pages, end the selection
there, and copy.

There is that. I guess this is something that doesn't come up that
often for me; if I'm cutting and pasting large blocks of text I'm
more apt to be doing it entirely from vim. It is somewhat annoying
to have to mentally switch gears between "screen" cut and paste and

The "screen" program will only see a maximum of one
page at a time. With a line-oriented editor and a backscroll buffer of
some sort you could get more, except, well, line-oriented editor.
Bletch!

Ooh, there's an idea ....

There're two of them? And they didn't think to give them distinct
names? Typical.

You hadn't noticed that a lot of the traditional-UNIX tools have
multiple implementations, and the GNU implementations are apt to
have more features?

If the underlying app is screen-oriented then it must be.

And if not, not. "screen" maintains an output buffer that can be
scrolled through, and cutting and pasting from *that* isn't limited
to a screenful.

There'd be
no way for "screen" to know about scrolling or selections in that app,
and selections in itself will be limited to the current contents of
the app's display, and scrolling in itself won't work with screen-
oriented underlying apps.

and aren't likely to capture crud like
foo^]]E^]]D^Hquux ...

I have no idea what that "crud like ...." phrase is meant to convey;
it doesn't resemble anything I've observed happening with "screen".

Well, the only other way to make "screen"'s clipboard work, besides to
copy parts of the app's display output,

I'm inclined to think, based on observation, that this is what it's
doing.

is to copy either parts of the
app's raw output or its input. But the latter two will be full of
escape and control characters, at least in the case where the app is
screen-oriented, which will then tend to print like the garbage above.

Just out of curiosity, how much experience do you have with this
tool you're critiquing?

 

[blmblm]

What about "bonding" with a GUI?

When I say "bond" here, I'm talking about something that happens
during a formative period of one's life. I suppose it's just possible
to still have one of those at my advanced age, but it seems a bit
improbable.

As best I can remember I started using vi-based editors sometime in
the late 1980s. I'm not sure I have enough years left to get that
much experience with something else.

 

[blmblm]

Robert Klemme <[email protected]> wrote:

[ SNIP ]

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.

[ SNIP ]

"Refactoring", simply put, does not change the functionality of the
code. Leastways it's not supposed to.

Refactoring is done to achieve more clarity and simplicity and
maintainability (and perhaps testability). It could be as simple as
renaming a variable actually. That's purposeful refactoring.

Yes, yes .... I guess my point is that I'm often not convinced
that the changes I've made are actually an improvement, even with
regard to internal aspects such as clarity and maintainability --
they're *meant* to be, but whether they succeed I'm sometimes not
so sure. Sometimes it does feel like I'm just rearranging the
furniture.

 

[blmblm]

[ SNIP ]

s/career/something/ (I'm not a professional programmer these days.)

I find the interface of a typical IDE to be *WAY* too cluttered for
my tastes. But then that's true of a lot of programs with graphical
interfaces. Probably a YMMV thing.

Not to start a war here (I use vi/vim a fair bit myself, GUI programming
text editors quite a lot, *and* also full-blown IDEs), but what do _you_
consider to be an IDE exactly?

Possibly the person you really want to hear from here is the one who
recommended learning a couple of them, but ....

By "typical IDE" I mean something like Eclipse or NetBeans -- i.e.,
a big complicated program with a GUI.

I don't disagree that vim or emacs with the right plugins might qualify
as an IDE (using a somewhat literal-minded definition), but *typical*
IDE, maybe not so much?

I just now separated "full-blown" IDEs from other categories, but that's
just because people seem to think that vim/emacs are somehow
intrinsically different from Notepad++/TextMate are somehow
intrinsically different from Eclipse/NetBeans/MonoDevelop/Code::Blocks.

Again, not to start a war here, but an IDE is an Integrated Development
Environment. It doesn't have to involve any GUI programs at all, in
theory. For example, I occasionally write Clojure in vim, and execute
snippets by sending them to a REPL in another terminal window using
screen. That's an IDE.

Being GUI or somewhat GUI or not GUI at all is an orthogonal question.
IDE != GUI.

For that matter, given that GUI usually means WIMP (window, icon, menu,
pointer), and one may be disposed to be critical of GUIs, what exactly
is one critical of? Especially when sporting a customized emacs
installation with windows, menus, text-based pseudo-icons, and a
rapidly-moveable cursor? ;-)

Let me put it this way, if we are arguing for simplicity of interface,
I've seen a lot of emacs setups that weren't.

I can believe that.

(Yeah, yeah, good points, none of which I disagree with.)

 

[Robert Klemme]

If I could find a text-mode tool that did as much as Eclipse did I'd
probably use it. What I like about Eclipse is not its interface --
I find it cluttered and not as keyboard-drivable as I like -- but
its features.

Hm... I use keyboard shortcuts in Eclipse excessively. What are you
missing?

Kind regards

robert

 

[blmblm]

Hm... I use keyboard shortcuts in Eclipse excessively. What are you
missing?

Taking the question literally -- probably mostly a willingness to
appreciate this tool's strengths and not be too critical when it
behaves in some way that goes against my admittedly non-mainstream
preferences. Sort of a . Back to the point, though:

First I should probably say that my notion of "as keyboard-drivable
as I like" is "can do everything from the keyboard", which is a
fairly high bar. I've mentally bookmarked a lot of Eclipse's
keyboard shortcuts, and they make my experience of using this
tool much more pleasant, but there are still a few things ....
Examples that come to mind:

If I do a "synchronize with repository" operation and let Eclipse
switch to the CVS perspective or view or whatever it is (I have
trouble remembering which of those is which), I haven't figured
out how to easily get back to the "normal" (Java) view, other
than clicking a little ">>" button near the upper right corner
to display a list of other whatever-they-are. I did find a
keyboard shortcut (control-f8 IIRC) that *seemed* like it would
do what I want, but I can't seem to make it work. I could be
mistaken.

I think I did come across a way to set and clear debugging
breakpoints from the keyboard, but I didn't mentally bookmark it,
and trying to find it again .... well, I haven't.

In other words -- picky little stuff, possibly solvable with more
work on my part. What I said, or implied, about starting with
a better attitude ....

 

[Tom Anderson]

Taking the question literally -- probably mostly a willingness to
appreciate this tool's strengths and not be too critical when it behaves
in some way that goes against my admittedly non-mainstream preferences.
Sort of a . Back to the point, though:

First I should probably say that my notion of "as keyboard-drivable as I
like" is "can do everything from the keyboard", which is a fairly high
bar. I've mentally bookmarked a lot of Eclipse's keyboard shortcuts,
and they make my experience of using this tool much more pleasant, but
there are still a few things .... Examples that come to mind:

If I do a "synchronize with repository" operation and let Eclipse switch
to the CVS perspective or view or whatever it is (I have trouble
remembering which of those is which), I haven't figured out how to
easily get back to the "normal" (Java) view, other than clicking a
little ">>" button near the upper right corner to display a list of
other whatever-they-are. I did find a keyboard shortcut (control-f8
IIRC) that *seemed* like it would do what I want, but I can't seem to
make it work. I could be mistaken.

I think I did come across a way to set and clear debugging breakpoints
from the keyboard, but I didn't mentally bookmark it, and trying to find
it again .... well, I haven't.

The key thing (har har) to know is that all Eclipse's key bindings are
configurable, and that there are a great many commands it has which do not
have bindings by default.

My pet hate is that there are no keystrokes for the 'extract constant' and
'extract parameter' refactorings. It's not long after i sit down with an
unfamiliar Eclipse that i find myself binding them to the otherwise unused
alt-shift-K and alt-shift-P combinations (fitting neatly into the
alt-shift family, which operates the other refactorings).

You can examine and configure the key bindings in the 'Keys' page in the
preferences. Which you can reach without the mouse by typing the keystroke
to open the preferences window (command-, on the Mac; can't remember what
it is on Linux), then typing 'keys' and hitting return. The textbox at the
top of the page lets you search for commands by name; i don't think
there's a way to search by keystroke. You can then see what's bound, and
add bindings for things which aren't. There's a little window which shows
you any conflicts with bindings you add. You can set the context in which
they keystroke is bound; i believe 'In Windows' means it's bound
everywhere.

From this, i can see that, on the Mac, command-F8 selects the next
perspective, and shift-command-F8 the previous one. There are a set of
'Show Perspective (foo)' commands for all the perspectives (do not be
seduced by the commands called simply 'Java' and 'Java Browsing' - they
are false idols). On my machine, command-F1 to command-F6 are not bound
(in Eclipse), so they could be used.

Toggle breakpoint is command-shift-B. Open breakpoint properties (but only
when in the breakpoints view) is option-return.

tom

 

[Eight of Seventeen]

[ SNIP ]

s/career/something/ (I'm not a professional programmer these days.)

I find the interface of a typical IDE to be *WAY* too cluttered for
my tastes.  But then that's true of a lot of programs with graphical
interfaces.  Probably a YMMV thing.

Not to start a war here (I use vi/vim a fair bit myself, GUI programming
text editors quite a lot, *and* also full-blown IDEs), but what do _you_
consider to be an IDE exactly?

After having used, and gotten used to, modern software with a proper
user interface, why the hell would you ever use vi, or anything like
it, ever again? Serious question.

Again, not to start a war here, but an IDE is an Integrated Development
Environment. It doesn't have to involve any GUI programs at all, in
theory. For example, I occasionally write Clojure in vim,

Isn't that that new Lisp dialect? Ewwww.

and execute snippets by sending them to a REPL in another terminal
window using screen. That's an IDE.

Are you on crack? That's an IDE in much the way that four wheels, two
axles, and a big metal box all sitting around in a junkyard is a car.
In particular, you're obviously forgetting that the "I" in "IDE"
stands for "integrated".

For that matter, given that GUI usually means WIMP (window, icon, menu,
pointer), and one may be disposed to be critical of GUIs, what exactly
is one critical of? Especially when sporting a customized emacs
installation with windows, menus, text-based pseudo-icons, and a
rapidly-moveable cursor? ;-)

Bent talked about a bastardized half-breed emacs like that as well.
From his descriptions of its usage, trying to program with that would
be a nightmare ... no, vi is a nightmare; that thing would be more
like an anteroom of Hell Itself.

Let me put it this way, if we are arguing for simplicity of interface,
I've seen a lot of emacs setups that weren't.

You've seen an emacs setup that *was*?!

 

[Eight of Seventeen]

If I could find a text-mode tool that did as much as Eclipse did I'd
probably use it.

*sigh*

Stockholm syndrome?

I think we need someone in this thread that's better qualified to
diagnose things like that.

 What I like about Eclipse is not its interface --
I find it cluttered and not as keyboard-drivable as I like

Beats being so bare-boned that when a new user looks at it the sole
thought to enter their head is "what the **** do I do now?!". I'll
take slightly cluttered, but conducive to discovering the available
functionality (or, at the *very* least, discovering the goddamn help
and how to navigate and search it) anyday.

(You're starting to sound rather familiar, but I don't recognize the
name you're using.  Have you used another name to post here?)
Yes.

(And I decline to take the flamebait I think is implicit in "promoting"
and "purportedly superior".)

You consider the truth to be "flamebait"?

Interesting.

There is that.  I guess this is something that doesn't come up that
often for me; if I'm cutting and pasting large blocks of text I'm
more apt to be doing it entirely from vim.

Which strategy stops working as soon as you want to cut from vim and
paste into a non-vim application, of course.

 It is somewhat annoying to have to mentally switch gears between "screen"
cut and paste and vim cut and paste, but -- <shrug>.

Those of us using modern operating systems and user interfaces don't
have that problem, of course.

Interesting that you admit to finding it "somewhat" annoying, though.
Another sign of progress?

Ooh, there's an idea ....  

If I were a religious man, I'd be looking skyward and muttering
something about now.

You hadn't noticed that a lot of the traditional-UNIX tools have
multiple implementations, and the GNU implementations are apt to
have more features?

Of course. But they usually have changed names as well; cc -> gcc;
more -> less; yacc -> bison; and so forth.

And if not, not.  "screen" maintains an output buffer that can be
scrolled through, and cutting and pasting from *that* isn't limited
to a screenful.

If the app is not screen-oriented, then it is going to be incredibly
clumsy for editing purposes. If it is, any such buffer will either be
empty or chock-full of escape codes, either alternative of which will
spoil your day.

Just out of curiosity, how much experience do you have with this
tool you're critiquing?

A lot more than I would have if I had it all to do over again.

 

[Martin Gregorie]

After having used, and gotten used to, modern software with a proper
user interface, why the hell would you ever use vi, or anything like it,
ever again? Serious question.

Its a good idea to know at least how to get by with vi. Two reasons:

- it needs about the least terminal features to work correctly (this
includes being able to work without arrow or function keys), so if your
system gets completely borked you may need it to get out of the hole
without data loss.

- its colon command mode is very powerful and can make repetitive changes
much better than editors that don't understand regexes.

 

[Eight of Seventeen]

Its a good idea to know at least how to get by with vi. Two reasons:

- it needs about the least terminal features to work correctly (this
includes being able to work without arrow or function keys), so if your
system gets completely borked you may need it to get out of the hole
without data loss.

I'd rather pull my own teeth with a string tied to a doorknob. A much
easier method is to install the hard drive into a functional system as
a slave, then bring the full power of complex, modern tools to bear
upon fixing whatever troubled files are on it that need fixing.