2010-01-19 10 views
13

Ci sono molti articoli e post che spiegano come funziona l'ereditarietà di JavaScript, ma perché è stato implementato JavaScript utilizzando l'ereditarietà prototipale invece dell'ereditarietà classica?Perché JavaScript è stato implementato utilizzando l'ereditarietà prototipale?

Amo JavaScript, quindi non sto dicendo che è una cosa negativa ... Sono solo curioso.

+7

contrassegno come wiki della comunità per favore .. –

+0

Il creatore di JavaScript è un utente StackOverflow? –

+1

@Gaby - C'è una risposta da qualche parte. – ChaosPandion

risposta

1

Penso che sia stato scelto perché è facile da implementare, non richiede parole chiave aggiuntive e gli utenti non hanno bisogno di capirlo per poter usare la lingua. È anche più potente e flessibile dell'eredità basata sulla classe.

È una scelta naturale per un linguaggio non tipizzato. I principali vantaggi dell'ereditarietà basata sulla classe sono che consente la tipizzazione statica e quindi il controllo dei tipi e un'implementazione di ricerca basata su tabelle più veloce.

+0

Mi chiedo dell'argomento "facile da implementare". Anche se questo potrebbe essere corretto rispetto all'ereditarietà degli oggetti, non sembra essere vero quando si considera che le funzioni di prima classe di JavaScript sono davvero potenti e, credo, non così semplici da implementare affatto (applicazioni parziali, chiusure, eccetera.). – stakx

12

A meno che uno dei progettisti di JavaScript non smetta di pesare, possiamo solo ipotizzare. Detto questo, ecco la mia risposta:

JavaScript viene eseguito come viene interpretato, quindi non vi è alcun concetto di separare la dichiarazione di un tipo di oggetto dall'oggetto stesso. È un approccio molto funzionale. L'istanza sta venendo all'esistenza come viene descritta - stiamo sempre operando su istanze attive. Per questo motivo, il concetto di classe - o un "modello di istanza" passivo - non ha un posto reale.

+4

Ci sono molti linguaggi di scripting che usano le classi. –

+0

Questo ha tanto sostanza quanto dire che è un prototipo perché è un prototipo. Non che tu lo dica, ma la conclusione è priva di senso. –

+0

@SeanMcMillan true, non era mia intenzione implicare il linguaggio * deve * funzionare in questo modo perché è un linguaggio di scripting, piuttosto che è abbastanza conveniente. –

8

JavaScript originariamente doveva essere molto simile a Lisp. Anche dopo che la sintassi è stata modificata in modo più simile a C/Java, è ancora Lisp in C's clothing. Penso che la risposta risieda nelle sue origini di programmazione funzionale. Nella pura FP, non esiste uno stato mutabile, il che significa nessun oggetto mutabile. Se si rilassano le regole un po 'e si ottiene un po' di creatività, si finisce con qualcosa come l'ereditarietà di protypal, vale a dire che è possibile estendere gli oggetti ma non modificare l'oggetto originale. Fornisce la stessa potenza dell'ereditarietà e offre comunque un'immutabilità.

Infine, ruotate il linguaggio per far sembrare C++ e Java, e viola, avete new someFunction() e il resto è storia.

+1

Cosa intendi con "non esiste uno stato mutabile, il che significa nessun oggetto mutabile"? –

+0

@Andre: Nella programmazione funzionale ** pura ** (come ad esempio Erlang) tutte le variabili sono costanti. I valori che mantengono non possono essere modificati dopo la creazione della variabile. Poiché ci riferiamo a oggetti che usano variabili, ciò significa che gli oggetti in FP non possono essere modificati: tutti gli oggetti sono costanti. – slebetman

+0

Va bene ma, in javascript, cosa succede se faccio questo: var a = {name = "n", age = 1}. a.age = 2. Cosa sto facendo? re-istanziare 'a'? –

1

L'eredità prototipica (con chiusure) consente ad altri di fare cose che non erano mai state immaginate. È l'unione di diversi paradigmi che si sono uniti per realizzare una programmazione generica.

Con un linguaggio prototipo, è possibile avere "mix-in" per le classi. Puoi realizzare il livello di incapsulamento che desideri, senza parole chiave specifiche per lingua. In breve, i linguaggi prototipo sono fantastici.

Odio dirlo, ma JavaScript e alcune librerie possono fare tutto ciò di cui ho bisogno. Era sovversivo nel suo sviluppo (supposto essere sottomesso a Java). Ha molto potere, nella più semplice delle implementazioni.

Con abbastanza studio/gioco, inizierai a vedere i vantaggi della sua ispirazione. JavaScript è una delle poche lingue che "nasconde" il suo potenziale intenzionalmente. Devi entrare nella politica se vuoi sapere il "perché". Ma è per questo motivo che è fantastico.

+0

@Pestilence, puoi indicarmi alcune risorse per "fare cose che non sono mai state immaginate"? Ad esempio con i mix-in, posso ottenere i metodi da un oggetto impostando il mio prototipo su di esso, ma posso farlo solo una volta, giusto? A meno che non faccia qualcosa senza aver bisogno di prototipi come: - Ho un oggetto X, lo voglio possedere Y.doSomething - X.doSomething = Y.doSomething - (che però imposta solo un riferimento a Y.doSomething, a destra ? Che cosa succede se lo voglio avere in modo indipendente) – ambertch

+0

Bene, emulare l'ereditarietà della classe è una cosa che puoi fare ... Ma non devi davvero preoccuparti delle gerarchie in un linguaggio tipizzato dinamicamente. Basta clonare uno o più dei tuoi prototipi in una nuova istanza. Le cose che puoi fare, includono: Creare dinamicamente "classi" e istanze mediante metodi di mixaggio e inizializzatori da altre "classi". Alterazione programmatica dell'interfaccia durante la "costruzione". Anche cambiando le "classi" di base. La modifica di tutti gli oggetti stringa per includere i metodi Base64 è qualcosa che mi piace fare: "foo" .base64(). – pestilence669

+0

L'attributo prototipo a cui ti riferisci è, può essere considerato opzionale, per classi personalizzate. Puoi prendere il controllo e bypassarlo completamente. – pestilence669

5

Perché è stato fortemente influenzato dal Sé. Sia Wikipedia che le specifiche ECMA lo menzionano.

15

Ecco cosa Brendan Eich ha da dire su quello che è successo: http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html

Come ho detto spesso, e come altri a Netscape possono confermare, mi è stato reclutato a Netscape con la promessa di "Schema fare "nel browser. Almeno la gestione ingegneristica del cliente, tra cui Tom Paquin, Michael Toy e Rick Schell, insieme a un ragazzo di nome Marc Andreessen, erano convinti che Netscape avrebbe dovuto incorporare un linguaggio di programmazione, in formato sorgente, in HTML.

Il diktat della gestione tecnica superiore era che il linguaggio doveva "assomigliare a Java". Ciò escludeva Perl, Python e Tcl, insieme a Scheme.

Non sono orgoglioso, ma sono felice di aver scelto le funzioni di prima classe di Scheme e i prototipi Self-ish (anche se singolari) come ingredienti principali. Le influenze di Java, in particolare i bug di data y2k, ma anche la distinzione primitiva rispetto all'oggetto (ad esempio, stringa contro stringa), erano sfavorevoli.

Problemi correlati