Eclipse Zwei Funktionen in Eclipse gesucht

[Marco13]

Hallo

Es gibt zwei Funktionen, die ich in Eclipse manchmal vermisse. Vielleicht weiß jemand, ob es die doch irgendwo ganz versteckt gibt:

1. Ein case-erhaltendes "Replace all": Wenn man in einem Stück Quelltext z.B. solche Zeilen hat wie

private SomeSpecialClass specialClass = null;

/** Finds the given specialClass */
private void findSpecialClass(SpecialClass specialClass) { ... }

dann kommt es gelegentlich vor, dass man etwas umbenennen will, und z.B.
- alle Vorkommen von "SpecialClass" ersetzen will durch "NormalClass"
- alle Vorkommen von "specialClass" ersetzen will durch "normalClass"
Beim "Refactoring" kann man da zwar schon einiges machen, indem man "similar named elements" und "textual occurances" mit ersetzt, aber ein REIN textuelles Ersetzen mit case-Erhaltung habe ich noch nicht gefunden...


2. Automatische Privatisierung: Ich fände es toll, wenn es eine Funktion gäbe, mit der man einfach und elegant die Klassen und Methoden auswählen könnte, die "public" sein sollen, und alles andere automatisch "so privat wie möglich" gemacht wird. Also alles, was private sein kann, wird private, alles was höchstens package-private sein kann, wird package-private, und alles was höchstens protected sein kann, wird protected. Beim Entwickeln und/oder häufigem hin-und-her-Schieben von Klassen (oder auch einfach durch "Unachtsamkeit" ) während der Entwicklung kommt es bei mir öfter mal vor, dass Sachen etwas "publicer" werden, als sie rein formal sein müßten. Ich denke, dass das etwas ist, was man eigentlich relativ leicht automatisieren könnte, wenn man sich ein bißchen mit den JTDs innerhalb von Eclipse auskennt. Gibt es sowas vielleicht schon als Plugin oder so?

Bin gespannt auf eventuelle Tipps

 

[Wildcard]

1. Da du 'rein textuell' schreibst möchtest du wirklich Find und Replace und nicht etwa refactoring, richtig? In dem Fall, der Search Dialog erlaubt auch Regex und das Replace Feld erlaubt capturing Groups. Du kannst also einen case insensitiven Regex verwenden, an entsprechender Stelle ein oder mehrere Capturing Groups setzen und diese dann im Replace Feld mit $1 $2 usw ersetzen.

2. Da kenne ich leider nichts, wäre aber ein guter Vorwand mal in die Plugin Entwicklung reinzuschnuppern

 

[headset]

1.Wenn du etwas umbenennen möchtest, z.B. ne Variable, musst du diese bloß anklicken und alt+shift+r drücken, kannst nen neuen Namen eingeben und dann musst du noch enter drücken.
Dann ändert die Variable den Namen und überall wo du sie verwendest ändert er sich auch.
Wenn du das meinst.

2. Ich weiß nichts von so einer Funktion, aber das wär irgenwie schon genial.

Ich hoffe, ich konnte helfen.
LG
Headset

 

[Marco13]

Du kannst also einen case insensitiven Regex verwenden, an entsprechender Stelle ein oder mehrere Capturing Groups setzen und diese dann im Replace Feld mit $1 $2 usw ersetzen.

Dass das mit Regex irgendwie geht, hatte ich schon befürchtet Vermutlich ist es zu speziell und (wenn man weiß, wie es geht) zu "einfach", als dass es dafür eine spezielle Funktion gäbe. Vielleicht reicht es da, sich EINmal das allgemeine Muster zurechtzupfrienmeln, mit dem man "so eine" Ersetzung machen kann, und das dann immer anzuwenden ... mal schauen, ob ich das hinkriege :rtfm:

2. Da kenne ich leider nichts, wäre aber ein guter Vorwand mal in die Plugin Entwicklung reinzuschnuppern

Ja, ich hatte auch schon ewig mal vor, das zu tun Vielleicht wäre das ja ein geeigneter Anfang: Es wäre (vermeintlich) einfach, und gleichzeitig nützlich. Aber auch da müßte ich erstmal :rtfm:en. Mit dem JDT hatte ich mich zwar schon ein bißchen beschäftigt, aber mit Pluginentwicklung im speziellen bisher noch nicht...


EDIT: @headset: Reines Umbenennen geht natürlich immer, ich meinte aber eine Funktion mit der aus dem Code

// Das ist einTest
EinTest einTest;
void dasIstEinTest() { ... }

der Code werden könnte:

// Das ist keinTest
KeinTest keinTest;
void dasIstKeinTest() { ... }

 

[Wildcard]

Ach, irgendwie ist mit vorhin die Tücke an deinem Beispiel entgangen.
Es ist kein Problem SpecialClass case sensitiv zu ersetzen mit SuperSpecialClass, bei NormalClass sieht es dann aber leider anders aus.
Vielleicht gibt es dafür einen Regex Trick, aber da fällt mir leider auch nichts ein. Wieder mal ein Fall für ein Plugin

 

[Marco13]

Mit der "Tücke" meintest du wohl, dass eben aus einem "s" ein "n" und einem "S" ein "N" werden müßte, und das mit Capturing Groups auch nicht sooo ohne weiteres geht... Ja, das ist das Hauptproblem Aber irgendwie könnte es ja doch hinzukriegen sein, zumindest für spezielle Fälle...

 

[Marco13]

... Plugin Entwicklung ...

Ja... Es wäre (vermeintlich) einfach

OK, und diejenigen, die sich schonmal mit Plugin-Entwicklung beschäftigt haben, können jetzt langsam mal aufhören, zu lachen...

 

[Marco13]

Und um mein leicht angefrustetes Selbstgespräch mal weiterzuführen: Ich bin in den letzten Tagen zu dem Schluß gelangt, dass Eclipse (mit seinen Plugins) wohl die komplexeste Software sein muss, die je von Menschen geschrieben wurde :rtfm: Wie konnten die Leute sowas komplexes entwickeln? Die hatten dafür ja nicht mal sowas wie Eclipse... :reflect:

:joke:

 

[maki]

Nicht wundern Marco13,

wenn man OSGi, Eclipse RCP, die Eclipse Extensions inkl. Extension Points verstanden hat, ist es wohl wirklich nicht mehr schwer
Dann müsste man nur noch wissen wie das Refactoring in Eclipse funktioniert.

Hab das hier auf die schnelle gefunden: Writing a new refactoring plugin for Eclipse? - Stack Overflow
Aber den hast du bestimmt selber auch schon gefunden

 

[Marco13]

Ja, diese Stichworte sind eben in den letzten Tagen an meinem Horizont aufgetaucht. Mit dem JDT hatte ich schon ein bißchen was gemacht, mal ein ÄSTchen gebaut und ein bißchen rum-besucht, aber das zusammen mit den Refactorings an sich :shock: Es ist ja auch nicht so, dass es an Information mangelt ... :rtfm: Aber die paar hundert Packages, die mit Refactoring zu tun haben und das Zusammenspiel der paar tausend Klassen aus diesen Packages nachzuvollziehen ist nicht leicht - speziell weil die eingebauten Refactorings auch noch viele der "internen" Klassen verwenden, die man bei eigenen Sachen nicht verwenden sollte ... und wenn man einen Dialog anzeigen will, kommt noch ein bißchen SWT dazu ... *schwitz* :rtfm: (Gerade hab' ich die 40 Tabs aus einem meiner Firefox-Fenster gebookmarkt - für heute reicht's )

 

[Sonecc]

Die hatten dafür ja nicht mal sowas wie Eclipse... :reflect:

:joke:

Sie haben es ja soweit programmiert, dass es lauffähig war und dann haben sie eclipse genutzt.
Mit e4 läuft es glaub ich genauso.
Sie haben das Grundgerüst gebaut und entwickeln e4 nun in e4 (wo ich das gelesen hab, weiß ich leider nimmer)

 

[Marco13]

Deswegen auch der " :joke: " Das sollte nicht zuletzt darauf anspielen, dass man so eine Software wohl kaum noch handhabbar halten kann, wenn man nicht die Möglichkeit hat, sie modular weiterzuentwicklen. Wenn man anfängt, die Sources im SVN-Viewer zu browsen (weil man sich nicht traut, ein komplettes Checkout zu machen), merkt man erst, wie hilfreich es es, wenn man z.B. "mal kurz" alle Referenzen auf eine Methode suchen kann - aber wenn man die Sourcen durchsieht, um herauszufinden, wie z.B. genau das funktioniert, merkt man, dass die Mechanismen, die da dahinter stecken, sind trotz (oder gerade wegen) der Allgemeingültigkeit, mit der sie implementiert sind, ad hoc erstmal schwer nachzuvollziehen sind...

 

[Marco13]

Vielleicht liest das noch jemand: Eine Dritte Funktion die man irgendwie dauernd braucht: Für ein gegebenes Interface eine "Default"-Implementierung erstellen:

interface SomeInterface
{
    int getType();
    String getName();
}

->

class DefaultSomeInterface implements SomeInterface
{
    private int type;
    private String name;

    @Override
    public int getType()
    {
        return type;
    }

    @Override
    public String getName()
    {
        return name;
    }

    // und noch die setter dazu, ist mir zu lästig, deswegen frag' ich ja ... ;-)
}

Natürlich kann man das mit einer Klasse und ein paar Fields und "create setters and getters" nachbauen, aber ... Vermutlich wird man da auch wieder selbst Hand anlegen müssen...?