Perché è OK e principalmente previsto:

abstract type Shape
{
   abstract number Area();
}

concrete type Triangle : Shape
{
   concrete number Area()
   {
      //...
   }
}

... mentre questo non è OK e nessuno si lamenta:

concrete type Name : string
{
}

concrete type Index : int
{
}

concrete type Quantity : int
{
}

La mia motivazione è massimizzare l'uso del sistema di tipi per la verifica della correttezza in fase di compilazione.

PS: sì, ho letto questo e il wrapping è un bizzarro rimedio.

Suppongo che stai pensando a linguaggi come Java e C #?

In quei linguaggi le primitive (come int) sono sostanzialmente un compromesso per le prestazioni. Non supportano tutte le funzionalità degli oggetti, ma sono più veloci e con meno spese generali.

Affinché gli oggetti supportino l'ereditarietà, ogni istanza deve "conoscere" in fase di esecuzione di quale classe è un'istanza. Altrimenti i metodi ignorati non possono essere risolti in fase di esecuzione. Per gli oggetti ciò significa che i dati di istanza sono archiviati in memoria insieme a un puntatore all'oggetto classe. Se tali informazioni dovessero anche essere archiviate insieme a valori primitivi, i requisiti di memoria aumenterebbero. Un valore intero a 16 bit richiederebbe i suoi 16 bit per il valore e inoltre la memoria a 32 o 64 bit per un puntatore alla sua classe.

Oltre al sovraccarico di memoria, ci si aspetterebbe anche di essere in grado di scavalcare le operazioni comuni su primitive come gli operatori aritmetici. Senza sottotipi, operatori come +possono essere compilati in una semplice istruzione di codice macchina. Se potrebbe essere sostituito, è necessario risolvere i metodi in fase di esecuzione, un'operazione molto più costosa. (È possibile che C # supporti il ​​sovraccarico dell'operatore, ma questo non è lo stesso. Il sovraccarico dell'operatore viene risolto al momento della compilazione, quindi non è prevista una penalità di runtime predefinita.)

Le stringhe non sono primitive ma sono ancora "speciali" nel modo in cui sono rappresentate nella memoria. Ad esempio, sono "internati", il che significa che due letterali di stringhe uguali possono essere ottimizzati allo stesso riferimento. Ciò non sarebbe possibile (o almeno molto meno efficace) se anche le istanze di stringa dovessero tenere traccia della classe.

Quello che descriveresti sarebbe sicuramente utile, ma supportarlo richiederebbe un sovraccarico prestazionale per ogni uso di primitive e stringhe, anche quando non sfruttano l'ereditarietà.

Il linguaggio Smalltalk fa (credo) permettono sottoclasse di interi. Ma quando è stato progettato Java, Smalltalk è stato considerato troppo lento e il sovraccarico di avere tutto come oggetto era considerato uno dei motivi principali. Java ha sacrificato l'eleganza e la purezza concettuale per ottenere prestazioni migliori.

Ciò che alcune lingue propongono non è la sottoclasse, ma il sottotipo . Ad esempio, Ada ti consente di creare tipi o sottotipi derivati . L' Ada Programming / Tipo di sistema sezione è la pena di leggere per capire tutti i dettagli. È possibile limitare l'intervallo di valori, che è quello che si desidera la maggior parte del tempo:

 type Angle is range -10 .. 10;
 type Hours is range 0 .. 23; 

Puoi usare entrambi i tipi come numeri interi se li converti esplicitamente. Nota anche che non puoi usarne uno al posto di un altro, anche quando gli intervalli sono strutturalmente equivalenti (i tipi sono controllati dai nomi).

 type Reference is Integer;
 type Count is Integer;

I tipi sopra indicati sono incompatibili, anche se rappresentano lo stesso intervallo di valori.

_{(Ma puoi usare Unchecked_Conversion; non dire alla gente che te l'ho detto)}

Penso che questa potrebbe benissimo essere una domanda X / Y. Punti salienti, dalla domanda ...

La mia motivazione è massimizzare l'uso del sistema di tipi per la verifica della correttezza in fase di compilazione.

... e dal tuo commento elaborando:

Non voglio essere in grado di sostituirne uno implicitamente un altro.

Mi scusi se mi manca qualcosa, ma ... Se questi sono i tuoi obiettivi, allora perché mai stai parlando di eredità? La sostituibilità implicita è ... come ... tutta la sua cosa. Sai, il principio di sostituzione di Liskov?

Ciò che sembra desiderare, in realtà, è il concetto di un "typedef forte", in base al quale qualcosa "è" ad es. intIn termini di portata e rappresentazione ma non può essere sostituito in contesti che si aspettano inte viceversa. Suggerirei di cercare informazioni su questo termine e su come la lingua o le lingue prescelte potrebbero chiamarlo. Ancora una volta, è praticamente letteralmente l'opposto dell'eredità.

E per coloro a cui potrebbe non piacere una risposta X / Y, penso che il titolo potrebbe essere ancora responsabile con riferimento a LSP. I tipi primitivi sono primitivi perché fanno qualcosa di molto semplice, ed è tutto ciò che fanno . Consentire loro di essere ereditati e rendere così infiniti i loro possibili effetti porterebbe a una grande sorpresa nella migliore delle ipotesi e una fatale violazione di LSP nel peggiore dei casi. Se posso ipotizzare ottimisticamente che a Thales Pereira non dispiacerà che citi questo commento fenomenale:

C'è il problema aggiunto che se qualcuno fosse in grado di ereditare da Int, avresti un codice innocente come "int x = y + 2" (dove Y è la classe derivata) che ora scrive un registro nel database, apre un URL e in qualche modo resuscitare Elvis. I tipi primitivi dovrebbero essere sicuri e con comportamenti più o meno garantiti e ben definiti.

Se qualcuno vede un tipo primitivo, in un linguaggio sano, giustamente presumono che farà sempre la sua piccola cosa, molto bene, senza sorprese. I tipi primitivi non hanno dichiarazioni di classe disponibili che segnalano se possono o meno essere ereditati e hanno i loro metodi sovrascritti. Se lo fossero, sarebbe davvero sorprendente (e romperebbe totalmente la compatibilità all'indietro, ma sono consapevole che è una risposta all'indietro al "perché X non è stato progettato con Y").

... anche se, come ha sottolineato Mooing Duck in risposta, i linguaggi che consentono il sovraccarico dell'operatore consentono all'utente di confondersi in misura simile o uguale se lo desiderano, quindi è dubbio che questo ultimo argomento valga. E smetterò di riassumere i commenti degli altri ora, eh.

Per consentire l'ereditarietà con l'invio virtuale 8 che è spesso considerato abbastanza desiderabile nella progettazione dell'applicazione), è necessario disporre di informazioni sul tipo di runtime. Per ogni oggetto, devono essere memorizzati alcuni dati relativi al tipo di oggetto. Un primitivo, per definizione, manca di queste informazioni.

Esistono due linguaggi OOP tradizionali (gestiti, eseguiti su una VM) che presentano primitive: C # e Java. Molte altre lingue non hanno primitivi, né usano ragionamenti simili per permetterli / usarli.

I primitivi sono un compromesso per le prestazioni. Per ogni oggetto, è necessario spazio per l'intestazione dell'oggetto (in Java, in genere 2 * 8 byte su macchine virtuali a 64 bit), oltre ai relativi campi e l'eventuale riempimento (in Hotspot, ogni oggetto occupa un numero di byte che è un multiplo di 8). Quindi un intoggetto as avrebbe bisogno di almeno 24 byte di memoria da conservare, invece di soli 4 byte (in Java).

Pertanto, sono stati aggiunti tipi primitivi per migliorare le prestazioni. Rendono molto più semplici. Cosa a + bsignifica se entrambi sono sottotipi di int? È necessario aggiungere un qualche tipo di dispathcing per scegliere l'aggiunta corretta. Questo significa spedizione virtuale. Avere la possibilità di utilizzare un codice operativo molto semplice per l'aggiunta è molto, molto più veloce e consente ottimizzazioni in fase di compilazione.

Stringè un altro caso. Sia in Java che in C #, Stringè un oggetto. Ma in C # è sigillato e in Java il suo finale. Ciò perché entrambe le librerie standard Java e C # richiedono che Strings sia immutabili e la loro sottoclasse li spezzerebbe l'immutabilità.

Nel caso di Java, la VM può (e fa) internare stringhe e "raggrupparle", consentendo prestazioni migliori. Funziona solo quando le stringhe sono veramente immutabili.

Inoltre, raramente è necessario sottoclassare i tipi primitivi. Finché i primitivi non possono essere suddivisi in sottoclassi, ci sono un sacco di cose ordinate che la matematica ci dice su di loro. Ad esempio, possiamo essere sicuri che l'addizione sia commutativa e associativa. Questo è qualcosa che ci dice la definizione matematica di numeri interi. Inoltre, in molti casi possiamo facilmente preimpostare gli invarianti su circuiti tramite induzione. Se consentiamo la sottoclasse di int, perdiamo quegli strumenti che la matematica ci fornisce, perché non possiamo più essere certi che determinate proprietà siano valide. Quindi, direi che la capacità di non essere in grado di sottoclassare i tipi primitivi è in realtà una buona cosa. Meno cose che qualcuno può rompere, oltre a un compilatore può spesso dimostrare di essere autorizzato a fare determinate ottimizzazioni.

Nei linguaggi OOP statici forti tradizionali, la sottotipo è vista principalmente come un modo per estendere un tipo e sovrascrivere i metodi attuali del tipo.

Per fare ciò, gli 'oggetti' contengono un puntatore al loro tipo. Questo è un sovraccarico: il codice in un metodo che utilizza Shapeun'istanza deve prima accedere alle informazioni sul tipo di tale istanza, prima di conoscere il Area()metodo corretto da chiamare.

Una primitiva tende a consentire solo operazioni su di essa che possono tradursi in istruzioni in un singolo linguaggio macchina e che non portano alcuna informazione di tipo con esse. Rendere un numero intero più lento in modo che qualcuno potesse sottoclassarlo non era abbastanza attraente da impedire a qualsiasi lingua che lo facesse diventare mainstream.

Quindi la risposta a:

Perché i linguaggi OOP statici forti tradizionali impediscono di ereditare le primitive?

È:

• C'era poca richiesta
• E avrebbe reso la lingua troppo lenta
• Il sottotipo era principalmente visto come un modo per estendere un tipo, piuttosto che un modo per ottenere un migliore controllo statico del tipo (definito dall'utente).

Tuttavia, stiamo iniziando a ottenere lingue che consentono il controllo statico basato su proprietà di variabili diverse da "type", ad esempio F # ha "dimensione" e "unità" in modo che non sia possibile, ad esempio, aggiungere una lunghezza a un'area .

Ci sono anche lingue che consentono "tipi definiti dall'utente" che non cambiano (o scambiano) ciò che fa un tipo, ma aiutano solo con il controllo statico del tipo; vedi la risposta di coredump.

Non sono sicuro se sto trascurando qualcosa qui, ma la risposta è piuttosto semplice:

1. La definizione di primitive è: i valori primitivi non sono oggetti, i tipi primitivi non sono tipi di oggetti, le primitive non fanno parte del sistema di oggetti.
2. L'ereditarietà è una caratteristica del sistema a oggetti.
3. Ergo, i primitivi non possono prendere parte all'eredità.

Si noti che in realtà ci sono solo due potenti linguaggi OOP statici che hanno persino primitive, AFAIK: Java e C ++. (In realtà, non sono nemmeno sicuro di quest'ultimo, non so molto sul C ++ e ciò che ho trovato durante la ricerca era confuso.)

In C ++, le primitive sono fondamentalmente un retaggio ereditato (gioco di parole) da C. Quindi, non prendono parte al sistema a oggetti (e quindi all'ereditarietà) perché C non ha né un sistema a oggetti né eredità.

In Java, le primitive sono il risultato di un tentativo errato di migliorare le prestazioni. I primitivi sono anche gli unici tipi di valore nel sistema, infatti è impossibile scrivere tipi di valore in Java ed è impossibile che gli oggetti siano tipi di valore. Quindi, a parte il fatto che i primitivi non prendono parte al sistema degli oggetti e quindi l'idea di "eredità" non ha nemmeno senso, anche se tu potessi ereditare da loro, non saresti in grado di mantenere il " valore-ness". Questo è diverso da es C♯ quale ha avere tipi valore ( structs), che comunque sono oggetti.

Un'altra cosa è che non essere in grado di ereditare non è in realtà unico nemmeno per i primitivi. In C, structs eredita implicitamente System.Objecte può implementare interfaces, ma non può né ereditare né ereditare da classes o structs. Inoltre, sealed classnon è possibile ereditare es. In Java, final classnon è possibile ereditare es.

tl; dr :

Perché i linguaggi OOP statici forti tradizionali impediscono di ereditare le primitive?

1. le primitive non fanno parte del sistema di oggetti (per definizione, se lo fossero, non sarebbero primitive), l'idea di eredità è legata al sistema di oggetti, l'eredità ergo primitiva è una contraddizione in termini
2. le primitive non sono uniche, molti altri tipi non possono essere ereditati ( finalo sealedin Java o C♯, structs in C♯, case classes in Scala)

Joshua Bloch in "Effective Java" raccomanda di progettare esplicitamente per l'ereditarietà o vietarlo. Le classi primitive non sono progettate per l'ereditarietà perché sono progettate per essere immutabili e consentire l'ereditarietà potrebbe cambiare ciò nelle sottoclassi, infrangendo così il principio di Liskov e sarebbe fonte di molti bug.

Ad ogni modo, perché questa è una soluzione caotica? Dovresti davvero preferire la composizione rispetto all'eredità. Se il motivo è la prestazione di quanto tu abbia un punto e la risposta alla tua domanda è che non è possibile mettere tutte le funzionalità in Java perché ci vuole tempo per analizzare tutti i diversi aspetti dell'aggiunta di una funzione. Ad esempio Java non aveva Generics prima della 1.5.

Se hai molta pazienza, allora sei fortunato perché esiste un piano per aggiungere classi di valore a Java che ti permetterà di creare le tue classi di valore che ti aiuteranno ad aumentare le prestazioni e allo stesso tempo ti daranno maggiore flessibilità.

A livello astratto, puoi includere tutto ciò che desideri in una lingua che stai progettando.

A livello di implementazione, è inevitabile che alcune di queste cose siano più semplici da implementare, alcune saranno complicate, alcune possono essere rese veloci, altre sono destinate ad essere più lente, e così via. Per tenere conto di ciò, i progettisti spesso devono prendere decisioni e compromessi difficili.

A livello di implementazione, uno dei modi più veloci che abbiamo trovato per accedere a una variabile è scoprire il suo indirizzo e caricare il contenuto di tale indirizzo. Nella maggior parte delle CPU ci sono istruzioni specifiche per il caricamento dei dati dagli indirizzi e quelle istruzioni di solito devono sapere quanti byte devono caricare (uno, due, quattro, otto, ecc.) E dove inserire i dati che caricano (registro singolo, registro coppia, registro esteso, altra memoria, ecc.). Conoscendo la dimensione di una variabile, il compilatore può sapere esattamente quale istruzione emettere per gli usi di quella variabile. Non conoscendo la dimensione di una variabile, il compilatore dovrebbe ricorrere a qualcosa di più complicato e probabilmente più lento.

A livello astratto, il punto del sottotipo è di poter usare istanze di un tipo in cui è previsto un tipo uguale o più generale. In altre parole, può essere scritto un codice che prevede un oggetto di un determinato tipo o qualcosa di più derivato, senza sapere in anticipo cosa sarebbe esattamente questo. E chiaramente, poiché più tipi derivati ​​possono aggiungere più membri di dati, un tipo derivato non ha necessariamente gli stessi requisiti di memoria dei suoi tipi base.

A livello di implementazione, non esiste un modo semplice per una variabile di dimensioni predeterminate di contenere un'istanza di dimensioni sconosciute e di avere accesso in un modo che normalmente chiamereste efficiente. Ma c'è un modo per spostare un po 'le cose e usare una variabile non per immagazzinare l'oggetto, ma per identificare l'oggetto e lasciare che l'oggetto sia immagazzinato altrove. In questo modo è un riferimento (ad es. Un indirizzo di memoria) - un ulteriore livello di riferimento indiretto che garantisce che una variabile debba contenere solo un tipo di informazioni di dimensioni fisse, purché sia ​​possibile trovare l'oggetto attraverso tali informazioni. Per ottenere ciò, dobbiamo solo caricare l'indirizzo (dimensione fissa) e quindi possiamo lavorare come al solito usando quegli offset dell'oggetto che sappiamo essere validi, anche se quell'oggetto ha più dati negli offset che non conosciamo. Possiamo farlo perché non

A livello astratto, questo metodo consente di memorizzare un (riferimento a a) stringin una objectvariabile senza perdere le informazioni che lo rendono a string. Va bene per tutti i tipi di lavorare in questo modo e potresti anche dire che è elegante sotto molti aspetti.

Tuttavia, a livello di implementazione, il livello extra di indiretta comporta più istruzioni e sulla maggior parte delle architetture rende ogni accesso all'oggetto un po 'più lento. Puoi consentire al compilatore di ottenere più prestazioni da un programma se includi nella tua lingua alcuni tipi di uso comune che non hanno quel livello extra di riferimento indiretto (il riferimento). Ma rimuovendo quel livello di riferimento indiretto, il compilatore non può più permetterti di sottotipare in modo sicuro dalla memoria. Questo perché se aggiungi più membri di dati al tuo tipo e lo assegni a un tipo più generale, tutti i membri di dati extra che non rientrano nello spazio allocato per la variabile di destinazione verranno eliminati.

In generale

Se una classe è astratta (metafora: una scatola con buche), è OK (anche richiesto di avere qualcosa di utilizzabile!) Per "riempire le buche", ecco perché sottoclassiamo le classi astratte.

Se una classe è concreta (metafora: una casella piena), non è corretto modificare l'esistente perché se è piena, è piena. Non abbiamo spazio per aggiungere qualcosa di più all'interno della scatola, ecco perché non dovremmo sottoclassare classi concrete.

Con i primitivi

I primitivi sono classi concrete dal design. Rappresentano qualcosa che è ben noto, completamente definito (non ho mai visto un tipo primitivo con qualcosa di astratto, altrimenti non è più una primitiva) e ampiamente usato attraverso il sistema. Permettere di sottoclasse di un tipo primitivo e fornire la propria implementazione ad altri che si basano sul comportamento progettato dei primitivi può causare molti effetti collaterali e danni enormi!

Di solito l'ereditarietà non è la semantica che desideri, perché non puoi sostituire il tuo tipo speciale ovunque ci si aspetta una primitiva. Prendendo in prestito dal tuo esempio, a Quantity + Indexnon ha senso semanticamente, quindi una relazione ereditaria è la relazione sbagliata.

Tuttavia, diverse lingue hanno il concetto di un tipo di valore che esprime il tipo di relazione che stai descrivendo. Scala è un esempio. Un tipo di valore utilizza una primitiva come rappresentazione sottostante, ma ha una diversa identità di classe e operazioni all'esterno. Ciò ha l'effetto di estendere un tipo primitivo, ma è più una composizione che una relazione di ereditarietà.