Gdyby zaimplementować Ruby na szczycieSilnik Javascript (w przeglądarce lub na samodzielnym V8 lub Spidermonkey), jakie byłyby niedopasowania impedancji klucza między modelami obiektowymi Ruby i JS?
Odpowiedzi:
7 dla odpowiedzi № 1Najbardziej oczywisty jest fakt, że ECMAScript jest oparty na prototypach, a Ruby jest oparty na klasie plus mixin. Również w Ruby enkapsulacja odbywa się za pomocą obiektów, w ECMAScript z zamknięciami.
Sądzę jednak, że konstrukcje kontroli przepływu Ruby będą znacznie trudniejsze niż jej model obiektowy. W końcu, JS.Class Jamesa Coglana jest w zasadzie implementacja modelu obiektowego Ruby w ECMAScript i nie jest tak duża.
ECMAScript po prostu nie ma narzędzi potrzebnych do zbudowania własnych konstrukcji kontroli. Zazwyczaj potrzebujesz albo GOTO, kontynuacje lub prawidłowe ogony. Jeśli masz jedną z nich, możesz łatwo wdrożyć wszystko inne: wyjątki, pętle, przełączniki, wątki, Fibers, generatory, coroutines… nazywacie to.
Ale ECMAScript ich nie ma (i nie bez powodu, przynajmniej w przypadku GOTO). Jedyny konstrukt kontroli przepływu ECMAScript ma wystarczającą moc, aby móc budować inne konstrukcje oprócz wyjątków. Niestety są one dość powolne. (Niemniej jednak oni mieć był używany jako substrat implementacyjny, na przykład w kompilatorze Microsoft Live Labs Volta, który używał wyjątków ECMAScript do implementacji wyjątków .NET, iteratorów, generatorów, a nawet wątków.)
Więc w zasadzie utknąłeś przy wdrażaniu przynajmniej własnego stosu wywołań, jeśli nie całego interpretera (jak w przypadku HotRuby), wykonywania globalnych transformacji CPS lub czegoś podobnego.
Zasadniczo co ty chcieć z silnika Ruby działającego na ECMAScript, jest
- wierna implementacja RubySpec (w szczególności konstrukcje kontroli przepływu, takie jak nici, włókna,
throw/catch, wyjątki itp.), - wydajność i
- ścisła integracja z ECMAScript (tj. zdolność do przekazywania obiektów i wywoływania metod tam iz powrotem między dwoma językami).
Niestety, kiedy musisz uciekać się do sztuczek, takich jak zarządzanie własnym stosem, przeprowadzanie transformacji CPS, budowanie na wyjątkach… okazuje się, że możesz wybrać tylko dwa z trzech celów.
3 dla odpowiedzi № 2
- Ruby ma zakres blokowy zmiennych lokalnych, JavaScript ma zakres funkcji
- Dziedziczenie Ruby + mixiny prawdopodobnie byłoby problematyczne do wdrożenia po prostu przy użyciu prototypowego dziedziczenia JavaScript
- Sprawdzanie arity Rubiego pod kątem wywołania metody / lambda i jest bardziej rygorystyczne niż zezwolenie na JavaScript
- Ruby ma prawdziwe, wymuszone stałe; JavaScript może nie (w zależności od wersji, z której korzysta tłumacz)
- Zmienne klasowe (ugh) nie mają odpowiednika w JaveScript, więc będą wymagały specjalnej obsługi
- Ruby ma w rdzeniu zielone wątki, JavaScript nie
2 dla odpowiedzi nr 3
JavaScript jest Turing-complete, więc teoretycznie możesz zaimplementować wszystko, w tym inne języki programowania. Nie ma znaczenia, jak różne są implementacja (JavaScript) i język docelowy (Ruby). The niedopasowanie impedancji między językami takimi jak Ruby i C jest ogromny, a tam masz Ruby, Python, Perl i sam JavaScript, wszystkie zaimplementowane w C.
Implementacja Ruby w JavaScript powinna być zamówieniemo wiele łatwiej niż niż w języku niższego poziomu. Na twoją korzyść masz to, że większość standardowej biblioteki Ruby i Ruby jest napisana w samym Rubim, więc kiedy już dostaniesz podstawowy interpreter, rzeczy powinny się stopniowo pogarszać.
Wdrażanie wydajny Tłumacz języka Ruby w JavaScript może być trudniejszy, ale nadal jest to możliwe. Możesz skończyć z tłumaczeniem języka Ruby na JavaScript, aby umożliwić dostęp do doskonałych optymalizatorów.
Więc nie myśl o różnicach między Ruby a JavaScript. Spójrz na standardową implementację Ruby i zastanów się, jak byś ją zaimplementował który w JavaScript.