Интерпретируемые языки - усиление скомпилированного языка позади интерпретатора
Несколько лет спустя в настоящее время официально существует лучшее решение. DOM4 Mutation Observers заменяют устаревшие события мутации DOM3. Они , которые в настоящее время реализованы в современных браузерах как MutationObserver (или как префикс поставщика WebKitMutationObserver в старых версиях Chrome):
MutationObserver = window.MutationObserver || window.WebKitMutationObserver;
var observer = new MutationObserver(function(mutations, observer) {
// fired when a mutation occurs
console.log(mutations, observer);
// ...
});
// define what element should be observed by the observer
// and what types of mutations trigger the callback
observer.observe(document, {
subtree: true,
attributes: true
//...
});
В этом примере прослушивается DOM изменения на document и все его поддерево, и оно будет срабатывать при изменении атрибутов элемента, а также структурных изменений. Спецификация проекта имеет полный список действительных свойств для прослушивания мутаций :
childList
- Установите значение
true, если мутации для целей дети должны быть обнаружены.attributes
- Установите на
true, если необходимо соблюдать мутации для атрибутов цели.characterData
- Установите на
true, если необходимо наблюдать мутации данных цели.поддерево
- Установите, чтобы
true, если мутации не просто нацелены, но также должны наблюдаться потомки цели.attributeOldValue
- Установите значение
trueеслиattributesустановлено значение true и значение атрибута цели до того, как необходимо записать мутацию.characterDataOldValue
- Установите значение
true, еслиcharacterDataустановлено значение true и данные цели до того, как необходимо записать мутацию.attributeFilter
blockquote>
- Установить список локальных имен атрибутов (без пространства имен) если не все атрибутные мутации
(Этот список действует с апреля 2014 года; вы можете проверить спецификацию на любые изменения.)
4 ответа
Строка между "интерпретируемыми" и "скомпилированными" языками действительно нечетка в эти дни. Например, первой вещью, которую делает Python, когда это видит исходный код, является компиляция это в представление байт-кода, по существу то же как, что Java делает при компиляции файлов класса. Это - то, что содержат *.pyc файлы. Затем время выполнения Python выполняет байт-код, не относясь к первоисточнику. Традиционно, чисто интерпретируемый язык относился бы к исходному коду непрерывно при выполнении программы.
При создании языка это - хороший подход для создания прочной основы, на которой можно реализовать высокоуровневые функции. Если у Вас есть твердая, быстрая строковая система обработки, то разработчик языка может (и если) реализуют что-то как stripslashes () вне основного времени выполнения. Это сделано по крайней мере по нескольким причинам:
- Разработчик языка может показать, что язык достаточно выразителен для справлений с такой задачей.
- Разработчик языка на самом деле пишет реальный код на языке, который имеет тесты и поэтому показывает, что основа является прочной.
- Другие люди могут более легко считать, одолжить и даже изменить высокоуровневую функцию, не имея необходимость мочь создать или даже понять ядро языка.
Просто, потому что язык как Python компилирует в байт-код и выполняется, который не означает, что это медленно. Нет никакой причины, почему кто-то не мог записать Своевременный (JIT) компилятор для Python, вроде того, что Java и.NET уже делают, для дальнейшего увеличения производительности. На самом деле IronPython компилирует Python непосредственно в байт-код.NET, который затем выполняется с помощью системы.NET включая JIT.
Для ответа на вопрос непосредственно единственное время, разработчик языка реализовал бы функцию на языке позади времени выполнения (например, C в случае Python) должен будет максимизировать производительность той функции. Поэтому модули, такие как синтаксический анализатор регулярного выражения записаны в C, а не собственном Python. С другой стороны, модуль как getopt.py реализован в чистом Python, потому что он может все быть сделан там и нет никакого преимущества для пользования соответствующей библиотекой C.
Существует также увеличивающаяся тенденция повторно реализовать языки, которые традиционно считают "интерпретируемыми" на платформу как JVM или CLR - и затем предоставляющий легкий доступ к "собственному" коду для совместимости. Таким образом от Jython и JRuby, можно легко получить доступ к коду Java, и от IronPython и IronRuby, можно легко получить доступ к коду.NET.
В случаях как они способность "усилить скомпилированный язык позади интерпретатора" могла быть описана как основной фактор мотивации для новой реализации.
Посмотрите раздел 'Papers' по www.lua.org.
Особенно реализация Lua 5.0
Lua определяет все стандартные функции в базовом (ANSI C) код. Я полагаю, что это главным образом по причинам производительности. Недавно, т.е. 'строка.*' функции получили альтернативную реализацию в чистом Lua, который может оказаться жизненно важным для подпроектов, куда Lua выполняется сверху.NET или Среды выполнения Java (где код C не может использоваться).
Пока Вы используете портативный API для основы скомпилированного кода как ANSI C стандартная библиотека, или STL в C++, затем используя в своих интересах те функции помешал бы Вам изобретать велосипед и вероятно обеспечил бы более быстрый интерпретатор меньшего размера. Lua проявляет этот подход, и это является определенно маленьким и быстрым по сравнению со многими другими.