Newsgroup: it.comp.lang.delphi
Titolo: Non uso xe2...ho una domanda

con xe2 esiste un qualcosa di diverso dai package per fare quello che
si fa in .net con le class library?
Dovrei fare delle cose che in d7 richiedono l'uso dei package ma NON
POSSO USARLI.
 
Grazie per ogni risposta.
 
A.

 POSSO USARLI.
 
Spiega lo scenario, altrimenti mi sa che non è possibile suggerire nulla. :)
 
-- 
MARCO BREVEGLIERI
#Home: 
http://www.marco.breveglieri.name
 
#Blog: 
http://www.compilaquindiva.net
 

 
Giusto..Mi sono spiegato una latrina... Pardon...
 
Problema:
ho delle classi che devono essere usate da:
 
6 eseguibili
2 servizi
8 dll
 
Al momento queste classi sono tutte linkate nei vari exe, dll etc.
Vorrei metterle in un "qualcosa" in modo da tenerle a parte senza
essere poi costretto a ricompilare il mondo se una di queste kaz di
classi cambia.
La domanda e' :
 
Per fare questo in xe2 l'unico modo e', come in d7, usare i runtime
packages"?
Oppure, come hanno introdotto una modalita' totalmente nuova per
gestire RTTI, in xe2 hanno anche introdotto un alternativa ai
packages?
 
A.
 

 classi cambia.
 
Supponendo di utilizzare dei *runtime package*, che mi pare la soluzione più adatta, non dovrebbe essere necessario ricompilare alcun eseguibile o DLL nel caso in cui non venga modificata la parte "pubblica" dei tipi di dati esportati dagli stessi package, se questi vengono dinamicamente linkati all'eseguibile o alle librerie citate.
 
In alternativa, si potrebbe usare l'RTTI estesa per caricare e richiamare questi package, senza linkarli direttamente, magari facendo in modo che i package si basino su un package "centrale", che contiene interfacce o classi base le cui modifiche sono ben più circostanziate, e facendo ereditare le classi nei package "satellite" da queste, semplificando quindi le chiamate dei metodi senza rendere gli eseguibili e le librerie troppo "dipendenti" da classi tendenzialmente complesse e collegate direttamente.
 
In alternativa ancora, si potrebbe adottare un altro standard (es. COM/ActiveX), ma mi vengono i brividi al pensarci, e avendo tu un'esperienza più diretta in merito, probabilmente te ne verranno di più grossi ed estesi. :)
 
Infine, potresti portare la logica da condividere tra applicazioni e librerie all'esterno, in un "server" invocabile tramite DataSnap via TCP o HTTP/REST, ma già questo introdurrebbe nuovi requisiti per supportare l'architettura.
 
Per quest'ultima soluzione, senz'altro XE2 offre buone soluzioni; per tutte le altre, qualsiasi versione di Delphi va bene, tranne per la RTTI estesa che esiste da Delphi 2010 in poi (se ricordo bene).
 
Ciao,
  Marco.


 ho delle classi che devono essere usate da:
 
 
Se ho capito bene ora condividi i sorgenti delle classi in comune, e 
quindi ad ogni rebuild sono i DCU delle classi modificate che vengono 
linkati agli exe, servizi,dll.
 
Fatta la dovuta premessa il mio consiglio è questo:
1- spostare tutte le classi in dll che dovranno poi essere caricate 
dinamicamente da tutti, exe e servizi compresi.
2- mettere in piedi un sistema di build (ad es, ANT) che faccia il build 
per te di tutti i progetti, exe, dll, servizi e quant'altro.
 
Io tenterei prima la strada del batch build, perchè la seconda implica 
un lavoro di coding che, almeno inizialmente, non è indolore visto che 
dovrai toccare tutti i punti dove includi i sorgenti delle classi 
condivise per sostituirli con l'uso della dll shared.
 
Ciao
 
-- 
morde
Android
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

 dinamicamente da tutti, exe e servizi compresi.
 
 
 
Qua sta il casino...
Una DLL win32 espone funzioni e non classi.
Se in una dll ho una classe, almeno un suo ancestor DEVE essere
presente nell'exe che usa questa kaz di classe.
Quindi, doveri creare una classe astratta per ogni classe non astratta
che uso.
Nella DLL metto quelle non astratte.
Nell' exe metto quelle astratte.
Quando l'exe chiama la DLL passa per RIFERIMENTO dei riferimenti
dichiarati del tipo classe astratto.
La DLL chiama il costruttore della classe non astratta usando come
handle quello ricevuto dall'exe.
Quindi, se ho 100 classi, devo creare 100 classi astratte....
 
A.

Smanettando su google, ho scoperto una cosa che non sapevo....
I packages, come le dll, possono essere caricati dinamicamente....:
 
 
http://edn.embarcadero.com/article/27178
 
 
Se questa cosa non richiede di compilare usando in runtime packages mi
si apre davanti un mondo nuovo... :-D
 
 
Certo, se esistesse il modo di non dover usare classi che ereditano da
TPersistent, sarebbe carino.
Altrimenti, mi basta poco, visto che OVVIAMENTE tutte le mie classi
hanno un ancestor comune creato  da me che al momento eredita da
TObject
 
 
A.
 

 Una DLL win32 espone funzioni e non classi.
 
Nel progetto su cui sto lavorando faccio proprio così: da QT carico una 
DLL win32 scritta in c++ standard che esporta una classe che fa da 
factory di business objects.
Ogni suo metodo mi ritorna un puntatore a una classe creata nella pancia 
della dll, che io uso "bovinamente", senza preoccuparmi del perchè e 
percome della sua genesi :-D
Ma qui siamo nel dominio di C/C++: dove ci si scambiano puntatori e si 
lavora direttamente con la memoria.
 
Anche se lo stesso DCC è soggetto alle comuni regole per creare le dll 
win32, dovrei documentarmi meglio per affermare la fattibilità della mia 
soluzione. Su stackoverflow qualcosa c'è, ma è poco.
 
Riguardo il resto del tuo discorso, sono d'accordo con te: strada troppo 
complicata, anche se possibile ;)


Il problema non e' "chi crea cosa". Il problema e':
 
la dll crea una istanza di una classe TQualcosa.
La classe TQualcosa e' dentro la DLL.
Un exe chiama la funzione della dll che crea un TQualcosa.
Ma l'exe NON SA come e' fatta la classe TQualcosa...
Quindi: una classe che somiglia a TQUalcosa deve essere nota all'exe,
ad esempio, una classe astratta uguale alla classe reale.
Al solito, se hai 5 classi ok, ma io ho perso il conto delle classi
che ho....
 
Devo vedere se usando i package dinamicamente si riesce a evitare
questa cosa. :-((
 
 
 
A.
 
 
 
 
 
 
 
 
 
b)


 La classe TQualcosa e' dentro la DLL.
 
Pessima idea mettere classi nelle DLL: in questo caso, usare i package è fondamentale, altrimenti devi compilare necessariamente DLL ed EXE usando i "runtime package" per essere sicuro che nessuno dei moduli incorpori classi condivise e utilizzate da entrambi, soprattutto se i riferimenti a questi oggetti vengono interscambiati.


> Pessima idea mettere classi nelle DLL:
 
..e ke kaz...era solo un esempio.. :-D
 
A.

 A.
Il massimo godimento l'ho avuto quando ho realizzato che potevo cambiare 
una classe java, ricompilare e fare il deploy del .class "a caldo" 
mentre il programma gira senza alcun problema.


 ..e ke kaz...era solo un esempio.. :-D
 
Ah, scusa... pensavo fosse già lo scenario attuale. :D


 una classe java, ricompilare e fare il deploy del .class "a caldo"
 
Il massimo del godimento l'ho avuto ad un veglione di capodanno alcuni
anni fa... :-D
 
 
A.

> Ah, scusa... pensavo fosse già lo scenario attuale. :D
 
Ho fatto queste domande prp per capire, tutto qua...
 
A.

 Ho fatto queste domande prp per capire, tutto qua...
 
Ok, allora crea solamente eseguibili (EXE) e package (BPL), e non vedo problemi di sorta alcuno, o comunque non vedo problemi che non avresti comunque con altre soluzioni di diverso tipo. :)
 
Questo a prescindere dal discorso di caricarli dinamicamente tramite RTTI.
 
Ciao,
  Marco.
