Newsgroup: it.comp.java
Titolo: [open source] A chi andrebbe di partecipare ad un progetto?

 Bye

Mi associo....
Proposte....ad esempio un file sharing con jxta.....oppure altro...
Ciao Paolo da Roma

 wrote in message
news:2uregtsamlig7a25u...@4ax.com...


 Bye

 - non sono tanto Object oriented.
in che senso ? , io li uso e mi sembrano abbastanza oo, alludi forse al
fatto che gli oggetti sono marshallati dentro lo space ??


Ciao,
no, molto peggio :) 
Ti sei mai chiesto perche' il matching vede solo i public fields delle
entries??
Questo rompe l'incapsulazione e tutti i principi di information hiding
che ci piacciono, o nella situazione migliore gli indebolisce
sensibilmente.
Leggi: Se vuoi fare matching su un attributo del tuo oggetto devi farlo
pubblico.
Conseguenza se vuoi usare JavaSpaces con delle legacy applications devi
probabilmente ridisegnare l'interfaccia delle classi che andranno sullo
spazio. 
Se il tuo programma e' nuovo dici addio a information hiding...
La ragione e' tecnica ma essenzialmente se fossere javabeans invece che
entries il problema si puo aggirare. Nota che non e' intenzione del
JavaSpace team andare in questa direzione.
Ogni commento e' bene accetto :)
-- Giuseppe

 Bye

 -- Giuseppe
IMHO, non basta avere dei getter per fare 'information hiding'. Un
semplice getPippo() che legge dal membro pippo non nasconde nulla
dell'implementazione, al massimo e' utile per avere degli attributi read
only non definendo il relativo setPippo(). Se solo questo e' il
problema, non c'e' praticamente nessuna differenza fra membri public e
membri private con relativi accessors. Soprattutto se i cambiamenti
possibili nella classe si riducono ad aggiunte di membri, modifiche di
tipo, ecc., cosa frequente se gli oggetti sono 'Entity' (nella
classificazione di Jacobson).
Anche gli Entity Bean (che sono Entity!) nella specifica 1.1 hanno
membri public utilizzati nello stesso modo (non so se nella 2.0
cambiera').
ciao
-- 
         ______
        /_____/\             Ugo Landini
       /____ \\ \            Education Technical Supervisor
      /_____\ \\ /           Sun Educational Services
     /_____/ \/ / /          
    /_____/ /   \//\         SUN Microsystems Italia S.p.A.
    \_____\//\   / /         Via Romagnosi, 4
     \_____/ / /\ /          00196 - Rome (RM) - Italy
      \_____/ \\ \           @mail : 
ugo.l...@sun.com
       \_____\ \\            Phone : +39 (0)  6 36708.682
        \_____\/             GSM   : +39 (0)  335 7766651

 ciao
Ciao,
secondo me non e' solo un problema di getter/setter, questi ultimi
semplificano solo le cose. 
Il problema e' filosofico alla base. Perche' il matching viene fatto
solo su campi pubblici? Qual'e' la filosofia alla base di questa scelta?
Nota che in un JavaSpaces non si mettono solo oggetti 'Entity', anzi
mettere oggetti entity fa a mio avviso poco senso, un database sarebbe
una scelta migliore: piu' efficente e senza  le limitazioni del
matching.
Ovviamente in ambienti estremamente dinamici i JavaSpaces fanno comodo
lo stesso.
Supponi invece che metto nello spazio oggetti con behaviour complesso e
di conseguenza con uno stato possibilmente complesso. A questo punto e'
naturale avere un design con fields private. Questi ultimi denotano lo
stato dell'oggetto e se un client e' interessato ad un oggetto in un
particolare stato non ha modo di ottenerlo senza fare metching sui campi
privati. 
Questo scenario e' quasi irrilevante in Jini dove il matching sui
servizi offerti da un "service" e' fatto su un interfaccia appositamente
costruita a questo scopo. 
Il mio punto e' che filosoficamente parlando non ha molto senso limitare
il matching ai public fields a meno che appunto non hai fortissime
ragioni di credere che i tuoi oggetti sono piu' "entity" che altro. 
Ho discusso la cosa con John McClain allo scorso community meeting. Loro
sono fortemente a sfavore dei beans perche le specifiche diventerebbero
molto piu' complesse (e meno efficenti, lo spazio dovrebbe istanziare le
entries). Senza i beans si dovrebbero fare svariate magie sugli oggetti
serializzati il che e' terribilmente inefficente. Filosoficamente la
loro posizione e' che i fields public sono la vera interfaccia e il
mondo esterno non deve avere alcun controllo su fields
protected/private. 
Io non sono d'accordo... Quanto meno e' brutto :)
-- Giuseppe

 Io non sono d'accordo... Quanto meno e' brutto :)
e comunque brutto è un concetto relativo... :)
UL

 Jini/JavaSpaces?
Non so bene cosa intendi per "strategic closures", ma una cosa banale da
vedere
e' che se hai una gerarchia standard per shapes tipo
class Shape {
	protected Integer x,y;
	....
}
class Circle extends Shape {
	...
}
Se metti dei cerchi nello spazio non puoi chiedere un cerchio con un
origine particolare
perche' e' protected. Ovviamente si potrebbe fare public ma questo tipo
di gerarchie io
le ho viste sempre con protected. Se il codice e' gia' scritto e lo vuoi
integrare con i JavaSpaces la cosa diventa dolorosa. 
E' ovviamente un esempio banale ma spero renda l'idea...
-- Giuseppe