[DELPHI] Raggruppare dichiarazioni Uses

[rotteninside]

Ciao a tutti, vorrei se possibile chiarirmi le idee sull'utilizzo della
clausola USES.
Dunque, mettiamo caso che io abbia una USES di 30-40 unit.

Uses 1,2,3,4,5,6,7,8,9,10...40;

Potrei avere una unit o un file (ad esempio : UsesGlobali) che contiene
questa clausola, e richiamare questo file in tutte le unit, senza dover
per forza riscrivere tutte e quaranta le unit ogni volta? Spero di
essermi spiegato bene...

[bDaniele]

non so se quello che chiedi si può fare, in ogni modo è buona norma che in ogni unit includi solo le unità esterne che usi.

[alka]

Originariamente inviato da rotteninside
Potrei avere una unit o un file (ad esempio : UsesGlobali) che contiene
questa clausola, e richiamare questo file in tutte le unit, senza dover
per forza riscrivere tutte e quaranta le unit ogni volta?

No, non si può assolutamente fare.

Il fatto di avere una uses con un numero così elevato di unit mi preoccupa molto: come è possibile che una singola unit (che non sia il programma principale, ma anche in questo caso c'è modo di mediare) possa fare uso di risorse che sono sparse in un numero così elevato di unit?

Credo che ci sia un grosso problema a livello progettuale, in quel caso, cioè nel modo in cui il codice è stato scritto e organizzato all'interno dei singoli moduli.

Non conoscendo i dettagli, non posso entrare nel merito...

Ciao!

[rotteninside]

Bhe in effetti non ne uso 40 ma una decina... forse ho esagerato nella supposizione...
Ho trovato che si può utilizzare la direttiva di compilazione {$I GlbUses.inc} dopo interface, eliminando la clausola Uses.
Mi chiedo, è possibile fare una cosa di qusto tipo:

{$I GlbUses.inc}
// inclusione di altre unit
Unit1, Unit2;

[alka]

Originariamente inviato da rotteninside
Bhe in effetti non ne uso 40 ma una decina... forse ho esagerato nella supposizione...

Se è una decina, non vedo quale sia il problema.

Originariamente inviato da rotteninside
Ho trovato che si può utilizzare la direttiva di compilazione {$I GlbUses.inc} dopo interface, eliminando la clausola Uses.
Mi chiedo, è possibile fare una cosa di qusto tipo:

{$I GlbUses.inc}
// inclusione di altre unit
Unit1, Unit2;

E' possibile farlo, ma non ne vedo l'utilità, in primo luogo, ma sono certo che porterà in futuro ad avere effetti collaterali e posso garantirti dell'assoluta mancanza di un "accrocchio" di questo tipo in quanto realizzo e mantengo applicazioni Delphi abbastanza complesse e non ho MAI avuto un'esigenza di questo tipo.

Insomma, non vedo proprio perchè tu debba complicarti la vita oltre a quanto può realmente farlo il fatto di dover realizzare il tuo progetto.

[rotteninside]

Insomma, non vedo proprio perchè tu debba complicarti la vita oltre a quanto può realmente farlo il fatto di dover realizzare il tuo progetto.

eh purtroppo mi hanno chiesto di realizzare una cosa di questo tipo: Il problema è che stiamo implementando dei moduli e delle librerie che verranno utilizzate da un'utente che andrà a scrivere poi i propri programmi sulla 'struttura' (unit, funzioni, interfacce) che abbiamo creato noi e dovrà utilizzare le funzioni che abbiamo implementato. Per questo avrei bisogno di raggruppare il più possibile le uses diciamo di 'servizio' che l'utente dovrà solo usare come funzioni di 'sistema'...
Ho provato a fare :

{$I glbUses}
uses Unit1;

ma non funziona...

[alka]

Dal mio punto di vista, un cliente che utilizza una vostra libreria per Delphi dovrà comunque saper programmare (un minimo) in Delphi e quindi sarà tenuto in generale a rispettare tutte le regole (che spesso sono presenti per il bene dello sviluppatore stesso) previste dal linguaggio, quindi il vostro prodotto dovrebbe seguire tutte le convenzioni adottate da qualsiasi estensione di terze parti.

Tra l'altro, nonostante capisca la problematica e il tentativo di darle una soluzione, bisogna anche considerare il fatto che in questo modo si includerebbero sempre un numero elevato di unit anche nel caso in cui queste non vengono utilizzate; a seconda del codice contenuto al loro interno (quindi, non sempre, poichè il compilatore opera delle scelte) le dimensioni dell'eseguibile tenderebbero ad aumentare.

Credo che sarebbe più serio suddividere correttamente le funzionalità della libreria in procedure o funzioni, o addirittura una gerarchia di classi, e poi rendere fruibili unit, che siano solo semplici classi o componenti, sottoforma di package, magari documentando bene i tipi a disposizione rendendo così lo sviluppatore in grado di poter scegliere lo strumento più adatto, all'interno della libreria, per svolgere un determinato compito e includere quindi la unit appropriata in cui si trova tale tipo, producendo così software ottimizzato, di qualità, che non referenzia moduli non utilizzati, con la possibilità di compilare il codice delle unit della libreria nell'applicazione (incorporandole) oppure collegare dinamicamente l'applicazione stessa al package che contiene tali unit (con l'opzione "Build with runtime packages").

Ciao!

[bDaniele]

Originariamente inviato da rotteninside
eh purtroppo mi hanno chiesto di realizzare una cosa di questo tipo: Il problema è che stiamo implementando dei moduli e delle librerie che verranno utilizzate da un'utente

scusa ma tu dici che state implementando dei moduli e delle librerie, allora perchè non implementarli come tali?
cioè perchè non create delle dll o delle bpl che servono esattamente a questo?
ti semplifichi la vita in un modo spropositato.

Forse nel tuo caso ti convengono le bpl se non deve esserci portabilità con altri linguaggi

[bDaniele]

ciao rotteninside,
non prenderla come una polemica, ma hai scirtto il primo messaggio ieri a quest'ora chiedendo, in pratica, di dirti come si fa una cosa che è la tua soluzione ad un problema.
solo dopo vari post siamo giunti a capire qual'è l'esigenza e quindi consigliarti la soluzione migliore (guarda caso contemporaneamente io e marco).
questo per dirti che di solito è difficile risolvere un problema senza sapere il problema.
se nel primo messaggio avresti scritto la tua "missione", un solo intervento sarebbe bastato, tu avresti avuto subito una risposta e chi scrive e modera non avrebbe perso tempo a leggere post, help e scrivere su una cosa che è diversa dall'esigenza reale.

non prenderla come una polemica.

saluti

[rotteninside]

non la prendo affatto come una polemica anzi, nei prossimi post farò più attenzione a descrivere i miei quesiti!
Alla prossima! Ciao