Newsgroup: it.comp.lang.delphi
Titolo: Re: costanti

 valore di ritorno di funzioni come "ExtractFilePath".
[cut]
con un approccio simil-singleton
interface
function MiaConst: String;
implementation
var
   _MiaConst: String = '';
function MiaConst: String;
begin
	Result:=_MiaConst;
end;
initialization
  _MiaConst:=ExtractFilePath..........
finalization
end.
ciao daniele

 Qui parliamo di variabili globali, non costanti. ;-)
Ma l'argomento "costanti" l'ho messo io in mezzo proprio xche mi 
interessava creare delle costanti che avessero come valore delle info 
utili da usare in tutto il mio progetto, l'approccio che dici tu con la 
var lo potevo fare benissimo anche io ma a me non è piaciuto poichè la 
variabile può essere modificata e io non volgio che succede questo.
Immagina che in un progetto ci lavorino almeno 2 persone...uno di questi 
modifica la variabile e si disallinea con l'altro sviluppatore, quando 
vengono allinati i sorgenti di uno e dell'altro non potrebbe funzionare 
più nulla.
Non ho detto che con la variabile non si poteva fare! Ho chiesto se era 
possibile un altra strada.
------------------------
Diego Di Filippo
  R&amp;D Software Developer
 
www.ada-project.com
-----------------------
--- posted by geoForum on 
http://www.delphiedintorni.it

 complicare la lettura...quindi chiedo! Altre proposte?
Puoi risolvere piuttosto elegantemente con una classe che esponga una 
serie di proprietà ReadOnly che andrai ad inizializzare nel proprio 
costruttore.
interface
type
TApplicationConsts = class(TObject)
private
   FPath: string;
   FProperty1: string;
   ...
public
   property Path: string read FPath;
   property Property1: string read FProperty1;
   ...
   constructor Create;
   ...
end;
var
AppConsts: TApplicationConsts;
implementation
constructor TApplication.Create;
begin
   FPath := ExtractFilePath(...
   FProperty1 := ...
   ...
end;
initialization
   AppConsts := TApplicationConsts.Create;
finalization
   AppConsts.Free;
end;
Dichiarata in questo modo, la variabile AppConsts è automaticamente 
disponibile in tutte le unit che fanno uso della suddetta.
In questo modo ottieni quello di cui hai bisogno, in più:
1. lavori Object Oriented, con tutti i vantaggi che ne derivano;
2. i tools tipo completamento del codice ti vengono in aiuto;
3. se per qualche motivo hai bisogno di una copia locale delle tue 
variabili, magari inizializzate in maniera diversa, in relazione ad 
eventuali altro costruttori della classe, puoi tranquillamente farlo 
senza per questo intaccare la variabile globale.
Ciao,
Gianluca.

ciao a tutti,
vorrei creare nel mio programma delle costanti i cui valori sono il 
valore di ritorno di funzioni come "ExtractFilePath".
Il valore di queste costanti devono essere passate come parametro alle 
altre funzioni di libreria.
ho provato con :
const
   costante = ExtractFilePath(...);
ma da errore.
come posso fare?
grazie


 più nulla.
Non è questo il tipo di problema che risolvi. Lo stesso identico 
problema ce l'hai anche con una costante: basta che uno dei due 
sviluppatori inconsapevolmente o con leggerezza ne modifichi il valore 
senza aver prima valutato le effettive conseguenze nel resto del codice 
(quindi senza aver visto dove effettivamente questo valore viene 
utilizzato). Questo si risolve solo documentando adeguatamente la 
dichiarazione della costante ed, eventualmente, i punti in cui viene 
utilizzata.
Il problema che puoi avere dall'uso di una variabile globale è quello 
che venga inavvertitamente variata all'interno del codice a causa di 
un'assegnazione (soprattutto nei casi in cui questa venga passata come 
parametro ad una funzione senza il modificatore _const_ ed all'interno 
della stessa venga per qualche motivo - più che lecito - modificata).
Ciao,
Gianluca.

 complicare la lettura...quindi chiedo! Altre proposte?
L'unica secondo me č usare delle funzioni, magari dichiarate in una unit
separata.
L'impatto prestazionale, in questo caso, sarebbe nullo.
-- 
Jax
====
Ho detto al mio nuovo amore: Sei bellissima! Ma non sa ancora che sono
un bugiardo.

 finalization
Mi sfugge l'utilità di questo approccio rispetto ad una Function ExePath() -
che oltretutto mi sembra anche più facile da gestire...
-- 
Jax
====
Le cose che una generazione considera un lusso, la generazione
successiva le considera necessità. (Anthony Crosland)

 create?
Uhm, credo che in questo caso sia per "nascondere" la variabile vera e
propria.
Facendo come dici tu, chiunque potrebbe modificare miavar, mentre
utilizzando una variabile "finta" (_miavar), miavar resterebbe
immodificabile.
-- 
Jax
====
La calunnia disdegna i mediocri, si afferra ai grandi. (Francesco
Crispi)

Il concetto è il medesimo.
rispondo in stereo a te e rubio.
Nessuno mette in discussione l'utilità, quello che non è chiaro a me
(e penso ad altri) è l'utilizzo del termine costante in questo
contesto.
Qui parliamo di variabili globali, non costanti. ;-)
Inoltre, perdona, ma perché definire una funzione che complica la
lettura?
Non bastava un miavar := extractfilepath() nell'initialization o nel
create?
Ciao.
-- 
Ore 18.30: premo invio.


l'utilità è che se qualcuno altro tocca il codice non deve poter 
modificare il valore di quella costante.
Oppure se nel codice si modifica la variabile ci si deve ricordare di 
rimetterla a posto.
Per è una cosa ottima preparare dei valori costanti del tuo progetto 
invece di chiamare sempre le funzioni nel codice ogni volta che ti 
servono.
:-)


 Lo so che una costante non può variare nel corso del programma, ed è 
E non deve variare in base a dei parametri.
Andrea

 grazie
Prego,
Andrea

ragazzi scusate se posto a caso ma ho problemi a fare il post reply.
Cmp molto probabilmente mi sono espresso male nello spiegare le mie 
intenzioni.
Lo so che una costante non può variare nel corso del programma, ed è 
proprio questo che voglio, cioè avere una costante che contiene il 
percorso della mia applicazione in modo da non poterne modificare il 
valore.
Non so altro come esprimermi.
L'idea di Daniele Teti è carina ma come dice Massimo Pini potrebbe 
complicare la lettura...quindi chiedo! Altre proposte?
grazie.


 costruttore.
Ottimo consiglio. In effetti ci sono anche gią molti componenti free che
forniscono informazioni, e usano la stessa filosofia.
-- 
Jax
====
Posso simpatizzare con qualsiasi cosa, tranne che con la sofferenza.
(Wilde)

 che oltretutto mi sembra anche più facile da gestire...
Al posto di "ExtractFilePath" metti una funzione che impiega 4 sec. ad 
essere eseguita, richiamala 1000 volte e capirai la "motivazione" del 
mio approccio.
Pensa che nei SW di video grafica le funzioni trigonometriche vengono 
spesso calcolate alla partenza e messe in un array di 360 elementi per
velocizzare i futuri *milioni* di accessi.
Il concetto è il medesimo.
Ciao Daniele

Ciao Daniele
grazie Daniele per l'aiuto.


costruttore.
Grazie Gianluca,
ti devo dire che ci avevo pensato anche io a delle proprietą readonly ma 
non sapevo proprio da dove cominciare.
di nuovo grazie.


utilizzata.
Infatti se invece della variabile viene mssa una costante lo sviluppatore
si chiederà (penso!) xchè in compilazione l'assegnazione non può andare a 
buon fine! e se modifica il punto di inizializzazione beh! allora si sa 
di chi è la colpa!
ciao.


 non sapevo proprio da dove cominciare.
Il dado e' tratto.
^____^
-- 
Morde. 
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

 
La "filosofia" è sempre quella del singleton, ma in versione OOP. Ben 
venga :-)
Ciao Daniele

 grazie
Semplicemente :
property costante: string read GetCostante;
function GetCostante: string;
begin
   Result := ExtractFilePath(...);
end;
Saluti
***Gio***

***Gio***
Ciao Gio,
Ho risolto già con l'idea di Gianluca Plevani, mi sono trovato benissimo 
e la classe si può estendere come vuoi.
Userò sempre questo metodo.
:)


 venga :-)
uhm... non pensavo proprio ad implementare una classe singleton. Con un 
singleton puoi istanziare n oggetti dello stesso tipo e tutti ritornano 
sempre la prima istanza. Però comporta una serie di problematiche 
diverse e complica la vita. Tenuto conto che in Delphi non se ne può 
nemmeno fare il subclassing, i casi in cui viene utile un pattern del 
genere sono piuttosto limitati. Io mi accontentavo di proporre un 
oggetto globale da utilizzare in tutta l'applicazione.
Però, per curiosità, il pattern del singleton può essere usato anche al 
di fuori di OOP? Non ne ho mai sentito parlare.
Ciao,
Gianluca.

 di fuori di OOP? Non ne ho mai sentito parlare.
I Design Patterns sono soluzioni a problemi frequenti, e in genere ( 
come concetto) possono essere applicati a qualunque ambito dove esista
un "problema".
Se il concetto/Pattern "Singleton" va bene per la risouzione del tuo 
problema, nessuno ti vieta di usarlo! Sia che programmi in Pascal, in 
C++ o C
Ciao Daniele