Amiga Foundation Classes

Una libreria FreeWare e Public Domain di Classi di Oggetti per lo sviluppo di software su Amiga e macchine future Amiga Compatibili.

$VER: Amiga Foundation Classes - White Paper V1.15

---

---

1. Sommario:

2.0 - Introduzione
2.1 - Cosa sono le Amiga Foundation Classes
2.2 - Scopo della creazione delle Amiga Foundation Classes
2.3 - Chi potrà usare le Amiga Foundation Classes
2.4 - Futuro delle Amiga Foundation Classes
2.5 - Interfacciamento con i nuovi Amiga-Compatibili OS

3.0 - Specifiche di implementazione
3.1 - Come scrivere una Classe per Amiga Foundation Classes
3.1.1 - Nome della Classe
3.1.2 - Node dei Metodi
3.1.3 - Object Inheritance
3.1.4 - Object Initialization e Object Destruction
3.1.5 - Librerie e versione minima di OS
3.1.6 - Tags
3.2 - Definizione dei codici di errore
3.2.1 - Quando segnalare un codice d'errore
3.2.2 - Come segnalare i codici di errore
3.2.3 - Classificazione dei codici di errore

4.0 - Possibilità di "Porting" delle Classi.
4.1 - Specifiche di Porting.
4.2 - Limiti del Porting.

5.0 - Distribuzione
5.1 - Le Classi compilate
5.2 - Il sorgente delle Classi
5.3 - Disponibilità
5.4 - Informazioni e siti WEB

2.0 - INTRODUZIONE

2.1 - Cosa sono le Amiga Foundation Classes

Con "Amiga Foundation Classes" (per brevità AFC) si intendono una libreria di Classi di Oggetti per la gestione dei più svariati aspetti di Amiga.
Ogni Classe facente parte degli AFC si occuperà di "interfacciare" il programmatore con uno specifico aspetto del Sistema Operativo di Amiga, cercando di rendere più semplice la progettazione e la creazione di applicazioni per i computer Amiga OS.
Le AFC sono state concepite anche per garantire un porting più rapido delle applicazioni Amiga sui prossimi Sistemi Operativi Amiga-Compatibili. Vedi il punto 2.4 per ulteriori spiegazioni.

2.2 - Scopo della creazione delle Amiga Foundation Classes

Le motivazioni che ci hanno spinto a progettare le AFC sono svariate: prima di tutto, la necessità di sfruttare appieno la programmazione orientata agli oggetti (OOP), che permette di "riciclare" il codice già scritto e di inglobarlo all'interno di altre Classi o, più genericamente, di utilizzarlo per più programmi.
Grazie alla ricompilazione delle AFC anche sulle prossime macchine con un OS Amiga-Compatibile sarà, inoltre possibile eseguire rapidamente il porting dei propri prodotti in modo rapidissimo. Vedi il punto 2.4 per ulteriori informazioni.

2.3 - Chi potrà usare le Amiga Foundation Classes

Le AFC saranno disponibili per tutti i programmatori che utilizzino un linguaggio che supporti la OOP. Le AFC potranno essere utilizzate liberamente in programmi sia FreeWare, che ShareWare, PD o Commerciali, senza alcun pagamento di royalties o altro. Probabilmente, nella stesura definitiva del (C)Copyright delle AFC verrà richiesto al programma che utilizza le AFC di inserire un messaggio tipo "Questo programma utilizza le AFC", anche se questo punto non sia ancora stato definito.

2.4 - Futuro delle Amiga Foundation Classes

Le AFC sono anche state sviluppate per garantire una solida base di Oggetti da utilizzare nelle prossime macchine Amiga-compatibili: ricompilando il codice sorgente delle AFC, sarà infatti possibile avere subito un'ottima libreria di Classi sulla quale costruire le applicazioni per i prossimi computer. Il vantaggio derivante dall'utilizzo delle Classi di oggetti, rispetto all'uso diretto delle chiamate al Sistema Operativo, sta appunto nel fatto che le Classi fungono da "intefaccia" tra l'OS e il programmatore: chi ha programmato su Amiga utilizzando le AFC, potrà portare il codice dei propri programmi sulle nuove macchine semplicemente ricompilando i sorgenti ed utilizzando la versione di AFC presenti per la nuova piattaforma sulla quale sta sviluppando.
Grazie alle AFC, i programmatori non saranno più costretti a perdere mesi di sviluppo per imparare a programmare un nuovo OS, ma continueranno ad utilizzare le stesse Classi, con la stessa sintassi e, più in generale, lo stesso comportamento.
Questo dovrebbe portare, almeno nelle nostre intenzioni, ad una netta diminuzione dei tempi di sviluppo a favore di una maggiore e migliore produzione di software. Il pericolo che incombe su ogni nuovo Sistema Operativo sta proprio nella mancanza, già al momento del suo lancio, di software professionale.
Grazie alle AFC, sarà possibile fornire in brevissimo tempo programmi professionali per questi nuovi OS.

2.5 - Interfacciamento con i nuovi Amiga-Compatibili OS

E' nostra intenzione fornire gratuitamente i sorgenti delle AFC agli sviluppatori di OS compatibili con quello attuale di Amiga. Siano essi Phase5, VISCorp, Be Inc., AROS, p-OS, PIOS, ecc.
Siamo infatti convinti che il futuro di una nuova piattaforma, non legata a Micros*ft, sia da ricercarsi nella possibilità di avere in breve tempo del software professionale e stabile.
I sorgenti di AFC verranno quindi forniti gratuitamente a tutti gli sviluppatori di OS che ne faranno richiesta. La loro implementazione, dovrà però essere successivamente analizzata dai responsabili di AFC per garantire il loro effettivo funzionamento e permetterne la distribuzione.
Per ulteriori informazioni, vedi paragrafo 5.0 e successivi.

3.0 - SPECIFICHE DI IMPLEMENTAZIONE

3.1 - Come scrivere una Classe per Amiga Foundation Classes

3.1.1 - Nome della Classe

· La Classe deve avere un nome univoco e chiaro.
· Il nome della classe deve essere tutto in minuscolo.
· Il nome della classe deve essere in inglese.
· Il nome della classe NON deve confondersi con il nome di una struttura di Amiga. Nel caso sia necessario utilizzare un nome uguale ad una struttura Amiga, si dovrà aggiungere il suffisso "_obj", anche se il linguaggio usato non lo richiederebbe. Per es. una Classe per gestire le bitmap, si dovrà chiamare "bitmap_obj".
· Nel caso si sia in dubbio se l'eventuale nome di una Classe potrebbe collidere con il nome di una struttura, sarà conveniente terminare il nome della classe con "_obj" in ogni caso.

3.1.2 - Nome dei Metodi

· Il Nome dei Metodi deve essere il più corto e più chiaro possibile. Per es. in una classe che gestisce una lista di nodi, il metodo per aggiungere un nodo NON si dovrà chiamare "addnode", ma semplicemente "add".
· Il nome dei Metodi deve essere tutto in minuscolo.
· Il nome dei Metodi deve essere in inglese.

3.1.3 - Object Inheritance

La caratteristica di Object Inheritance propria della OOP deve essere utilizzata IL MENO POSSIBILE. Questo perchè la Object Inheritance viene implementata in modo differente nei vari linguaggi. Nei sorgenti di AMF, per semplificare la leggibilità e l'eventuale Porting, tutto deve essere il più chiaro e lineare possibile. E' quindi VIETATO l'utilizzo di particolari strutture o costrutti delle classi caratteristici di un particolare linguaggio. Ad es. costrutti di tipo "friend" o la Multiple Inheritance del C++ NON sono consentiti.

Al posto della Object Inheritance è consigliabile creare un'istanza della Classe che si desirera "riutilizzare" all'interno della nuova Classe. Per esempio, se creiamo la Classe "picture" (notate: tutto in minuscolo e in inglese) che "potrebbe" ereditare una Classe "bitmap_obj", è consigliabile inserire un'istanza della Classe "bitmap_obj" all'interno della classe "picture".

3.1.4 - Object Initialization e Object Destruction

· L'inizializzazione e la distruzione di una Classe deve sempre avvenire tramite due Metodi particolari: quello di Inizializzazione e quello di distruzione.
· Il metodo di inizializzazione DEVE chiamarsi col nome della Classe stessa. Per esempio, il metodo di inizializzazione della Classe "picture" dovrà chiamarsi "picture()" (con eventuali parametri tra parentesi, qui omessi per leggibilità).
· Il metodo di distruzione di una classe, invece, DEVE chiamarsi "end()" e NON deve ricevere alcun parametro.
· Questi due metodi di Inizializzazione e Distruzione devono essere invocati in maniera ESPLICITA dal programma che utilizza la Classe: non bisogna assolutamente fare affidamento sulle routine di Inizializzazione e Distruzione presenti nel linguaggio ospitante.
· Nel caso che una Classe ne "inglobi" un'altra, dovrà chiamare nel proprio Metodo di inizializzazione il Metodo di inizializzazione della Classe "inglobata". Per es. la Classe "picture", che contiene "bitmap_obj", dovrà chiamare, all'interno di "picture()" il metodo "bitmap_obj()" legato all'istanza della Classe "bitmap_obj".

3.1.5 - Librerie e Versione minima di OS

· Le Classi create devono appoggiarsi il meno possibile su librerie fornite da terz parti, che non facciano parte, cioè, di quelle normalmente fornite con AmigaOS. Una Classe "picture" che si basi sulla "iff.library", ad esempio, non verrà presa in considerazione, in quanto è possibile caricare le immagini anche tramite la "iffparse.library" e poi scrivere l'algoritmo di ByteRun-deconding.

· L'utilizzo di librerie di terze parti, tra l'altro, penalizza le Classi, dal momento che è possibile che queste librerie non vengano poi aggiornate per funzionare correttamente con i nuovi Sistemi Operativi.

· La versione minima supportata dalle AFC è la 2.04. Se delle Classi risulteranno compatibili anche OS1.3, questo potrà essere segnalato, ma non è una caratteristica fondamentale.
· Nel caso che alcune Classi richiedano esplicitamente una versione più recente di OS per funzionare correttamente, dovrà essere segnalato all'interno della documentazione.

3.1.6 - Tags

Dove possibile, la Classe dovrà essere modificabile tramite dei Tags, propri del sistema AmigaOS. I Metodi di "modifica" standard, tramite Tags si devono chiamare:

· "setattrs(tags)" per il settaggio dei tags.
· "getattr(tag)" per ricevere UN singolo valore di ritorno, fornendo un tag come parametro.
· "getattrs(tags)" nel caso si desideri implementare un Metodo che ritorni più risultati con una singola chiamata.

3.2 - Definizione dei codici di errore

Le AFC devono garantire un'ottima risposta a comportamenti non previsti durante la loro progettazione. Per dirla in parole povere, devono essere "a prova di scemo". Se l'utente sbaglia a chiamare un Metodo, o lo chiama prima di aver concluso un processo di inizializzazione o cose del genere, la Classe deve essere in grado di intercettare l'errore e segnalarlo, magari cercando anche di continuare comunque.
E' per questo che è necessario classificare e segnalare all'utente il maggior numero di errori possibili. Cercando, dove è possibile, di essere chiari, per facilitare la sessione di debug.

3.2.2 - Come segnalare i codici di errore

Per segnalare un errore, in tutti i linguaggi che lo supportano, è preferibile utilizzare le "Eccezioni", nei linguaggi a oggetti che non supportano le "Eccezioni", sarà necessario creare una Classe "error_obj" nella quale verrà memorizzato il codice di errore e i Metodi che verranno chiamati erroneamente dovranno ritornare False, dopo aver settato "error_obj" con il codice di errore appropriato.

3.2.3 - Classificazione dei codici di errore

4.0 - POSSIBILITA' DI "PORTING" DELLE CLASSI

4.1 - Specifiche di Porting.

Le AFC possono (e devono) essere portate su più linguaggi possibile. Il porting deve seguire tutti i punti riportati nei capitoli 2 e 3. Eventuali modifiche funzionali sulla Classe NON SONO AMMESSE, mentre, nel caso che la Classe esegua delle operazioni non impementabili (per es. fornire più di un valore di ritorno da una funzione) queste cose potranno essere "adattate" da colui che eseguirà il "Porting".

4.2 - Limiti del Porting

5.0 - DISTRIBUZIONE

5.1 - Le Classi compilate

Le Classi compilate, i file ".obj" del C++ o i file ".m" di Amiga E per intenderci, potranno essere liberamente distribuite e dovranno essere inserite in una directory chiamata "AFC".

All'interno di ogni file ".lha" contenente la Classe sarà presente anche la documentazione in formato Amiga Guide e dei sorgenti d'esempio.

5.2 - Il sorgente delle Classi

Il sorgente delle Classi NON è Pubblico Dominio e per tanto NON viene distribuito assieme alla versione compilata delle Classi. Tuttavia, sarà sempre a disposizione dei programmatori che intenderanno eseguire il prorting di una determinata Classe.
Il gruppo di controllo di AFC avrà sempre a disposizione tutti i sorgenti aggiornati e, a sua completa discrezione, potrà decidere se fornire o meno ad un determinato programmatore il sorgente delle Classi.

5.3 - Disponibilità

Le versioni compilate delle AFC potranno essere trovate in questi luoghi:

FTP:
ftp.intercom.it/pub/afc - Sito ufficiale delle Amiga Foundation Classes

5.4 - Informazioni e siti WEB

Per eventuali informazioni aggiuntive o aggiornamenti (anche del testo che state leggendo in questo momento) potrete sempre fare riferimento a:

http://www.intercom.it/~fsoft/afc.html

La pagina ufficiale delle AFC.

Oppure, iscrivetevi alle AFC mailing list, mandando un messaggio a:

afc-list@intercom.it

con nel SUBJECT del messaggio:

subscribe

---

I supervisori: Fabio Rotondo e Andrea Galimberti

---