Ho un modello concettuale per un sistema di oggetti che implica la combinazione di interfacce / protocolli Go / Obj-C con la possibilità di aggiungere metodi virtuali da qualsiasi unità, non solo quella che definisce una classe. L'idea è di consentire le classi aperte di Ruby-ish in modo da poter adottare un approccio minimalista allo sviluppo delle librerie e collegare alle piccole parti di funzionalità effettivamente necessarie all'intero programma.
L'implementazione di questo implica una tabella di metodi contrassegnati come virtuali in una tabella RTTI, a cui è consentito aggiungere funzioni di sistema durante l'inizializzazione del modulo. Dopo aver convertito un oggetto in un'interfaccia, viene eseguita una ricerca Go-style per creare un vtable per quella particolare mappatura e passarlo in modo da poter avere prestazioni paragonabili a C / C ++. In questo caso, i metodi possono essere aggiunti / in seguito / che non erano precedentemente noti e questi nuovi metodi consentono di soddisfare le nuove interfacce; mentre mi piace questa idea perché sembra che sarebbe molto flessibile (ignorando il potenziale per il codice spaghetti, che può accadere con qualsiasi modello che si utilizza a prescindere).
Racchiudendo le chiamate di sistema per i metodi di binding in un insieme di chiamate C-compatibili pulite, si sarebbe anche in grado di integrare il codice con le librerie condivise e mantenere una buona quantità di prestazioni (Go non fa collegamenti condivisi e Obiettivo -C esegue una ricerca dinamica su ciascuna chiamata.)
Esiste un caso d'uso valido per questo modello che ne valga la pena? Per quanto questa estensibilità in stile Dylan sia piacevole a cui accedere, non riesco a portare a un caso d'uso che giustifichi il sovraccarico oltre a "potrebbe rendere alcuni tipi di codice più estendibili negli scenari futuri."