Home » Language IDEs » Java Development Tools (JDT) » New plugin: Protocols---for more order in the class
| New plugin: Protocols---for more order in the class [message #117507] |
Mon, 17 November 2003 03:59  |
Eclipse User |
|
|
|
Originally posted by: sten-erik.bergner.telia.com
I have just released a plug-in called "Protocols" that addresses the lack of
support for internal organization of classes and interfaces, a thing that
has been bothering me as a heavy user of Eclipse/Java.
The main problem was simply this: to make related members (methods,
fields, etc.) appear together, in the browser views and in the source code.
If this problem was solved, a follow-up problem was then how to convey why
those members were appearing together, documenting the common denominator,
or putting a header on the group if you will.
With standard Eclipse, the only way of organizing methods, with any tool
support that I could find, was alphabetical order. So in large classes when
things became desperate, I found myself prefixing method names to achieve a
grouping affect. But because this makes the names ugly and the expressive
powers of prefixes are limited, I finally decided to do something to provide
a better solution.
I come from a repository-based-IDE background, so while the design
acknowledges the natural urge of placing related members together under a
common comment in the source code file, the capabilities aim to satisfy a
desire of editing structure in the browser views and not having to worry
about the source.
If you would like to know more, there's quite a bit of information on
http://www.bergner.se/protocols from where you can download the plug-in. And
yes, of course it comes with source, so if you're more interested in how
(rather than what and why) you are more than welcome to that part of it. In
fact, if you do look at my code and would like to discuss it, please don't
hesitate to drop me a line.
Cheers,
Sten-Erik
se.bergner@bergner.se
|
|
| | | | | | |
| Re: New plugin: Protocols---for more order in the class [message #119841 is a reply to message #119355] |
Mon, 24 November 2003 03:04  |
| Eclipse User |
|
|
|
Originally posted by: sten-erik.bergner.telia.com
Eric, welcome to the discussion. I thought I had a rather good grip on the
pros and cons of using headers vs. javadoc tags, but this is something new.
The problem is just that you are going to have to help me understand it.
With an established piece of source code shared by many programmers, one
doesn't perform major reorganizations just for the fun of it; so one of
course strives to get it right early on. I'm with you so far. But if the old
structure is so wrong that you just have to redo it, why should you not want
your coworkers to notice? To my mind, that would be the point of the
exercise.
When you're trying to get away with using a repository based tool like
VAJ in spite of everyone else on the team, you get burned by not having any
control over the source code file. But that doesn't seem to relate so much
to the Protocols plug-in that we are talking about here. If it does, is
pretty much the other way around: If you move a method, it moves; if you let
alone, it stays put. Here order is of essence, not arbitrarily as with VAJ.
I'm not denying that a javadoc tag based solution does have merits, but
mostly for a technical point of view, and I was surprised to find the
interface between Eclipse users and, say, Emacs users being advocated as one
of them. If we could peruse this issue, I for one would be grateful.
Cheers,
Sten-Erik
"Eric Rizzo" <eclipse-user@jibeinc.com> wrote in message
news:bplfr1$fuh$1@eclipse.org...
> Sten-Erik Bergner wrote:
>
> > "Eric Estievenart" <eric.estievenart@peregrine.com> wrote in message
> > news:opryry6bzv9ck0a6@news.eclipse.org...
> > [snip]
> >
> >>Also extending a bit the javadoc tags could help in generating
> >>logically grouped documentation.
> >
> >
> > I agree, using a javadoc tag per member holds many attractions. The
reason I
> > chose the techinque with comments was that it is more obvious to anyone
> > confonted with the bare source code.
>
> That is somewhat true. But it is also a fact that many people get upset
> when they find methods have been re-ordered significantly. Eclipse users
> won't notice or care, because Eclipse makes navigating a class' methods
> easy, but team members who don't have such a tool will inevitably gripe
> the first time they see classes that have been re-ordered.
>
> I speak from first-hand experience. I was the only VAJ user on several
> teams and heard complaints from other developers when I would export
> changed code from VAJ into our SCM system.
>
> I vote for using JavaDoc comments, with an option to group methods
> together as the current version does. The key is to make re-ordering of
> methods be optional.
>
> Eric
> --
> Eric Rizzo
> Software Architect
> Jibe, Inc.
> http://www.jibeinc.com
>
|
|
| |
| Re: New plugin: Protocols---for more order in the class [message #120312 is a reply to message #119841] |
Mon, 24 November 2003 12:50 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-user.jibeinc.com
Sten-Erik Bergner wrote:
> Eric, welcome to the discussion. I thought I had a rather good grip on the
> pros and cons of using headers vs. javadoc tags, but this is something new.
> The problem is just that you are going to have to help me understand it.
>
> With an established piece of source code shared by many programmers, one
> doesn't perform major reorganizations just for the fun of it; so one of
> course strives to get it right early on. I'm with you so far. But if the old
> structure is so wrong that you just have to redo it, why should you not want
> your coworkers to notice? To my mind, that would be the point of the
> exercise.
>
> When you're trying to get away with using a repository based tool like
> VAJ in spite of everyone else on the team, you get burned by not having any
> control over the source code file. But that doesn't seem to relate so much
> to the Protocols plug-in that we are talking about here. If it does, is
> pretty much the other way around: If you move a method, it moves; if you let
> alone, it stays put. Here order is of essence, not arbitrarily as with VAJ.
>
> I'm not denying that a javadoc tag based solution does have merits, but
> mostly for a technical point of view, and I was surprised to find the
> interface between Eclipse users and, say, Emacs users being advocated as one
> of them. If we could peruse this issue, I for one would be grateful.
I am happy to explore this issue with you more, even though I can't use
the plug-in right now (I'm still on Eclipse 2.1).
I think the best way I can explain why I don't like the current
implementation as much as using JavaDoc tags instead is this:
In the current implementation, there is a mixing/coupling of two
different "interfaces" (or concerns). One "interface" is the
categorization of methods - that is the primary thing the plugin
provides over regular Eclipse. The other "interface" that is getting
mixed in is the grouping of source code in the actual file.
I think it is more appropriate to separate these two "interfaces" or
concerns so that putting a method in a certain category does not
necessarily put it into a particular place in the file. The method
categories are really intended to be used by your specialized view in
the Java perspective, so where the methods reside in the file is not
important for that. It is like have an interface in Java and a concrete
implementation. De-couple your implementation (moving source code in the
file) from the interface it provides (logical categorization of methods).
I do see the value of having an option to group methods of the same
category together in the file, but I don't care for the fact that doing
so is absolutely tied to the other feature of categorizing methods.
Here's another way to put it: categorization is a logical grouping,
while file-ordering is a physical grouping. Those two don't have to be
coupled together - make them independent of each other and let the user
decide if they are coupled together. By doing that, you have have made
it more flexible and thus more likely to be used by more developers.
Hope this conveys my perspective a little better.
Eric
BTW, I do not want it to seem that I don't like this plug-in. I do like
the idea very much. I would almost certainly be using it if I were on
Eclipse 3.x. I'm just trying to help you understand all points of view
so you can produce the best product possible - in the end it is your
decision to make.
--
Eric Rizzo
Software Architect
Jibe, Inc.
http://www.jibeinc.com
|
|
|
| Re: New plugin: Protocols---for more order in the class [message #120705 is a reply to message #120312] |
Tue, 25 November 2003 03:43 |
| Eclipse User |
|
|
|
Originally posted by: sten-erik.bergner.telia.com
Eric, thanks for putting time on this issue. I think I understand your view
now and I sympathize with your architectural approach. Yet my opinion is
that it cannot be adequately realized.
You say: "categorization is a logical grouping, while file-ordering is a
physical grouping. Those two don't have to be coupled together - make them
independent of each other and let the user decide if they are coupled
together."
This sounds great, but I claim that what you state is (unfortunately so)
infeasible. It's the word "if" (number five from the end) that is causing
the problem. Replace it with "how" and we're in perfect agreement.
Categories, however abstract and decoupled from the physical world, must
still be represented in the source code file to survive. And the crux is
that there exists no way of doing that which is (1) invisible and (2) immune
to editing by those who know not or care not. Yet your reasoning implies
that tagging would suffice in this respect. As far as I can tell this is the
one thing that we are not in absolute agreement on: that tagging is so
inconspicuous that using it as a base representation, from which all other
representations can be generated, is an acceptable architecture.
My stand point is this: There exists no representation that does not
require involvement on the part of the users of the source code. Therefore
if the users finds grouping more attractive than tags, grouping should be
offered without tags.
This does not preclude support for tags as an alternative to grouping,
or of course even both in ensemble for those who really wanted it all.
Extending in this direction is one of obvious ways to develop the Protocols
plug-in further. I can't promise that this is something that I will do, but
then maybe someone else will.
Sten-Erik
"Eric Rizzo" <eclipse-user@jibeinc.com> wrote in message
news:bptga3$27r$1@eclipse.org...
> Sten-Erik Bergner wrote:
>
> > Eric, welcome to the discussion. I thought I had a rather good grip on
the
> > pros and cons of using headers vs. javadoc tags, but this is something
new.
> > The problem is just that you are going to have to help me understand it.
> >
> > With an established piece of source code shared by many programmers,
one
> > doesn't perform major reorganizations just for the fun of it; so one of
> > course strives to get it right early on. I'm with you so far. But if the
old
> > structure is so wrong that you just have to redo it, why should you not
want
> > your coworkers to notice? To my mind, that would be the point of the
> > exercise.
> >
> > When you're trying to get away with using a repository based tool
like
> > VAJ in spite of everyone else on the team, you get burned by not having
any
> > control over the source code file. But that doesn't seem to relate so
much
> > to the Protocols plug-in that we are talking about here. If it does, is
> > pretty much the other way around: If you move a method, it moves; if you
let
> > alone, it stays put. Here order is of essence, not arbitrarily as with
VAJ.
> >
> > I'm not denying that a javadoc tag based solution does have merits,
but
> > mostly for a technical point of view, and I was surprised to find the
> > interface between Eclipse users and, say, Emacs users being advocated as
one
> > of them. If we could peruse this issue, I for one would be grateful.
>
> I am happy to explore this issue with you more, even though I can't use
> the plug-in right now (I'm still on Eclipse 2.1).
>
> I think the best way I can explain why I don't like the current
> implementation as much as using JavaDoc tags instead is this:
> In the current implementation, there is a mixing/coupling of two
> different "interfaces" (or concerns). One "interface" is the
> categorization of methods - that is the primary thing the plugin
> provides over regular Eclipse. The other "interface" that is getting
> mixed in is the grouping of source code in the actual file.
> I think it is more appropriate to separate these two "interfaces" or
> concerns so that putting a method in a certain category does not
> necessarily put it into a particular place in the file. The method
> categories are really intended to be used by your specialized view in
> the Java perspective, so where the methods reside in the file is not
> important for that. It is like have an interface in Java and a concrete
> implementation. De-couple your implementation (moving source code in the
> file) from the interface it provides (logical categorization of methods).
> I do see the value of having an option to group methods of the same
> category together in the file, but I don't care for the fact that doing
> so is absolutely tied to the other feature of categorizing methods.
>
> Here's another way to put it: categorization is a logical grouping,
> while file-ordering is a physical grouping. Those two don't have to be
> coupled together - make them independent of each other and let the user
> decide if they are coupled together. By doing that, you have have made
> it more flexible and thus more likely to be used by more developers.
>
> Hope this conveys my perspective a little better.
> Eric
>
> BTW, I do not want it to seem that I don't like this plug-in. I do like
> the idea very much. I would almost certainly be using it if I were on
> Eclipse 3.x. I'm just trying to help you understand all points of view
> so you can produce the best product possible - in the end it is your
> decision to make.
>
> --
> Eric Rizzo
> Software Architect
> Jibe, Inc.
> http://www.jibeinc.com
>
|
|
| |
Goto Forum:
Current Time: Fri May 09 08:56:05 EDT 2025
Powered by FUDForum. Page generated in 0.06973 seconds |
Home