Newsgroup: it.comp.java
Titolo: uno stupido dubbio.

Salve.
Sto iniziando solo ora con java e sto provando piccoli esempi trovati in 
vari manuali.
Uno degli esempi e' questo:
public class prova {
   public static void main(String[] args) {
     A a = new A();
     a.metodo();
     B b = new B();
     b.metodo();
     System.out.println("Esecuzione della classe " + b.class_type);
   }
}
le classi A e B sono:
public class A {
   String class_type;
   public A() {
     class_type = "A";
   }
   public void metodo() {
     System.out.println("Messaggio della classe A");
   }
}
public class B extends A {
   String class_type;
   public B() {
     class_type = "B";
   }
   public void metodo() {
     System.out.println("Messaggio della classe B");
   }
}
come si nota nella classe princilale prova c'e' un 
System.out.println("Esecuzione della classe " + b.class_type);
La domanda e': ma per accedere al contenuto di una varialbile non 
bisogna creare un metodo apposito?

music ha scritto:

Non *bisogna* ma e' cosidetta *buona programmazione*.
Sostanzialmente dipende da come sono dichiarate le variabili:
se sono private vi si puo' accedere solo dall'interno della classe,
classi "clienti" posso manipolare tali variabili solo con i metodi.
Parti da questo concetto: immagina ogni classe come una scatola chiusa 
con dei bottoni.
Chi usa quella classe non deve aver bisogno di sapere cosa c'e' 
all'interno della scatola, gli basta sapere cosa fanno i bottoni.
Su questo principio si basano ad esempio le classi interface.
Concettualmente ogni classe che si realizza dovrebbe essere utilizzabile
da chiunque avendo una descrizione dei suoi metodi (esattamente come per
le api di java)
All'atto pratico pero' ti capiterà di scrivere classi con moltissimi 
parametri e non avrai voglia di scrivere metodi per tutti (almeno io
non ce l'ho).
Ma questa *non è* buona programmazione

 non ce l'ho).
Click destro -> "Generate getter/setters" ... O forse non usi Eclipse :D ?

Giambo ha scritto:

ehm....
devo ammettere la mia colossale ignoranza ^^
da quello che mi par di capire e' un tool di sviluppo?
dovro' provarlo

 dovro' provarlo
Da quando sono passato da "vi" a Eclipse, la produttivita' e' aumentata 
in maniera considerevole. Se penso agli anni passati a sviluppare con un 
semplice editore testi, non riuscirei a tornare indietro :)

 writes:
G> Da quando sono passato da "vi" a Eclipse, la produttivita' e'
G> aumentata in maniera considerevole. Se penso agli anni passati a
G> sviluppare con un semplice editore testi, non riuscirei a tornare
G> indietro :)
<religion-war>
Solo perché sei partito con l'editor sbagliato, non è colpa dei buoni
editor.
Quello che uso io si fa ancora preferire ad Eclipse (e si, mi genera
i getter ed i setter... :) )
</religion-war>
Fuori dalla  guerra di  religione, la componente  editor di  Eclipse è
scarsa. Tanti  bei fischietti e  campanelli, ma quanto ad  editor come
tale è notepad.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a 
fn...@rat.vg

 
LOL! ahaha, ma che stai dicendo...

 </religion-war>
ah, un altro emacsiano...
vi 4ever!!!
Ciao Jack

> 
CA> LOL! ahaha, ma che stai dicendo...
Che come text editor, nonostante campanelli e fischietti, quello di
Eclipse č dannatamente limitato rispetto ad un buon editor. Perché
quando č ora di fare qualcosa in piů di un banale search & replace
ti trovi a dover ripetere N volte la stessa serie di movimenti, non
a dire all'editor "fai N volte questa serie di movimenti".
Attento, sai bene dove abbonda il riso, e lo stai dimostrando...


 writes:
J> ah, un altro emacsiano...
J> vi 4ever!!!
St.  Ignucius  ci  insegna che  usare  vi  non  è  un peccato,  è  una
penitenza. Che  puoi mai  aver fatto  di grave da  dover usare  vi per
tutta l'eternità, fratello?


 tutta l'eternità, fratello?
sono obbligato ad usare win al lavoro...

 writes:

J> sono obbligato ad usare win al lavoro...
Povera vittima oppressa!!! Hai il mio sostegno e la mia pietà per il
crudele stato in cui ti tengono. Che St. Ignucius ti conceda la grazia
di un S.O. degno di questo nome!
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a 
fn...@rat.vg
P.S.
Ma almeno Cygwin te la lasciano usare ?

 di un S.O. degno di questo nome!
al momento faccio finta: ho installato cygwin ;)
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 tale è notepad.
Oddio, un editor che mi permetta il CTRL+freccia o CTRL+ALT+freccia o 
CTRL+SHIFT+freccia o l'identazione intelligente o ... beh, non l'ho 
ancora trovato ;)
Cosa ti manca di preciso nell'editore di Eclipse ?

emacs per quel poco che l'ho utilizzato devo dire che non rallenta
nemmeno un pò il sistema... a differenza di quel mattone di roba che
eclipse come altri Ide caricano.
Io mi "punisco" utilizzando Java Studio Enterprise 8 per 2 semplici
motivI:
     ho un canale di comunicazione efficiente che mi permette di
scambiare materiali e sorgenti con i miei compagni di corso
dell'università (cosa che ad Eclipse manca)...
     mi serve qlc di specifico su java e che mi permetta di creare le
GUI da subito, senza rimbecillirmi a trovare il plugin e senza dover
pregare che funzioni dopo l'istallazione (proprio come Eclipse,
vero?)...
Ciao Marco

 vero?)...
Il GUI creator di Eclipse e' il suo punto debole. Ma se come me sviluppi 
Swing da "zero" o se sviluppi applicazioni WEB, allora Eclipse va piu' 
che bene.
Poi alla fine e' questione di gusti: Ho usato Eclipse sin dalla sua 
prima versione "open" e oramai mi ci sono affezionato. Ho pure provato 
IntelliJ, che pare essere l'IDE per eccellenza, ma forse sono troppo 
vecchio per cambiare abitudini :)
Un IDE invece che non ho mai sopportato e' JBuilder: Ho dovuto usare la 
versione 7 (o era la 9 ?) per qualche tempo ma poi e' uscito Eclipse 2.0 
e tutta la ditta ha deciso di "switchare" ;)

> tale è notepad.
G> Oddio, un editor che mi permetta il CTRL+freccia o CTRL+ALT+freccia
G> o CTRL+SHIFT+freccia o l'identazione intelligente o ... beh, non
G> l'ho ancora trovato ;) Cosa ti manca di preciso nell'editore di
G> Eclipse ?
È che  Eclipse si ferma  lì. Tu ti  accontenti del limitato  numero di
comandi di CUA. Se me lo permetti, visto che lo ho disponibile, uso un
set di funzionalità più  ricco. Per farne una descrizione superficiale
ed introduttiva ci metto un talk di un'ora abbondante ;).
Eclipse inoltre  non va oltre quello  che offre se non  in una maniera
non proprio  facile facile, che è vero  si che puoi fare  i plugin, ma
non puoi,  ad esempio, pluggare l'editor e  fare un plug in  non è una
cosa immediata.  Ed essendo  Java compilato -  e dato che  Eclipse non
include la beanshell, non hai "il linguaggio immediatamente esposto".
Verissimo, fare un  modo di qualità per Emacs  non è immediato nemmeno
quello,  ma  immediatamente  puoi  creare  quella  cosina  orrida  che
trasforma  il manovrare  un editor  per qualche  ora nel  più creativo
scrivere una decina di linee di codice.
Nota: Ecliplse in questo momento  è aperto in un altro workspace. C'è,
lo uso,  ma non per l'editing serio.  Offre altre cose e  sarei mona a
non usarle.


 writes:
SS> emacs per quel poco che l'ho utilizzato devo dire che non rallenta
SS> nemmeno un pň il sistema...
La  cosa  era  vera  una  volta.   Emacs  č  grosso,  non  lo  si  puň
negare.  L'eseguibile usato  correntemente č  il dump  di  una virtual
machine LISP che viene ripristinata all'avvio del programma, con tutta
una serie di funzioni precaricate.
Rimane  piů leggero delle  varie IDE  che ho  usato, salvo  quella del
Watcomm  C/C++ che  peraltro NON  includeva  un editor  (ne dava  uno,
peraltro vi compatibile, se proprio non ne avevi uno disponibile).


 ed introduttiva ci metto un talk di un'ora abbondante ;).
Oh, tanto credo che gli altri frequentatori del NG non seguano piu' 
questo thread, fai pure. Oramai l'OT c'e', tanto vale andare fino in 
fondo, no ;) ?
Mi piacerebbe sapere che cosa mi perdo usando l'editor di Eclipse, 
magari riesci a convertirmi a emacs :) !

> comandi di CUA.
G> Si, e' vero, mi bastano :) Se posso scrivere codice senza dover
G> usare il mouse, sono contento.
Emacs è fatto per usare la tastiera, anche se supporta pienamente il
mouse.
G> Oh, tanto credo che gli altri frequentatori del NG non seguano piu'
G> questo thread, fai pure. Oramai l'OT c'e', tanto vale andare fino
G> in fondo, no ;) ?  Mi piacerebbe sapere che cosa mi perdo usando
G> l'editor di Eclipse, magari riesci a convertirmi a emacs :) !
Beh, ho un po' di tempo.
Se noti,  uso Emacs  anche per fare  altre cose (i.e.  scrivere questo
post)  oltre  che  per   programmare,  e  continuo  ad  usare  Eclipse
principalmente  per il  debug, ma  anche le  compilazioni  e l'editing
minore.
Emacs, dal canto suo, ha 30  anni di esperienza nel text editing dalla
sua.
Formattazione (e  più sveglia di quella  di Eclipse, che  quando TAB è
configurato per  formattare manda  il testo esattamente  nella colonna
dove  deve andare),  evidenziazione  sintattica, copia  ed incolla  li
diamo per assodati. Emacs ha una fortissima configurabilità di come tu
vuoi  che appaiano  i vari  elementi, e  lascia una  porta  aperta per
aggiungere nuove regole  (in realtà lui lavora su  tre passi: funzione
sintattica del  carattere, funzioni  attivate in presenza  di elementi
sintattici e riconoscimento di parole chiave tramite regexp).
Volendo opera su rettangoli di testo.
Il controllo delle  parentesi di Emacs è configurabile  come aspetto e
può essere molto più evidente di quello di Eclipse.
Per il  search'n'replace, il modo di  operare di Emacs  non usa dialog
box  ed  inoltre permette  di  usare  espressioni  regolari.  La  cosa
permette di fare con un  search'n'replace quello che al limite faresti
con una macro (Emacs,  se non usi il mouse, non usa  dialog. E con una
buona  completion dei nomi,  non uso  nemmeno la  vista ad  albero dei
file, che peraltro c'è).
Usualmente il  search semplice è  fatto in forma incrementale  (con la
possibilità  di includere  in un  colpo  nel pattern  tutta la  parola
correntemente  individuata)  ma offre  comandi  per  fare una  ricerca
secca.
Il search'n'replace è interattivo come  quello di Eclipse, ha anche un
metodo che brutalmente parte e rimpiazza tutto (come in vi).
Macro.  In  Emacs definire una  macro è una  operazione semplicissima,
dalla  versione  22  (siamo  alla  22.0.96) o  dalla  21,  invocazioni
successive della stessa macro vengono semplificate (basta continuare a
premere  e).  Rimane  possibile,  come per  qualsiasi  altro  comando,
eseguirlo N volte dicendo prima quale è l'N.
Una cosa  sulle macro.  Ci  sono modi per  salvarle, ma una  macro può
essere tradotta  rapidamente in una  funzione (EmacsLISP) dato  che in
Emacs ogni pressione di un tasto in realtà invoca una funzione. Quindi
basta  chiedere  all'editor  quale  funzione è  richiamata  dal  tasto
(Contol-H K e poi il tasto/combinazione di tasti per dirla tutta) e si
sa quale è la funzione, e saputo il nome si può sapere come usarla.
Un paio di parole relativamente a Java.
Ho già detto che ha la visualizzazione ad albero dei file (non la uso,
richiede il mouse).
Il modo  base per Java non  fa molto, ma  usando JDEE non si  sente la
mancanza  delle feature di  editing Eclipse  (completamento dipendente
dal  tipo, import automatica,  override dei  metodo...).  Non  mi pare
ancora che ci sia pronta  una funzione di refactoring alla Eclipse (ma
probabilmente  ci  si arriva  facilmente  usando l'indicizzazione  dei
simboli  di Etags),  in  compenso  ho avuto  occasione  di rifare  "in
automatico" il 90% del refactoring  dovuto al fatto che una classe del
framework usato  era stata sostituita con un'altra.  A lavoro concluso
mi sono reso  conto che se avessi saputo prima cosa  fare, tra Emacs e
shell (per trovare i file da elaborare) avrei fatto fare alla macchina
il 100% del lavoro, ottenendo un tool generale per aggiornare tutte le
applicazioni del  cliente che ancora  usavano la vecchia  versione del
framework.
Naturalmente è possibile lanciare la  compilazione (o del file o di un
progetto con  ant) da dentro  Emacs e poi  portarsi alle righe  su cui
sono stati segnalati gli errori.
Ah,  mi sono  scritto  un paio  di  funzioni per  ricompilare in  modo
automatico la definizione del classpath di un progetto partendo dalla
directory dei jar esterni (lavoro principalmente con applicaizoni web
based).
Queste  sono  solo due  parole,  se ti  va  di  contattarmi per  posta
elettronica, l'indirizzo giusto  è sotto la firma, usa  il cifrario di
Cesare per portarlo in chiaro.


 
Direi che stai dimostrando TU di non conoscerlo a dovere. Probabilmente ti sei 
limitato ad osservarne le funzionalita' di search e replace, non perdero' di 
certo a fartene notare gli altri vantaggi, ma cosi come tu programmi il tuo 
Emacs io e tutti gli altri che lo usano facciamo lo stesso con Eclipse, con un 
sistema sotto giusto due righe piu' potente.. che Emacs Lisp sia un linguaggio 
piu espressivo ed agevole, sono il primo a constatarlo. Ma non dire che l'editor 
e' "dannatamente limitato", senno sembra che ridi piu' di me!
Peace and love :)

> 
CA> Direi che stai dimostrando TU di non conoscerlo a
Dici male. Dici  molto male. Forse la prossima  volta conviene leggere
qualche  altro  post  prima  di  partire a  rispondere  sentendosi  il
campione della cosa giusta.


 campione della cosa giusta.
I post infatti li ho letti tutti e di certo non mi sento il campione della cosa 
giusta (o perlomeno non vado a sbandierare ai 4 venti quanto il mio editor sia 
fico!), constatavo il fatto che secondo me hai sottovalutato le potenzialita' di 
un editor che tu consideri scarso e limitato. Come spero ma non credo tu abbia 
capito, non mi stavo riferendo all'editor _in se_: chiunque puo' aprire i vari 
menu ed usarne le funzionalita'. Mi riferivo alle API che permettono di 
estenderlo ed istruirlo, ovviamente. Piu rapide di quelle di emacs? 
assolutamente no. Ma se le conosci, le hai usate, e continui a ritenerle scarse 
e limitate, beh, allora non posso proprio farci niente!
Adios

 writes:
CA> I post infatti li ho letti tutti e di certo non mi sento il
CA> campione della cosa giusta (o perlomeno non vado a sbandierare ai
CA> 4 venti quanto il mio editor sia fico!),
Non è il mio editor. E l'editor che uso come lo usano molti altri, e
ne traggono giovamento dalla potenza.
CA> secondo me hai sottovalutato le potenzialita' di un editor che tu
CA> consideri scarso e limitato.
L'_editor_ di  eclipse è scarso e  limitato. Non Eclipse.  Ed è scarso
nonostante gli automatismi (tanti) inseriti.  Se metà del tempo che ci
hanno messo a fare quegli automatismi lo avessero dedicato all'editing
puro, Eclipse sarebbe un ambiente di gran lunga migliore.
Peraltro questo è un difetto che  ho riscontrato in _tutte_ le IDE che
mi sono capitate davanti. L'unica,  ripeto, era quella del Watcom che,
pur dandoti  un editor  a disposizione -sai  mai che non  avessi altre
scelte che notepad- aveva costruito  il suo ambiente in modo che fosse
possibile utilizzare un qualsiasi editor.
E qui non ho ancora toccato  la parte di estendibilità. Non ho nemmeno
toccato  le parti  relative ai  modi per  un dato  linguaggio.  Mi sto
limitando a quello che è l'editing con il programma nudo e crudo.
CA> capito, non mi stavo riferendo all'editor _in se_: chiunque puo'
CA> aprire i vari menu ed usarne le funzionalita'. Mi riferivo alle
CA> API che permettono di estenderlo ed istruirlo, ovviamente. Piu
CA> rapide di quelle di emacs?  assolutamente no.
É in Java, no ? Ergo devi compilare - e per quello che ho visto coi
plugin - riavviare. E questa la rapidità. E scusa se è poco.
Se poi Eclipse  avesse questo interprete che permette  di estendere al
volo il  programma, perché  non dici  dove è ?  O hai  qualche segreto
industriale da difendere ?


 industriale da difendere ?
Non lo posso dire perche' non lo ha, e lo sai bene, e comunque questa e' una 
cosa che non ho mai sostenuto. Il workflow per estendere le funzionalita' sono 
quelle da te descritte. Bisogna scrivere un "plugin" (piu' che altro una 
action), compilarla, fargliela vedere e riavviare. Non esiste una "console" dove 
posso scrivere una procedura ed associarla ad una combinazione di tasti al volo. 
Ma la discussione non verteva sulla rapidita' di sviluppo, che io stesso ho 
detto essere quella di emacs maggiore. Il discorso era riferito alle tue parole:
 > Perché quando è ora di fare qualcosa in più di un banale search & replace ti
 > trovi a dover ripetere N volte la stessa serie di movimenti, non a dire
 > all'editor "fai N volte questa serie di movimenti".
cioe' le potenzialita'. Dato che emacs lo conosco, ma di certo non ad un livello 
tale da poter scrivere su due piedi qualunque estensione mi venga in mente, 
tantomeno usando jdee, ho fatto due ricerche su internet e cio' che pensavo mi 
e' stato confermato.
Mi sono imbattuto ad esempio sul codice di un tizio che ha scritto una funzione 
per sortare gli import statements. Questo signore si e' dovuto scrivere 
procedure per parsarsi il file da capo a coda, usando regex per identificare gli 
import statements e poi sortarle usando un algoritmo di sorting creando buffers 
e roba da programmazione di basso livello. Facendo finta di ignorare che la 
possibilita' di modificare il sort gli import e' gia' disponibile nativamente, 
con PDE avrei avuto a disposizione l'oggetto CompilationUnit su chiamare il 
metodo getImportContainer e lavorare direttamente su un oggetto che 
semanticamente mi rappresenta il blocco di import. Ora, premesso che non so 
valutare se il tizio di cui sopra sia un buon programmatore o un pirletta, mi 
pare che tra i due ambienti la differenza sostanziale sia che Emacs mette a 
disposizione un potente linguaggio che ti permette di operare sul documento ma 
ancora a livello di righe e caratteri, mentre Eclipse fornisce un framework piu' 
alto dove il tuo documento e' gia sezionato in blocchi semantici.. imports, 
members, methods bla bla bla. Scrivere il codice che ho visto (tante righe!), 
anche per un navigato di elisp, credo che avrebbe portato via un discreto tempo 
e non penso meno di quello che si sarebbe impiegato a farlo in pde compilazione 
e riavvio compresi. Quindi penso che a sostituire il modificatore di visibilita' 
dei campi di una classe sia un gioco da ragazzi in elisp mentre con pde ci 
sarebbe un overhead considerevole, gap che verrebbe pienamente colmato pero' nel 
momento in cui uno voglia fare cose piu' complesse come un grosso refactoring o 
altro. Ne convieni?

> crudo.
CA> Siamo d'accordo. Allora per curiosita' ti chiedo (perche lo
CA> ignoro): quali sono le funzionalita di jdee che "out of the box"
CA> quindi senza minimamente creare o modificare estensioni, lo
CA> rendono tanto migliore dell'editor di eclipse?
Qui  c'e`  stato un  misunderstanding.  Ripeto,  parlo dell'editor  in
quanto tale. Non dell'editor piu` jdee.
CA> Non lo posso dire perche' non lo ha, e lo sai bene, e comunque
CA> questa e' una cosa che non ho mai sostenuto. Il workflow per
CA> estendere le funzionalita' sono quelle da te descritte. Bisogna
CA> scrivere un "plugin" (piu' che altro una action), compilarla,
CA> fargliela vedere e riavviare.
[.. omissis ..]
CA> cioe' le potenzialita'. Dato che emacs lo conosco, ma di certo non
CA> ad un livello tale da poter scrivere su due piedi qualunque
CA> estensione mi venga in mente,
Scrivere un  modo è tutt'altro  che banale, modificarne  uno esistente
già più semplice, il fatto di poter provare al volo aiuta.
Ma non mi riferivo a quello. Mi riferivo al fatto che ogni volta che ho
davanti un compito ripetitivo ho aperta la porta per automatizzarlo, e
la cosa non è difficile.
Partendo dall'assioma che ogni tasto premuto chiama una funzione e che
quindi una sequenza di comandi è una sequenza di funzioni, la scrittura
di semplici funzioni che risolvono un caso contingente diventa una cosa
non difficile (per un programmatore) ed immediata.
Vantaggi ? Che ogni qualvolta ho una serie di azioni ripetitive, o con
una macro, o  con le funzioni, le automatizzo  (guadagnando tempo, che
uso  poi come  piace  a  ME).  Parallelamente,  ho  la possibilità  di
trasformare in un  passatempo creativo anche i più  pallosi compiti di
editing.  Non solo  ci metto  meno, ma  mi sento  anche  meglio: trovo
riduttivo dovermi trovare  in quelle situazini in cui  da una tastiera
viene fuori un rumore ritmico ripetuto rapidamente, quelli sono i casi
in cui deve essere la macchina a lavorare.
CA> tantomeno usando jdee, ho fatto due
CA> ricerche su internet e cio' che pensavo mi e' stato confermato.
Sugli automatismi  Java e  sulla gestione del  progetto Eclipse  non è
carente, ripetiamolo ancora una  volta. Ma prevede solo "casi tipici".
Se tu hai  una cosa che è  un caso atipico, non hai  una strada rapida
per agire  se non fare  a manina. Anche  se sei sapresti come  fare la
cosa, non è rapida e nemmeno "indolore".
E  poi ci  sono delle  furbate che  Eclipse, non  avendo  una trentina
d'anni, non ha  "imparato", ad esempio il dover  PER FORZA passare per
la reflection per fare la completion (laddove poi sia possibile questa
completion   per   reflection)  non   lo   trovo   per  nulla   comodo
(lentezza).  Avere  una  completion  basata  sul  contenuto  dei  file
correntemente caricati è  un qualcosa che si apprezza:  alla peggio la
cosa la scrivi tutta una volta sola...
CA> Mi sono imbattuto ad esempio sul codice di un tizio che ha scritto
CA> una funzione per sortare gli import statements.
??? Ci sarebbe gia` pronta in JDEE, non capisco perché la abbia fatta,
a meno che non sia la cosa che è entrata in JDEE, ma ne dubito.
CA> con PDE avrei avuto a disposizione l'oggetto
CA> CompilationUnit su chiamare il metodo getImportContainer e
CA> lavorare direttamente su un oggetto che semanticamente mi
CA> rappresenta il blocco di import.
Ho  guardato oggi  la lista  dei  linguaggi supportati  da Eclipse,  è
abbastanza completa.   La cosa che però  ho notato è che  si tratta di
editor diversi, anche se si presentano uniformemente. Una funzione che
hai in uno  non la hai nell'altro. Scusami, ma  questo approccio mi fa
piuttosto pena  ed il  fatto di avere  "oggetti che  semanticamente mi
rappresentano qualcosa" (scusa la citazione,  non è un'attacco a te) a
questo punto  mi pare una immane  menata, un bel gigante  dai piedi di
argilla.
Preferisco un  editor unico, estremamente  potente su cui poi  ti puoi
creare cose come EIEIO ed il  Semantic Bovinator (che ha il difetto di
mangiare CPU come  un matto se non lo limiti, e  la cosa sotto Windows
scoccia  - meno  male che  Windows  lo uso  il meno  possibile) se  ti
servono (30 anni fa di OO non si parlava ancora).
CA> Ora, premesso che non so valutare
CA> se il tizio di cui sopra sia un buon programmatore o un pirletta,
CA> mi pare che tra i due ambienti la differenza sostanziale sia che
CA> Emacs mette a disposizione un potente linguaggio che ti permette
CA> di operare sul documento ma ancora a livello di righe e caratteri,
CA> mentre Eclipse fornisce un framework piu' alto dove il tuo
CA> documento e' gia sezionato in blocchi semantici..
Vedi sopra. Mosso da curiosità, mi sono  andato a vedere come
fa JDEE a fare il sort degli import.
(defun jde-import-sort (&optional reverse)
  "Sort Java import statements alphabetically. In reverse order if
REVERSE is non-nil.
Usage:
  \\[jde-import-sort] sort import statements ascending.
  \\[universal-argument] \\[jde-import-sort] sort descending.
The the current buffer must be in `jde-mode'. This command uses the
semantic Java parser and requires JDE 2.1.6-beta24 and above."
  (interactive "P")
  (or (eq major-mode 'jde-mode)
      (error "Invalid major mode found. Must be 'jde-mode'."))
  (or (and (local-variable-p 'semantic--parse-table (current-buffer))
           (symbol-value 'semantic--parse-table))
      (error "Semantic Java parser not found."))
  (and (interactive-p)
       (consp current-prefix-arg)
       (setq reverse t))
  (let* ((tags  (semantic-fetch-tags))
         (depends (semantic-brute-find-tag-by-class 'include tags)))
    (if depends
        (let* ((first-import-tag (car depends))
               (last-import-tag  (nth (1- (length depends)) depends))
               (start (semantic-tag-start first-import-tag))
               (end   (semantic-tag-end   last-import-tag)))
          (when (and start end)
	    (require 'sort)
	    (let (sort-fold-case)
                (sort-lines reverse start end)
                (goto-char start)))))))
Usa un parser  semantico per dindividuare dove sono i  tag di import e
poi riordina le righe in quel range.
Ma hai detto  la frase magica: "Emacs mette  a disposizione un potente
linguaggio  che ti  permette  di  operare sul  documento  ma ancora  a
livello di righe e caratteri,"
La vera forza di Emacs è proprio di essere un drago a gestire il testo
come insieme di caratteri. Ed è esattamente quello che ti serve quando
arrivano  i compiti  più pallosi.  In  quel caso  i blocchi  semantici
possono non essere di alcun aiuto.
CA>  gap che
CA> verrebbe pienamente colmato pero' nel momento in cui uno voglia
CA> fare cose piu' complesse come un grosso refactoring o altro. Ne
CA> convieni?
Non del tutto.  Io ho fatto  il grosso refactoring, ne ho già parlato.
Certo, l'ho dovuto scrivere il codice che lo ha fatto (un po' di Elisp
ed un po'  di shell per individuare i file). In  una ventina di minuti
"pianificando" le  operazioni da compiere  sui vari file (come  ho già
detto, per farlo basta pensare a che tasti si premerebbero, e tradurre
ciò in funzioni)  e mettere tutto in una funzione che  poi la shell ha
provveduto a richiamare dall'esterno.
La cosa  è di qualche  anno fa,  una delle cose  che ricordo è  che si
andava a cambiare  in ArrayList il tipo di  varie variabili Vector, ma
c'era  anche   altro  e  riguardava   un  certo  numero  di   file  di
configurazione in XML...
Questo  non vuole dire  che mi  rifiuti di  usare l'editor  di Eclipse
(almeno fintanto che non riesco a interfacciare bene Emacs da Eclipse)
e le feature  varie già pronte. Semplicemente uso  Eclipse per gestire
il progetto  e per l'editing minuto  e l'editing grosso  lo faccio con
Emacs.



-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

> Volendo opera su rettangoli di testo.
E'OF> Questo però trovo lo faccia in modo abbastanza bruttino.  Le
E'OF> configurazioni di default vogliono che schiacci ben
E'OF> ctrl-x r r 1 : yank ctrl-x r g 1 : copy ctrl-x r k : kill
E'OF> tasti. Inoltre non ho trovato un modo di farlo con il mouse.
E'OF> Anche io tendo ad usare poco il mouse, ma nelle selezioni
E'OF> verticali in qualche modo è comodo: forse perchè il compito è in
E'OF> se e per se grafico.
Sull'assegnazione   dei   tasti:   chi   ha   scelto   definitivamente
l'assegnazione ha fatto queste due considerazioni:
- (opinabile     ) Non e` un comando di uso comune
- (meno opinabile) Meglio non mescolare nel kill ring selezioni norma-
                   li e  per colonna -  non vorrei che ci  siano delle
                   motivazioni  tecniche  dietro   la  scelta  di  non
                   mettere il  testo selezionato per  colonne nel kill
                   ring ma in un registro.
Quanto  alla prima  ci sono  vare possibilità  per aggirarla  -non per
niente  hai parlato  di configurazioni  di default-,  tutte  si basano
sulla  completa riassegnabilità  dei  tasti.  Conta  che oramai  quasi
tutte  le tastiere,  di riffa  o di  raffa, ti  permettono di  avere a
disposizione  anche il tasto  Hyper -  mai usato  nei modi  standard -
senza  dover ricorrere ai  binding lasciati  liberi per  l'utente (C-c
[a-z]).
Quanto  al  mouse,  guarda  che  funziona  benissimo.  I  vertici  del
rettangolo  sono dati  dal point  (posizione del  cursore) e  dal mark
(marca).
E'OF> Io ho presente a riguardo TextMate. Semplicemente schiacciando
E'OF> alt permette di passare alle selezioni verticali (e le manipola
E'OF> anche in modo parecchio furbo).
Non so fino a che punto,  ma ho il dubbio che sarebbe possibile creare
un  text-mate-mode per  Emacs... Ho  anche  il sospetto  che si  possa
riconfigurare TextMate per assomigliare molto a Emacs :) :) :).
E'OF> dell'estensibilità fa la sua bandiera (estensibile tipicamente
E'OF> in ObjC ma soprattutto in Ruby, Perl o Python o anche bash --
E'OF> che vuole dire in pratica in qualunque linguaggio interpretato,
E'OF> solo che su ogni OS X Perl Ruby e Python ci sono, quindi...).
Beh, c'è anche la bash :).
Bisogna vedere  se poi questo  modi di estendere l'editor  permette di
rimpiazzare al  volo alcuni comportamenti  "standard" dell'editor solo
quando serve. 
Va  detto che  questa esigenza  capita in  situazioni  patologiche che
hanno poco a che vedere con l'uso di un editor per scrivere programmi:
a me  è successo di dover  rimpiazzare la funzione che  invia la posta
con un'accrocchio  scritto apposta per aggirare  le configurazioni del
firewall di un cliente sfruttando  ssh (permessa) ed un mio account su
una macchina all'esterno della rete  del cliente... Come ho ammesso, è
una situazione patologica. 
Però un  certo gusto maligno  a continuare ad  usare la posta  come al
solito mentre i colleghi  dovevano usare una tiribbile interfaccia web
lo ho avuto, lo ammetto :> :>.


 lo ho avuto, lo ammetto :> :>.
LOL :)


> Beh, c'è anche la bash :).
E'OF> Ah, si. Beh, davo per scontato :)
Anche io. Ma  sai non tutto lo fanno... C'è un  S.O. su questo pianeta
che  fa  pensare  che  lavorare  con  un  interprete  di  comandi  sia
limitante...
E'OF> Sinceramente non so come (nel senso che mi sono limitato
E'OF> a creare semplici snippet usa e getta per un po' di testo
E'OF> ripetitivo
E  dici poco.  Hanno  trasformato  un lavoro  meccanico  in un  lavoro
creativo.


 creativo.
Beh, certo. Ma non ho che scalfito la superficie, questo voglio dire.
