Это IDispatсh не движка, а скрипта. Он уже есть под именем this. Думаю, что если вы хотите работать с самим движком, придётся вам писать свой скрипт-контрол

В общем-то это и было одним из вариантов решения исходной задачи, однако видимо никаких готовых разработок в этой области нет

Видимо подобное решение останется как рабочий вариант решения задачи, поскольку хоть и не обеспечивает непосредственную модификацию исполняемого потока как объекта первого рода, но тем не менее позволяет обойтись только одной перезагрузкой JS-сценария
Благодаря такой схеме получается полноценная недостающая рефлексия, возможность установки языковых расширений, адекватная обработка ошибок времени исполнения и поддержка передачи событий
Если все перечисленное все-таки можно реализовать без создания новой инстанции ScriptControl, было бы еще лучше - а так задача решена, но только наполовину

Абсолютно солидарен, именно из-за отсутствия следования спецификации EcmaScript и получаются уродцы вроде движка Gecko и недобраузера Firefox, в котором все реализовано через известное место
Насчет node.js знать не знаю, но это не имеет отношения к оригинальному вопросу - нужна рефлексия для JScript вне зависимости от контекстного хост-объекта, а там уже неважно, WMI ли это или node.js, или что-то еще

Ну-ну... Согласно спецификации все свойства глобального объекта вообще не должны быть перечислимыми, однако из-за того что известные реализации имеют еще одно хост-свойство вроде window, то для удобства включен режим перечисления, а также автоматическое включение ссылок между переменными и свойствами глобального объекта
Ни для каких других контекстов это не работает... Так что Вы там и не ответили, какое все это имеет хотя бы малейшее отношение к рефлексии? Причем тут вообще свойства объектов, когда речь идет не о объектах или списках их свойств, а о извлечении информации об исполняемом коде и его элементах

Спасибо за предложенную реализацию! Этот вариант конечно не решает задачу в исходной постановке, но позволяет достичь рефлексии в HTA-приложении, сохраняя возможность использовать WScript-объект

Более того насчет интерфейса IDispath, существует такой метод http://msdn.microsoft.com/en-us/library … s.85).aspx, вероятно его возможно применить для обозначенной цели

Это IDispatсh не движка, а скрипта. Он уже есть под именем this. Думаю, что если вы хотите работать с самим движком, придётся вам писать свой скрипт-контрол.

shiz пишет:

Сомнительно, <script id="scr1" src="external.js"></script>ну и как получить код из external.js?

Очень и очень легко - document.scripts["scr1"].text

На моей памяти свойства src и text были взаимоисключающими. И, хотя я сильно отстал от жизни, боюсь, что в этом отношении всё осталось очень и очень по-прежнему.

Если тебе, как ты говоришь, нужен ScriptControl, то:
1) создаёшь ScriptControl;
2) передаёшь в ScriptControl ссылку на него самого, при желании на WScript или глобальный объект;
3) загружаешь в него на исполнение остальной код.
Ну и что этот код сможет сотворить над собой?

И что там? Берётся код на придуманном языке "jsplusgoto" переводится на настоящий JS и запускается. Что с того, что он берётся из <script>, если у него неизвестный браузеру type. С таким же успехом он мог бы браться из комментария, любого другого невидимого элемента, из переменной, ресурса в WSF. И если в JScript есть некоторые трудности с доступом к глобальному контексту скрипта из локального, то в предложенном извращении со ScriptControl'ом эта библиотека должна заработать с минимальными изменениями.

Что может быть хуже, когда на глубокий вопрос отвечают сказками на уровне учебника для чайников, да и к тому же неправильно

Да, да! Вы верно задали мерило по себе, - ECMAScript в помощь.

Ну, не все читают спецификацию ECMAScript, отсюда различие интерпретаторов. И то, что реализуется в одном браузере вразрез вышеобозначенной спецификации, собственно, и порождает, как правило, кучу словесного поноса и что-то вроде node.js, который в настоящий момент и изобретается автором темы сызнова.

Прямо-таки плевок эстета. Просветите нас, что такое объект в JavaScript, приведите примеры того, как Вы видите рифлексию и то, что именно Вы под ней разумеете, да и вообще - напишите толково о самой сути и философии JavaScript, раз Вы любите бросаться инсинуациями, мол, кругом быдлокнижные дураки, один я умный. Если Ваше величество снизойдет до нас, то книгам по программированию предпочитаю спецификации, отладчики и факты. Последних от Вас не было.

inter-hosting, ну Вам, например, среда HTA нравится? Ничто не мешает, запустить HTA, запустить скрипт на WSH, а их заставить обмениваться данными через "Обмен данными между скрипт-процессами" (решение на форуме есть). Причем в HTA вы запросто можете "экспортировать" объект WScript.

Спасибо большое, что отвечается по существу! (Что может быть хуже, когда на глубокий вопрос отвечают сказками на уровне учебника для чайников, да и к тому же неправильно
Среда HTA она просто великолепна, и действительно там поставленная задача решается в два счета, да и объект WScript действительно как оказывается не сложно экспортировать, НО:
Интересно решение именно для чистого консольного JScript/WSH, чтобы в нем можно было сделать то же самое, что и в браузерном интерпрераторе
Опять-таки для простоты формулировки и единообразия - заставить заработать такую вот библиотеку http://summerofgoto.com/ для JScript/WSH; в браузерном JavaScript она прекрасно работает
Ясно что конечная цель это не использование такой библиотеки, но такой пример сразу отметает оффтопик про ассоциативные массивы и свойства объектов
Как еще один хороший вариает формулировки - получить возможность считывать JOB-элементы из WSF-файла, а также генерировать и удалять их в процессе выполнения WSF-пакета, как минимум - получить идентификатор текущей JOB-задачи

Заранее спасибо

Какбэ... для примера.      .....
Шагаем далее.     ....

Все что здесь Вами указано- это лишь констатация факта, что функции в JS являются объектами первого рода, а также то, что в глобальном пространстве объявляемые переменные автоматически связываются с хост-объектом; тот факт, что свойства без аттрибута DontEnum можно перебрать в for-in цикле, абсолютно никакого отношения к рефлексии не имеют, банальны, неинересны и неизвестны разве что новичкам

Если постоянно не осуществлять изборочные цитирование фраз из контекста, то задача изначально одна и та же, и критерии четкие - рефлексия, чтение/модификация глобального кода и обработка ошибок времени исполнения в WSH/JScript, да так шоб прям:
* Иметь возможность посмотреть полноценный стек вызовов для текущей функции, да так чтобы как в отладчике в браузере - весь набор вышележащих функций, в том числе и анонимных, с номерами строчек и исходным кодом
* Иметь возможность посмотреть список *переменных* в текущем контексте (НЕТ, свойста объектов без аттрибута DontEnum не интересуют вообще)
* В случае WSF-файла иметь возможность определить текущую активную работу/JOB, посмотреть ее исходный код или код любой другой работы, перейти на исполнение другой работы
* Иметь возможность сделать аналог из браузерного JS конструкции window.onerror = function() { return true }   (НЕТ, глобальный try/catch это совершенно другое, в VBScript есть аналогчная вещь, но в JScript нету)
* Иметь возможность сделать аналог из браузерного JS конструкции document.scripts["myscript"].text = superfunction(document.scripts["myscript"].text), да так чтобы состояние всех объектов программы сохранилось, но изменился исходный код следующего исполняемого участка

Считаете что нет четкой формулировки? Их можно сделать много эквивалентных, но пусть будет такая - заставить заработать такую вот библиотеку http://summerofgoto.com/ для JScript/WSH; в браузерном JavaScript она прекрасно работает
Никакие ваши свойства объектов, да и функции первого рода здесь не помогут - нужно то же, что и в оригинальной задаче

Ничего подобного! Мало того что это не имеет отношения к поставленной задачи, к тому же это не совсем правда и зависит от реализации JS-интерпретатора
В некоторых реализациях Gecko обращение к конструкции this.variable снимает DontDelete-флаг ассоццированной var-переменной
Что интересного в том, что JScript-интерпретатор устанавливает символическую ссылку между свойствами хост-объекта и глобальной переменной, не говоря уже о том, что var myvar и GLOBAL.myvar это совершенно две разные вещи

Собственно в этом и состоит вопрос всей рассматриваемой темы
Очень приближенно схема следующая- осуществляется получение указателя на объект текущего интерпретатора, который согласно спецификации WSH/Jscript является OLE-объектом, и уж если IDispatch там не поддерживается, то с помощью библиотеки вроде DynamicWrapperX или каких-то еще внешних средств, осуществить вызов требуемых методов этого  Scripting engine с необходимыми аргементами, вроде http://msdn.microsoft.com/en-us/library … s.85).aspx, которые уже предоставляют настоящую информацию о рефлексии, и http://msdn.microsoft.com/en-us/library … s.85).aspx для модифкации требуемых элементов кода в реальном времени
Более того насчет интерфейса IDispath, существует такой метод http://msdn.microsoft.com/en-us/library … s.85).aspx, вероятно его возможно применить для обозначенной цели

Спасибо

Какбэ... для примера. Функции в JavaScript - это объекты, свойства которых можно перебирать в цикле примерно так:

for (var i in func) {
   alert(i + ': ' + func[i]);
}

На месте func может быть и объект, потому, как говорилось ранее, что функции в JavaScript являются объектами. Объекты же в свою очередь представляют собой хэш-таблицы или, если хотите, ассоциативный массив. Значениями последней(его) могут быть данные простых типов или другие объекты - в обоих случаях они будут именоваться свойствами; помимо значений объект может содержать функции, именуемые методами. Собственно, на этом введение в рефлексию JavaScript можно считать оконченной.
Шагаем далее.
Одним из первых действий, выполняемых любым интерпретатором JavaScript перед исполнением кода - создание глобального объекта, свойства которого представляют собой глобальные переменные сценария JavaScript. Иными словами, определяя глобальную переменную, фактически определяется свойство глобального объекта. О прочих нюансах, пожалуй, говорить пока смысла нет, но вся эта информация по крайней мере должна стать (для того, у кого все же голова там, где ей положено быть) поводом к размышлению.

Если получить подобный объект, то в дальнейшем с ним довольно легко работать

Как именно? Допустим, получили вы указатель на объект, не поддерживающий IDispatch, в переменную (какого типа?), и каковы дальнейшие действия?

inter-hosting, я думаю, что проще рассказать что Вы хотите получить в итоге. Модификация кода в режиме реального времени?

Задача состоит в полноценной рефлексии для JS-определенного кода в текущем сценарии, а также возможности просмотра и модификации глобального пространства сценария в режиме исполнения
Как гипотетический пример - возможность реализации подобной штуки http://summerofgoto.com/ на JScript/WSH

Конечная цель - получить те же средства управления JS-интерпретатором, как и в браузерной версии - как вариант, та же установка window.onerror недоступна в JScript/WSH, однако благодаря рефлексии будет легко сделать и подобную реализацию
Более того в JScript/WSH не хватает инкрементальной загрузки кода, или возможности обращения к произвольному JOB-элементу в WSF-файле

Очень и очень легко - document.scripts["scr1"].text

Спасибо за уделенное внимание, но к сожалению, это совершенно другое и не имеющее отношение к постановке задачи
Разница примерно такая же, как исходный текст в HTML-файле и текущая разметка в режиме реального времени из document.body.innerHTML, которая в общем случае может уже не содержать ни одного элемента из исходного варианта
То же самое требуется и для JScript/WSH- возможность модифицировать JS-код глобальной области в реальном времени, и потом получить его содержание - примерно как в отладчике

===
Важно и если вернуться к ранее описанному моменту:

Если получить подобный объект, то в дальнейшем с ним довольно легко работать http://msdn.microsoft.com/en-us/library … S.85).aspx, и как видно выше, интерфейс WSH поддерживает COM-инфраструктуру, в частности можно получить объект Scripting engine (The OLE object that processes scripts. A scripting engine implements the IActiveScript and, optionally, IActiveScriptParse interfaces. )

Таким образом результирующая задача - COM-получить объект  Scripting engine для текущей инстанции исполняемого JScript-сценария из самого этого сценария

присвойте старой функции новое значение

Зачем? надо просто вызвать другую.

Полностью согласен.

В классическом браузерном JavaScript можно использовать вариант document.scripts, который позволяет как получать доступ к исходному коду исполняемого JS-скрипта

Сомнительно,

<script id="scr1" src="external.js"></script>

ну и как получить код из external.js?

В WSH для доступа к исходному коду исполняемого скрипта надо очевидно прочесть содержимое файла с этим кодом:

source_code = FSO.OpenTextFile(WScript.ScriptFullName).ReadAll();

Это коллекция всех тегов <SCRIPT> со страницы браузера. Примерно то же самое что и document.getElementsByTagName('script').

И потом. Что значит следующая фраза?

Если кто-то изменит код текущего сценария это будет другой сценарий.

И на последок.

function alert(msg)
{
    WScript.Echo(msg);
};

alert(alert);