rilevante

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.

Il giorno martedì 21 febbraio 2012 14:26:36 UTC+1, Alberto Salvati ha scritto:
> con xe2 esiste un qualcosa di diverso dai package per fare quello che
> si fa in .net con le class library?

Cioè? :)

Così come in .NET ci sono "class library", in Delphi ci sono i package.

> Dovrei fare delle cose che in d7 richiedono l'uso dei package ma NON
> POSSO USARLI.

Spiega lo scenario, altrimenti mi sa che non è possibile suggerire nulla.:)

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.

Il giorno martedì 21 febbraio 2012 16:23:07 UTC+1, Alberto Salvati ha scritto:
> Problema:
> ho delle classi che devono essere usate da:
> [...]
> 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.

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 leclassi nei package "satellite" da queste, semplificando quindi le chiamatedei 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 tuttele altre, qualsiasi versione di Delphi va bene, tranne per la RTTI estesa che esiste da Delphi 2010 in poi (se ricordo bene).

Ciao,
Marco.

On 21.02.2012 16:23, Alberto Salvati wrote:

>
> Problema:
> 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

>
> 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.



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.

On 22.02.2012 13:46, Alberto Salvati wrote:
> Qua sta il casino...
> 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)
[..]

Il giorno mercoledì 22 febbraio 2012 15:19:19 UTC+1, Alberto Salvati ha scritto:
> la dll crea una istanza di una classe TQualcosa.
> 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 questioggetti vengono interscambiati.

> Pessima idea mettere classi nelle DLL:

...e ke kaz...era solo un esempio.. :-D

A.

On 23.02.2012 14:58, Alberto Salvati wrote:
>> Pessima idea mettere classi nelle DLL:
>
> ...e ke kaz...era solo un esempio.. :-D
>
> 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.

Il giorno giovedì 23 febbraio 2012 14:58:45 UTC+1, Alberto Salvati ha scritto:
> ..e ke kaz...era solo un esempio.. :-D

Ah, scusa... pensavo fosse già lo scenario attuale. :D

>
> Il massimo godimento l'ho avuto quando ho realizzato che potevo cambiare
> 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.