OOBJECT E IL DEBUGGER- Metodi STATICI:
---------------------------------------------------

Fino alla versione 1.b era praticamente impossibile usare il debugger con oObject. Biblioteche object e simili, oClip, oOclip, etc. E' un difetto molto difficile neutralizzare perché il debugger si aspetta un METODO UDF che deve avere lo stesso nome come il METHOD MESSAGE altrimenti esso risponde con "funzione indefinita" e termina; per maggiori dettagli si veda oClip.doc.

Nella versione 2.00, object implementa un modo addizionale per dichiarare nomi di METODi e METODi UDFs con lo stesso nome ma sono anche STATICi nel loro .prg di origine e 100% visibile al debugger. La soluzione era nel lib all'inizio, ma mi è venuto solo una notte alle 3: 00; non avevo che da cambiare gli archivi. Ho giusto aggiunto 4 comandi addizionali nella testata ed tutto funziona!!!

Nota (1): può usare una di queste sintassi nel proprio sorgente. Questo vuole dire che si può mescolare PUBBLICO, STATICO, GETSET, INLINE, BLOCK, LINKED basta seguire le convenzioni sintattiche di ciascun METODO.

Nota (2): Tenete a mente che i Metodi STATICI sono INLINE IVars. Usare questa caratteristica eleverà alla fine il numero di IVars contenute in una classe. appoggi del [oObject] fino a 250 IVars in una classe singola.



Vantaggi di Metodi STATICI:
------------------------------

o  sintassi più Pulita:
I parametri sono passati a ciascuno metodo all'inizializzazione della classe così è più facile fare la revisione e la manutenzione .
o  Dimensione più piccola dell'overhead al runtime:
Ogni METHOD UDFs può essere dichiarato come statico; usando questa tecnica, siha UNA sola funzione pubblica per classe.
o  esecuzione più Veloce:
La classe esegue funzioni STATICHE attraverso blocchi del codice.
o  100% supporto del Debugger:
Poiché metodi e messaggi hanno lo stesso nome, il debugger li vede del tutto transparenti e li processa come funzioni normali.
o  Completa compatibilità della sintassi fra OBJECT 1.00& 2,00:
Gli Utenti di objects.lib(di FiveWin) possono compilare il loro codice usato con oObject.chcon com minime o nessuna modifica.
o  compatibilità con oOBJECT Completa:
Si può usare il proprio codice oObject esistente ogni qualvolta lo si desidera. Nessuna modifica va fatta al sorgente del programma. Davvero, si può utilizzare un qualsiasi programma creato per oOBject  senza qualsiasi problema.
o  implementa il Polymorphism .
o  Ereditarietà non è compromessa dall'uso di funzioni STATICHE. Ricordate di creare l'ALIAS per le parent classes ed usare ALIASed methods per richiamare la parent class.

Svantaggi:
----------
o si deve usare la sintassi alternativa per impiegare questa caratteristica.

o C'è una disputa in corso riguardo alla velocità dei codeblocks nei confronti di funzioni pubbliche.

o Quando si cambiano i parametri passati a un METODO UDF si deve modificare il sorgente in due punti.

o  si può scrivere solo una classe per sorgente .prg altrimenti un METODO UDFs usato in due classi produrrà "nome della funzione duplice" negli avvertimenti del compilatore.



Sintassi:
-------

CLASS Something
...
// Method Messages
// 2 modi per richiamarlo
...
METHOD <Method>( uParms,... ) // Messagio normale 
...
CLASS METHOD <Method>( uParms,... ) // Class Message (non inherited)
...
ENDCLASS

...

// Method UDFs - Lo stesso <Method> di cui sopra...
// 6 modi per richiamarlo.

METHOD <Method>( uParms,... )
...
METHOD FUNCTION <Method>( uParms,... ) CLASS <ClassName>
...
METHOD ClassName::<Method>( uParms,... )
...
METHOD ::<Method>( uParms,... )
...
METHOD <Method>( uParms,... ) CLASS <ClassName>
...
STATIC METHOD <Method>( uParms,... )
...