Object rappresenta qualcosa che è sia la forza che la debolezza della nostra tecnica. Il codice può essere posizionato in una descrizione di classe o implementazione, può essere trasformato o tradotto in un report o può essere nascosto da qualche parte in un programma awk.
Ovviamente, dovremmo stare molto attenti a questa ultima opzione: ooc è pensato per essere usato per più di un progetto; di conseguenza il programma awk dovrebbe essere reso indipendente dalla struttura specifica di un progretto. E' permesso raccogliere informazioni e utilizzarle per le sostituzioni, ed è inoltre possibile collegare gli statement del preprocessore ai reports, ma non si dovrebbe fare affidamento allo specifico contenuto del report o all'ordine in cui il contenuto appare.
I report possono essere cambiati da progetto a progetto ed è qui che però si può rafforzare lo standard di codifica. I report e tutti gli altri file come le descrizioni di classe e le implementazioni sono cercati nelle directory specificate in una variabile d'ambiente OOCPATH. Attraverso questa variabile si possono caricare le differenti versioni dei report per i diversi progetti in essere.
Il nostro approccio per Object illustra la flessibilità dei report: possiamo condividere il codice comune dei report chiamando i report contenuti nei file in comune ed evitiamo nel contempo l'overhead di controllare ogni volta le condizioni di un caso particolare, non generale. Mentre il codice one-of-a-kind può essere scritto in un file di implementaizone, è abbastanza facile scriverlo come report e beneficiare così' del meccanismo di generazione dei report.
In generale, la generazione dei report ha vantaggi e svantaggi. Da un lato, semplifica lo sviluppo di una gerarchia di classi e le variazioni durante la manutenzione perchè i report sono i punti nevralgici per mantenere e rafforzare gli standard di codifica. Se vogliamo tracciare le chiamate ai selettori, per esempio, andremo semplicemente ad inserire una linea di trace nel body del selettore nel file di report.
La generazione dei report occupa però un maggio tempo di esecuzione rispetto alle semplici chiamate a funzione. Un preprocessore dovrebbe generare le stampe #line per il compilatore C così che i messaggi di errore si riferiscano alle linee sorgenti originali. Apparentemente è facile generare le stampe dei numeri di linea ma con il meccanismo dei report in realtà è tutto molto più complesso. Quando i report sono stabili potremmo scrivere un altro preprocessore per generare un programma awk dai reports?