Newsgroup: it.comp.lang.delphi
Titolo: VCL: perplessità (ditemi se sono pazzo)

Voi, in tutta sincerità, vi trovate bene con il toolkit grafico di 
Delphi? A me rimangono parecchie perplessità...
ad esempio, capisco la comodità di avere una TApplication che faccia da 
parent a tutte le form: nascondere tutte le form nascondendo la loro 
TApplication, creare e distruggere le form come variabili globali della 
TApplication... ma parliamo dei difetti di questo approcio: minimizzando  
la TApplication se ne vengono giù *tutte* le form, questa architettura 
confonde non poco gli utenti e i window manager, i primi non sapendo che  
il pulsante nella taskbar non è quello della form ma quello della 
TApplication, i secondi non sapendo come trattare questa strana bestia 
(provate a creare due form, entrambe massimizzate, e provate a passare 
da una form all'altra - impossibile: dovrete per forza ridurne una a 
icona), il task manager poi non riesce a capire qual è la finestra 
principale dal momento che tutte le finestre in realtà sono figlie della  
TApplication, impossibile gestire le finestre dalla taskbar perchè nella 
taskbar c'è solo la TApplication che per di più può essere soltanto 
ridotta a icona o chiusa (giustamente: che senso avrebbe massimizzare 
un'applicazione? e in fondo la TASKbar è la barra delle APPLICAZIONI, 
non delle FINESTRE, ma è comunque scomodo e non standard)...
insomma, una serie di piccoli inconvenienti che mi fanno rimpiangere le 
Dialog standard di Windows, che saranno più ostiche ma almeno fanno solo 
quello che viene detto loro di fare. E che userei volentieri in luogo 
delle form se Delphi le supportasse almeno al pari di Visual C++. 
L'unica cosa che mi trattiene dal passare dall'altra sponda è che le MFC 
sono uno schifo rispetto alle VCL (anche se mi sembrano molto più 
leggere le MFC).
e poi, avete mai visto che razza di mostri vengono generati da Delphi? 
avete mai provato a spiare dentro gli eseguibili, anche i più semplici? 
ve lo anticipo: sono pieni di porcherie. Risorse stringa con i nomi dei 
mesi e dei giorni della settimana. Risorse che elencano le unit usate 
dal programma. Importano decine di funzioni che non vi sareste mai 
sognati di usare. E tutto questo usando solo la unit System (e forse 
anche la SysUtils). Ma dico io??? e il fatto che ogni dannato programma 
cerchi di caricare la dll risorse localizzata all'avvio... capisco anche 
qui la comodità, ma "qualcuno vuole per piacere pensare ai BAMBINI?" 
(utenti). E io che volevo scrivere utility a riga di comando in 
Delphi... follia pura! mi sa che mi conviene abituarmi alla sintassi 
rigidissima del FreePascal...

rigidissima del FreePascal...
si' ok, questo e' il lato negativo di delphi discusso milioni di volte
su questo ng...
ti rispondo con una domanda: preferiresti avere degli eseguibili
relativament piccoli con milioni di dll / ocx (VB like) con relativi
casini di incompatibilita' tra varie applicazioni che usane le stesse
dll, problemi nelle distribuzioni ec...?
cmq per generare exe piccoli puoi usare build with runtime packages
project-options-packages (pero' devi distribuire con la tua
applicazione anche i packages...)
in conclusione, rispndendo al subject .. ti dico che si',
sotstanzialmente sei pazzo!! ;))) no dai sto scherzando :)
Ciao,
Alan Solo

 rigidissima del FreePascal...
Tutt'altro! la puoi fare tranquillamente con una console application (che
tra l'altro crea exe piccolissimi) :)
O anche in finestra per quello.. che importa se ci mette i nomi dei mesi
nell'exe ?
La VCL e' finora la cosa piu' terribilmente complessa, funzionale, veloce,
ben programmata che io abbia mai visto. Prova a pensare che la VCL crea
controlli visuali che sono anche oggetti, beneficiando dell'ereditarieta' e
tutto il resto. Pensa al VB, dove ogni controllo e' quello e basta..
Ciao !                        {MSX}

rigidissima del FreePascal...
Togliendo tutte le uses inutili, come console application, non sono
poi cosi' grandi.
Saluti,
Massimo.

sotstanzialmente sei pazzo!! ;))) no dai sto scherzando :)
e alla Borland non sono pazzi, in compenso fumano cose che non possiamo 
neanche immaginare :)

neanche immaginare :)
no dai, non scherziamo, a costo di ripetermi io Adoro Borland e i suoi
prodotti, e se io fossi un programmatore Borland che ha sviluppato
quei RAD cosi' fatti bene, e tu mi viene a dire, "uffa! ma gli exe
sono troppo grandi e sul mio hd da 30 gb non ci stanno, e poi io
voglio una icona per ogni finestra accipicchia!"... sincermante...
ti manderei a .... ;) dopo che mi sono rotto sviluppando la VCL,
oggetti di ogni genere, wizard, un porting completo su linux....
Beh, ti saluto
Ciao,
Alan Solo

avete mai provato a spiare dentro gli eseguibili, anche i più semplici? 
Sei pazzo.

 cui esegui dei thread separati e "isolati" dal resto del programma...
Ho testato qualche volta il codice messo su questo NG (messaggio di risposta
a me del 1 gennaio 2001 di ACSH )
1. Sovrascrivere il metodo CreateParams della form:
  TForm2 = class(TForm)
  ...
  protected
    procedure CreateParams(var Params: TCreateParams); override;
  ...
  end;
2. Nella sezione implementation della unit scrivere:
procedure TForm2.CreateParams(var Params: TCreateParams);
begin
  inherited;
  Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW;
end;
Questo basta per fare comparire l'icona sulal barra delle applicazioni per
ogni finestra dell'applicazione (se copiato il codice in ogni finestra).
E questo non è un esempio della flessibilità della VCL?? io direi proprio di
sì :)
Ciao
Matteo

Le dll sono un'eredita' del passato (di quel passato dove i pc dovevano fare
stare tutto Win e le applicazioni in 1 o 2 mega di RAM; oggi si viaggia con
macchine che hanno dai 128 in su e il problema di risparmiare qualche decina
di kb di ram non esiste piu') che sarebbe ora di far sparire proprio per
rendere il sistema stabile e affidabile (si sa che il 90% dei casini di Win
deriva proprio da sto cavolo di dll condivise da s/o e applicazioni m$ o
fatte con compilatori m$).
Per quanto riguarda KJK, non riesco a vedere dove stia la praticita' o la
"bellezza" di un eseguibile di 100 K che poi ha necessita' di 30 oggetti
esterni tra ocx e dll (per un totale magari di 6 mega :) ) per funzionare,
con tutti i problemi connessi a registrazione degli ocx, corretta versione
delle dll, ecc.
Viva Borland e suoi exe monolitici :)
Ciao, Sandro

sì :)
grazie mille, ottimo!
poi io direi anche si potrebbe fare una classe base con ad esempio una
propieta' CreateNewIcon (o simile) di tipo booleano, e poi derivare da
essa, senza copiare il codice... evviva la VCL!! ;)
Ciao e grazie di nuovo per la dritta,
Alan Solo

Per quanto riguarda KJK,
8) ah, ti riferivi a me prima? Ci siamo fraintesi, io sono
d'accordissimo con te!! :)
Ciao,
Alan Solo

 d'accordissimo con te!! :)
ti chiedo scusa, la mia non voleva essere tanto una reply a te quanto
un'aggiunta alle tue (giustissime) considerazioni con alla fine una replica
diretta a kjk!
Ciao e buon weekend! Sandro

Ciao e buon weekend! Sandro
anche a te ciao :)
Alan Solo

essa, senza copiare il codice... evviva la VCL!! ;)
magari cosi':
//********************************
unit TMyForm;
interface
uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms,
Dialogs;
type
  TMyForm = class(TForm)
  private
   FCreateNewIcon:boolean;
   procedure CreateParams(var Params: TCreateParams); override;
  public
   constructor Create(AOwner: TComponent; NewIcon: boolean); overload;
  end;
implementation
constructor TMyForm.Create(AOwner: TComponent; NewIcon: boolean); 
begin
 FCreateNewIcon := NewIcon;
 inherited Create(AOwner);
end;
procedure TMyForm.CreateParams(var Params: TCreateParams);
begin
  inherited;
  if FCreateNewIcon
   then Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW;
end;
end.
//********************************
usandolo cosi':
type
  TForm2 = class(TMyForm)
....
var
  Form2: TForm2;
....
Form2 := TForm2.Create(Application); // modo standard
Form2 := TForm2.Create(Application, False);
// in pratica uguale al precedente
Form2 := TForm2.Create(Application, True); // crea una nuova icona
che ne dite? ;)
Ciao,
Alan Solo

Sei pazzo.
ho solo molto tempo da perdere :)
e un complesso di "invidia del pene" rispetto ai programmatori C++

flessibilitŕ della VCL?? io direi proprio di sě :)
grazie mille
non sai quanto l'ho cercata :)

 Delphi? A me rimangono parecchie perplessità...
[cut del resto del msg]
Se intendi la unit Forms, come sembra dal resto del msg, posso essere in
parte d'accordo con te.
Come a volte si scrive, la VCL e' frutto di un compromesso fra RADita' e
OOPita'. Come tutti i compromessi, non puo' soddisfare tutti.
Da semplice utente di strumenti di programmazione (e debug;)) credo che D
(e a maggior ragione la VCL) sia un ottimo strumento che riesce a
mascherare le complessita' intrinseche sia di Win sia dell'OOP senza per
questo negarti il diritto di andare a vedere cosa c'e' sotto (v. ad es. la
risposta alla domanda su come si fa ad avere un button anche per le
finestre (per la quale ringrazio, mi servira' fra poco)).
btw: se vuoi vedere cosa contiene System.pas, aggiungila esplicitamente a
uses e Ctrl-Click: non conosco VC++, ma onestamente dubito che possa
essere + facile aprire un file del suo framework (mfc?). Se vuoi vedere
l'implementazione di funzioni built-in (come Assigned) metti un breakpoint
sull'istruzione ed apri la finestra della CPU (tip ricevuto su
libero.delphi (Dessena?)).
Una cosa che mi sembra fortemente migliorabile in Delphi e' tutta la parte
di documentazione in linea. Voglio dire: con il Code Explorer, e' piu'
navigabile il sorgente della VCL che l'help (a dire il vero, questo e' un
complimento all'IDE).
Se si vogliono eseguibili ridotti all'osso c'e' sempre Dev-Cpp (IDE in
Delphi e Mingw dietro), o il BCC55 (se non sbaglio), oltre al Builder che
ti da' il compilatore Cpp + la VCL (non conosco il FreePascal).
Fortunatamente non ho finora avuto problemi di spazio o necessita'
particolari di efficienza a runtime: se devo mandare per mail un prototipo
di eseguibile trovo *ottimo* poter fare a meno di ocx o dll verie ed uso
UPX per comprimerlo.
In conclusione e per rispondere alla tua domanda, non credo sia pazzo, ma
se effettivamente hai grossi problemi di prestazioni / ottimizzazione /
dimensioni dell'eseguibile forse D non e' davvero la scelta giusta per te.
Almeno, per il poco di D che conosco: lieto se saro' smentito.
Saluti
Paolo Arosio
--
absit iniuria verbis

 rendere il sistema stabile e affidabile [...]
Scusa ancora, ma questo e' proprio il gioco di WIntel, per quel che ne
capisco.


fatte con compilatori m$).
A me non dispiace tanto l'idea che parte dell'app risieda su dll. Ti
immagini se, ogni volta che M$ aggiorna le librerie di sistema,
dovessimo procurarci gli aggiornamenti di tutti gli eseguibili
ricompilati??
Il problema e' semmai nell'approccio del moderno e futuribile Windows.
Sui vecchi e obsoleti sistemi Linux/Unix ogni aggiornamento "critico"
alle librerie ha un suo numero di versione, a cui viene associato un
link con un nome generico. Cosi' i vari sw non sono al corrente
dell'aggiornamento, pero' e' sempre possibile, in caso di
incompatibilita', fare in modo che un particolare sw continui ad usare
la versione vecchia. Non ti so dire come si fa, pero' e' cosi'.
Ciao
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

 ricompilati??
basterebbe un layer che si occupi di fare da interfaccia tra le chiamate
degli applicativi alle API e a quant'altro fa parte integrante del sistema
operativo, e le librerie vere e proprie. In questo modo gli applicativi
lavorerebbero ad un livello astratto, e non si dovrebbero preoccupare delle
chiamate specifiche delle funzioni delle dll, con tutti i problemi di
versione e differenze di parametri e significati tra i sistemi operativi
(W9x, NT, 2K, ecc.) che ben conosciamo. Una cosa del genere gia' e' stata
implementata con le DirectX, per capirci.
Ciao, Sandro

operativo, e le librerie vere e proprie.
Ah, ecco, pensavo che volessi eliminare del tutto il concetto di
libreria dinamica! :)
Pero' temo che quell'approccio possa essere applicabile su un campo
"limitato" come quello della grafica, non so quanto su una macchina
per intero. In pratica tu vorresti una macchina virtuale su cui far
girare le applicazioni?
Purtroppo credo che le prestazioni non sarebbero il massimo (vedi
Java, dove pero serve alla portabilita').
Secondo me sarebbe bastato un meccanismo di linking con le librerie
solo un po' + oculato.


delphi..
quasi tutto, ahime'


quasi tutto, ahime'
cioé? Un progetto vuoto ti crea una form ttuoform che e' gia' un
oggetto (la cosa che non mi piace semmai e' che tutto cio' che viene
letto da .dfm e' public) cmq direi che completamente OO, o cosa
intendi?
Ciao,
Alan Solo


Ciao,
Andrea

E' un'operazione scocciante, ma ne puň valere la pena.
grazie, non lo sapevo... lo vedo utile anche per i frames...
mi dipiace solo che e' un workaround che alla borland non ci abbiano
pensato di farlo in modo "trasparente"...
Ciao :)
Alan Solo

intendi?
Che l'OP e' misto procedurale-a oggetti, (i tipi stringa, intero, ecc
non sono classi) e questo crea un casino enorme in qualche algoritmo.
Se tutti i tipi fossero subclassi di TObject, un metodo potrebbe
testare la classe attuale di un argomento, senza considerare i casi
particolari dei tipi primitivi. Non ti dico poi se ti viene voglia di
identificare le proprieta' a runtime...
Ciao


identificare le proprieta' a runtime...
anche questo potrebbe essere comodo... (attualmente non ne ho mai
avuto la necessita' e non ne vedo attuazione nella realta')...
ma cmq, non credo che questo possa essere tra le proprieta' (scusa il
gioco di parole) che un linguaggio OO debba avere...
Ciao,
Alan Solo

identificare le proprieta' a runtime...
Pero' secondo me la necessita' di identificare le proprieta' a
run-time e' sorpassabile il + delle volte progettando il sistema in
modo da sfruttare il polimorfismo.

gioco di parole) che un linguaggio OO debba avere...
Tieni conto che Delphi puo' esistere perche' esiste la RTTI :-)
altrimenti addio Object Inspector e compagnia bella


modo da sfruttare il polimorfismo.
Dipende da cosa hai intenzione di fare...io in questo periodo avveo
bisogno di assegnare delle proprieta' a runtime di classi di cui
conosco le proprieta' solo attraverso file di configurazione (e se ci
pensi, non e' una necessita' cosi' poco frequente), pero' davanti alla
TypInfo mi sono arreso :-)
Con D5 sembra vada meglio (uso D4), ma dovrei aggiornarmi


Se usi la STL...
O meglio, la standard library.
STL e libreria standard C++ sono due cose ben distinte.
Giusto per precisione.

gia' non ci avevo pensato (in BCB invece sono classi)
BCB e' un'implementazione di C++.
In C++ solo il tipo stringa e' una classe della libreria standard
(std::string). I tipi predefiniti NON SONO classi.

pensi, non e' una necessita' cosi' poco frequente), 
Mi citi il caso particolare ?

(std::string). I tipi predefiniti NON SONO classi.
gia', hai ragione ... infatti in testa avevo proprio (e solo) le
stringhe
chiedo scusa per l'imprecisone ad entrambi
Ciao,
Alan Solo

 ha scritto nel messaggio
news:3aeaecd9...@news.libero.it...

Per essere ancora piů precisi( non me ne volere... :=) ) una cosa č la
standard library ed un'altra la Standard Template Library( STL ).
Quest'ultima serve per la programmazione generica( si chiama cosě o
sbaglio? ) e per i design-pattern in C++.
Corretto?
Andrea

TypInfo mi sono arreso :-)
ciao, per curiosità ho dato un'occhiata all'help e ho trovato
queste funzioni:
function ComponentToString(Component: TComponent): string;
var
  BinStream:TMemoryStream;
  StrStream: TStringStream;
  s: string;
begin
  BinStream := TMemoryStream.Create;
  try
    StrStream := TStringStream.Create(s);
    try
      BinStream.WriteComponent(Component);
      BinStream.Seek(0, soFromBeginning);
      ObjectBinaryToText(BinStream, StrStream);
      StrStream.Seek(0, soFromBeginning);
      Result:= StrStream.DataString;
    finally
      StrStream.Free;
    end;
  finally
    BinStream.Free
  end;
end;
function StringToComponent(Value: string): TComponent;
var
  StrStream:TStringStream;
  BinStream: TMemoryStream;
begin
  StrStream := TStringStream.Create(Value);
  try
    BinStream := TMemoryStream.Create;
    try
      ObjectTextToBinary(StrStream, BinStream);
      BinStream.Seek(0, soFromBeginning);
      Result := BinStream.ReadComponent(nil);
    finally
      BinStream.Free;
    end;
  finally
    StrStream.Free;
  end;
end;
non so se fanno al caso tuo sono funzioni di streaming su file,
le ho provate e funzionano pero' ti salvano solo alcune proprieta',
quelle "visuali" left,top, caption ecc....
penso ci sia anche la possibilita' di non passare da un file usando
TMemoryStream...
Ciao,
Alan Solo

TMemoryStream...
l'es. che ho riportato utilizza già TMemoryStream, mi sono confuso
con un altro... scusa
Ciao,
Alan Solo

sbaglio? ) e per i design-pattern in C++.
Non capisco che cosa tu voglia dire...
La libreria standard del C++ include i costrutti template per la
programmazione generica (vedi std::vector, std::list, std::string...).

Mi citi il caso particolare ?
Business object. Ho delle classi (derivate da un tipo base) che
rappresentano un dominio, per es. TPersona, con varie proprieta' come
Cognome, Nome, CodiceFiscale, ecc.
Da qualche parte leggo una tabella e devo assegnare il valore alla
proprieta', e so che alla colonna "NOME" e' associata la proprieta'
"Nome". Mi servirebbe qualcosa del tipo
AssignProperty("Nome", MyTable['NOME'])
ma in D4 non ho trovato niente del genere. Mi sembra che in D5 ci sia,
ma devo aggiornarmi, come ho scritto


STL e libreria standard C++ sono due cose ben distinte.
Le mie ultime esperienze con il C++ risalgono ad almeno 5 anni fa....
Mi spieghi cosa e' di preciso la standard library?


queste funzioni:
[...]
Ti ringrazio per la cortesia, pero' a me serve qualcosa del tipo,
disponendo di una classe TPersona con una proprieta' Nome:
AssignProperty('TPersona', 'Nome', 'Pippo');
Credo che in D5 ci sia qualcosa del genere, ma purtroppo TypInfo non
e' documentata, quindi c'e' da fre qualche test.



Ah, non sapevo... :=)
Ma la STL non era stata fatta apposta per lo scopo?
E da quando è affidata a Silicon?
Non l'aveva sviluppata un russo?
Andrea

 - Sir Thomas Beechan a una violoncellista
Ciao !
Andrea

e' documentata, quindi c'e' da fre qualche test.
non so se hai piu' fortuna, questo e' cio' che c'e' scritto nell'help
di D5 Ent. a propposito di typeinfo:
"Certain low-level VCL procedures and functions require run-time type
information pointers as parameters. The actual format of the run-time
type information is internal to the compiler and may change between
releases."
quindi sembra una cosa interna e non toccabile, o almeno non alla luce
del giorno...
...e pensare di fare un metodo del tipo:
proc TPersona.SetProperty( PropertyName: string; AValue: Variant );
begin
 case PropertyName of
  'Nome' : Self.Nome := AValue;
  'Cognome' : Self.Cognome := AValue;
 end;
end;
che dici? fa schifo? beh sě effettivamente.... fammi sapere se risolvi
qualcosa, lo vedo molto interessante...
Ciao,
Alan Solo

che dici? fa schifo? 
già... guarda qui:
// ******************
  {$M+}  // genera informazioni a runtime della classe
  TPersona = class(TObject)
   private
    FNome:string;
    procedure SetNome(ANome: string);
   public
   published
    property Nome: string read FNome write SetNome;
  end;
  {$M-}
var
  Form1: TForm1;
implementation
{$R *.DFM}
procedure TPersona.SetNome(ANome: string);
begin
 FNome := ANome + ' ...sei passato per il setter!';
end;
procedure TForm1.Button1Click(Sender: TObject);
var Persona : TPersona;
begin
 Persona := TPersona.Create;
 try
  SetPropValue( Persona, 'Nome', 'valore variant assegnato');
  ShowMessage( Persona.Nome );
 finally
  Persona.Free;
 end;
end;
// ******************
dimenticavo, usa l unit "typInfo"
Ciao, :)
Alan Solo

Non l'aveva sviluppata un russo?
Certo.

Mi spieghi cosa e' di preciso la standard library?
La libreria standard del C a cui sono aggiunte le nuove classi
contenitori (std::vector, std::list, ...).
L'ultimo standard del C++ risale al 1998.

del C.
Non solo questo.
Per libreria standard si intende anche l'insieme dei contenitori,
ripresi dall'iniziale STL, ma differenziatisi nel tempo.
Comunque siamo OT...

già... guarda qui:
[...]
fa schifo anche quello! ;))
//****************
unit RunTimeInfo;
interface
uses typinfo;
type
  {$M+}
  TRunTimeInfo = class(TObject)
   public
    procedure SetProperty(AProperty: string; AValue: variant);
  end;
  {$M-}
implementation
procedure TRunTimeInfo.SetProperty(AProperty: string; AValue:
variant);
begin
 SetPropValue( Self, AProperty, AValue );
end;
end.
//****************
in qusto modo basta ereditare gli oggetti da TRunTimeInfo (senza
nessuna direttiva al compilatore) e fare
OggettoEredidato.SetProperty('NomeProprietà', 'Valore variant');
Ciao, :)
Alan Solo


wrote:
scusate per il monologo :) ma continuano a venirmi in mente idee,
questo penso sia la versione definitiva:
in pratica si puo' fare:
 Oggetto.PropertyByName('Nome') := <Valore>;
oppure
 variabile := Oggetto.PropertyByName('Nome');
e ora sono soddisfatto... (w Delphi!) ;)
//*** CODE ***
unit RunTimeInfo;
interface
uses typinfo;
type
  {$M+}
  TRunTimeInfo = class(TObject)
   private
    procedure SetPropertyValue(const APropertyName: string; AValue:
variant);
    function  GetPropertyValue(const APropertyName: string): variant;
   public
    property  PropertyByName[const APropertyName: string]: variant
read GetPropertyValue write SetPropertyValue;
  end;
  {$M-}
implementation
procedure TRunTimeInfo.SetPropertyValue(const APropertyName: string;
AValue: variant);
begin
 SetPropValue( Self, APropertyName, AValue );
end;
function TRunTimeInfo.GetPropertyValue(const APropertyName: string):
variant;
begin
 Result := GetPropValue( Self, APropertyName );
end;
Ciao,
Alan Solo

questo penso sia la versione definitiva:
Sei arrivato al limite.
Ormai ti mandi messaggi da solo...

Ormai ti mandi messaggi da solo...
la battuta era voluta ;)
cmq penso che cio' che ho "scoperto" (non e' documentato) possa essere
utile oltre che a Piero Bonano ancha ad altri... e sono orgoglioso di
me (?? ;) e di Delphi!!
ora dalla lista "se dovessi fare queste cose forse Delphi non è la
scelta migliore" posso togliere "informazioni sulle classi a runtime"
!!! :))
Ciao,
Alan Solo

!!! :))
Sul versante RTTI solo Java e' superiore a Delphi (proprio per il
fatto di essere OO puro)


fatto di essere OO puro)
infatti, stavo prorpio pensando a Java, pero' (non si nota minimamente
che sono di parte ;) penso che con delphi almeno hai la possibilità di
scelta, per default (cioè direi il 90% dei casi) non genera
informazioni "inutilmente" a run time...
pero' in quei casi particolari in cui potrebbe far comodo lo si puo'
fare... :)
Ciao,
Alan "Delphi 4ever" Solo ;)