JScript: Фреймворк

Методы ECMA262-5 - удобно для тех, кто в курсе, но можно и без них.
Остальное - по-моему у каждого разработчика есть свои наработки - библиотеки подобных функций.
Никакого скепсиса - так вижу.
Идея понравилась. Если "правильно" подойти к реализации + карта ляжет может что-нибудь доброе получится.
Я бы создал репозиторий на каком-нибудь GitHub или Google Code для совместной разработки и общения.
Создание сообщества единомышленников в случае развития идеи очень важно.
По коду - я бы... как это правильно... закрыл scope... ну как-то так в общем:

(function() {
// здесь код библиотеки
})();

Пример использования первой функции (toArray) +  map:

new Enumerator(new ActiveXObject("Scripting.FileSystemObject").Drives).toArray().map(function(drive) {
  WScript.Echo(drive.DriveLetter);
});

Т.е. из коллекции получаем массив, после чего к примеру мапим его как нам надо.

upd: не совсем удачный пример - лучше forEach:

new Enumerator(new ActiveXObject("Scripting.FileSystemObject").Drives).toArray().forEach(function(drive) {
  WScript.Echo(drive.DriveLetter);
});

Функция map() вернет нам массив, состоящий из определенных свойств объектов.

Здесь с Вашей стороны есть доля лукавства: фреймворки и библиотеки главным образом пишутся для вэба, а узконаправленных, скажем, для административных задач - водятся ли они вообще в дикой природе?

Запихать все в ананимную функцию, как это делает большинство разрабов различных библиотек, можно, но стоит ли? Кидать все в одну кучу, делая тем самым API библиотеки или фреймворка труднодокументируемым, а главное сложным в использовании (и отладке), многих и побуждает к написанию того, что народ любит называть "плагинами", а на деле лишь является оберткой над API. На мой субъективный взгляд логичней бить логику библиотеки на классы, связывая после их в единое целое. Например, функции для работы с массивами помещаем в класс arr:

var arr = arr || {
//методы класса
};

И так далее. Это в значительной мере упрощает документирование, разработку и эксплуатацию. По крайней мере scope.js (библиотека, написанная для одного проекта) такой подход оправдала.

А Вы уверены, что абсолютно все разработчики данный документ не читают? Идею же с репозиториями...

...также поддерживаю.

Рад, что откликнулись. Думаю, не стоит опасаться захламления глобального пространства имен, потому что никто не запрещает использовать такую классную штуку как http://code.google.com/intl/ru/closure/ … rview.html. При большом желании можно код обернуть в анонимную функцию. Но это мелочи в реализации.

Код уже залит на GitHub. Я бы хотел рассказать о моем видении на реализацию этого проекта.

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

Какой алгоритм работы? Да все просто, я буду брать справочник AutoIt|VBScript и переписывать функции в JS.

Что касается модулей, то можно их сделать в отдельном файле, никаких проблем нет. Но я не сторонник классической идеи о модульности типа NewMath = {Method1: ...}. Может быть не прав. Сборку рабочего кода вполне можно сделать отдельной утилитой с применением удаления мусорного кода.

Мне вполне нравится Ваша идея с Enumerator.prototype.forItems и я использовал свой аналог функции, правда назвал как forEach. Реализовано как-то так.

Enumerator.prototype.forEach = function (action, that /*opt*/)
{
    this.toArray().forEach(action, that);
}

В текущий момент функции пишутся и названы в соответствии с документацией AutoIt. Что касается стиля расширения прототипов, то я использую, как Вы сказали, «словоСлово». Но если Вы любите программировать, например, на PHP, и Вам очень нравится определенная функция, которая могла бы упростить жизнь в разработке, то без проблем можете ее реализовать так, как она описана и именована в документации к PHP. Вот к примеру, мне очень нравится использование переменных в строках, например

echo "$a - a value"

И в скором времени это будет внесено в функционал.
Конечно, можно спорить на эту тему, но я вижу фреймворк как платформу, которая  позволяет довольно быстро переносить код из одного языка в другой, в том числе для ускорения разработки.

Думаю, что полностью код фреймворка подключать нецелесообразно. В настоящий момент я себе поставил задачу напихать как можно больше функционала, который мне обычно нужен в работе. При этом при завершении написания кода, использующего фреймворк, я его прогоняю через Google Closure, который удаляет неиспользуемые функции. В принципе у меня нет огромных проектов на WSH, где я бы беспокоился о захламлении глобального пространства имен.
Что касается вопроса о вводе модулей, то мне сейчас немного сложно на него ответить. Я стараюсь сделать код максимально понятным и локаничным, а фреймворк плоским. Подумаю над этим. Вот что приходит в голову: сделать как можно гибче и демократичней, например как в Дельфи. Там можно подключать модули, при этом разработчик может писать как <название модуля> точка <функция> либо просто <функция>. То есть использование "префиксов" функций в коде можно оставить на выбор разработчику.

Работа интересная. Я помню. Взял на заметку. К ней вернусь чуток позже.

Serge Yolkin, синтаксис как был JS, так и останется. Писать с большой буквы или маленькой - это вообще не является проблемой. Весь код исправляется одним регулярным выражением. Дублирования кода не стоит бояться, потому что весь мусор (неиспользуемый) на этапе преобработки будет выпилен либо Google Closure, либо аналогом, которым я также занимаюсь. Вопрос о паковке функций в массивы/объекты/файлы/модули также легко решаем преобработкой. Например, засунем функции работы с файловой системой в отдельный файл FS.js. Никаких препятствий не вижу использовать эти функции либо через объект FS.<method> либо <method>. Все это решается предварительной обработкой кода. Сейчас же мне интересна реализация тех функций, которые я назвал на "To Do". А все остальное - вторично и решаемо.

В JScript нет команды include
Фреймворк придется подгружать динамически.
Предлагаю рабочий пример  eval работает как в WSH, так и NET (exe файл)

P.S про условную компиляцию до конца месяца напишу отдельно

примечание:файл с форума выгружается коряво но 7zip его читает

1) потому и предложил разделить модули - скелет отдельно, трансляторы - отдельно, и никаких перекрёстных ссылок, только из транслятора в базу (скелет)
2) при наличии желания/времени на изучение справки по AutoIt, возможно, и писать будет проще на AutoIt...

Rumata, согласен. Удалил. Что касается функций StringXXX, то предлагаю их оставить, так как они довольно часто используются.

+, например вот так решает Крокфорд

Наверное подразумевали Number.prototype.

Подразумевалось то, что подразумевалось. Диапазон знакового целочисленного типа, насколько помню, лежит в пределах от -2147483648 до 2147483647, и если попытаться определить тип этих значений с помощью оператора typeof, получим Number. Следовательно, определить самостоятельно целочисленный тип в JavaScript более, чем возможно, правда есть несколько нюансов, например, как идентифицировать Integer без приведения к таковому с помощью parseInt? Можно, в принципе, ориентироваться на наличие точки, намекающей на тип Float, или, учитывая, что в JavaScript имеется возможность представлять числа в виде строк (и наоборот), то можно вполне предопределить тип, а точнее его диапазон с помощью регулярных выражений, но насколько все это эффективно и нужно ли вводить понятия int, uint и иже с ними, судить не берусь. Могу лишь напомнить про следующие числовые константы:

WScript.echo(NaN); //1,#QNAN
WScript.echo(Number.NaN); //-1,#IND
WScript.echo(Infinity); //1,#INF
WScript.echo(Number.NEGATIVE_INFINITY); //-1,#INF
WScript.echo(Number.POSITIVE_INFINITY); //1,#INF
WScript.echo(Number.MAX_VALUE); //1,79769313486232E+308
WScript.echo(Number.MIN_VALUE); //4,94065645841247E-324

Если быть объективным, этих констант достаточно, чтобы проводить довольно сложные вычисления, не заморачиваясь с вводом новых типов данных.

Позвольте заметить, что конечное слово все же за разработчиком. Единственное, на что действительно стоит обратить внимание в данном случае - доступность документации.

Можно и вовсе сократить до each, как в Ruby.

Это все равно что венгерская нотация в C\C++.  Наиболее верным является не то, насколько жестко разработчик придерживается стилистических рекомендаций, а простота восприятия кода. Например, кому-то покажется функция вида:

function getStringLength() {...}

куда более осмысленной, чем просто:

function stringLength() {...}

Навязывание норм развитого социализма только тормозит развитие науки и прогресса вцелом.

Serge Yolkin, да Вы поймите меня правильно. Я абсолютно "за" в отношении ввода пространства имен/модулей/файлов/библиотек и т.п. Только вот Вы мне подскажите: что есть "базовый" js-фреймворк?:) Это сборище функций, которое я сам придумаю? - Да, и, кстати, это абсолютно верно, но вот скажите зачем нам создавать велосипед заново, придумывая спецификации, апи? Лучше же от чего-то отталкиваться. Если опыт чей-то имеется в смежной области, так почему бы не воспользоваться им?
Или Вы думаете базовый функционал - это просто расширение прототипов в соответствии со стандартами ECMA либо традициями других фреймворков под веб? - Тогда возникает вопрос: "А в чем собственно фишка и в чем удобство?".
Попробуйте ответить на вопросы: Какова точка отсчета для фреймворка? И как ее задать?
Понимаете, я должен исходить из того, что я должен сделать такой базовый функционал, который в первую очередь будет заточен под решение административных/управленческих задач. Говорить сообществу разработчиков о том, что "Ребята, выучите сначала мой базовый функционал, который я родил вот только что, а только потом берите сливки с других языков и реализуйте их модулями причем на базе моего базового фреймворка" несколько неправильно. Я должен что-то взять за основу, что простое, плоское, локаничное, интуитивно понятное, а также популярное хотя бы среди какой-то части скриптописателей. Разумеется, надо использовать готовые спецификации. Просто в качестве дефолтного я выбрал AutoIt. Поэтому базовым фреймворком будет AutoIt. Но я напоминаю о том, что это не означает, что разработчик будет таскать за собой огромную библу с мусорным кодом. То, что разработчик будет использовать в рабочем коде, то и останется после обработки. Ничего лишнего.
Если мы упремся в конфликт имен функций из разных языков программирования, то и в этом ничего страшного нет, потому что никто не мешает задать приоритет модулей из отдельных файлов. Сейчас вопрос только в реализации функционала. Причем все очень демократично. Публикуйте — разберемся.

Serge Yolkin, Вы не занудствуете. Вы задаете абсолютно правильные и логичные вопросы. Когда есть скептики, значит есть над чем думать. И это очень хорошо.

Точно. Это у меня опечатка.

В этом плане (если действительно есть такая необходимость - определение целочисленности) есть интересный ход, хак, но изящный

var x = Math.PI;
alert(x >>> 0);
alert(x >> 0);
alert(x << 0);
alert(x ^ 0);
alert(x | 0);

Вcе они а) отбрасывают дробную часть числа, б) обнуляют результат, если число по модулю превышает 0xFFFFFFFF (2^32-1), Но здесь есть одна тонкость: числа больше 0x7FFFFFFF можно рассматривать как отрицательные так и положительные. Например, 0x80000001:

0x80000001 >>  0 == -2147483647
0x80000001 >>> 0 == 2147483649

Справедливо и обратное:

-1 >>  0 == -1
-1 >>> 0 == 4294967295

Иногда может потребоваться одно, иногда - другое.

Согласен с Вами. Но ограниченный набор отдельных файлов, каждый из которых содержит определенный, ограниченный функционал, лучше, чем один сплошной файл. Если есть зависимости (фнукционал файла А зависит от некотрых функций файла Б)  - задокументировать в шапке файла.

Так любой сможет с легкостью использовать часть функционала не вытягивая всю библиотеку (например, если кому-то захочется использовать "массивные" функции forEach, map и прочие в реализации JSMan, то он, кто-то легко разберется, что искомое находится в файле Array.js).

Для меня здесь ключевая фраза - "не загоняясь по синтаксису других языков". Думаю, что не стоит приближать один язык к другому. JS от этого лучше не станет, если он будет похожим на AutoIt. Если кто-то желает програмировать на JS, похожем на AutoIt, может быть он выбрал не тот язык для программирования? В частности, для меня Ruby далек, так же как Cobol, поэтому первые ассоциации при виде each связаны с jQuery, в котором он реализован через абы как - передача параметров прямо противоположна стандартному forEach. Вот пример (об чем думал Джон?):

var x = [1, 2, 3];
$.each(x, function(index, value) { alert(value); });

x.forEach(function(value, index) { alert(value); });

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

greg zakharov

Я то лично противник этого. Но речь шла именно о

Поэтому я и привел то решение. Кому надо - тот воспользуется и напишет свою реализацию определения целого числа.

Ни в коей мере не отвергаю мнение ни автора (JSMan в данном случае), ни чье-либо другое (Ваше). Речь только о разделении единого файла на этапе разработки на неколько отдельных файлов. Которые проще сопровождать и проще использовать отдельно.

Так ли необходимо реализовывать функционал одного языка в другом с точностью до API? Не лучше ли использовать другой язык? Например, в своей работе я использую очень часть Perl и JScript. Будучи на win-машине, использую js, если мне достаточно его средств, либо перехожу на Perl, если решение на нем быстрее проще в реализации и сопровождении. Тем более если это сиюминутная задача, то я возьму Perl (иногда JS, потому что мне не нравится работа с временем в Perl). Но я не создаю фреймфорк perl2js.
Но это только мое мнение. Каждый язык имеет свои средства работы с существующими объектами. дублирование классного средства одного языка в другом должно быть органично в рамках данного языка. Например, есть несколько реализаций C-подобной функции sprintf в js. Можно использовать существующее готовое, можно переписать с нуля. Задача стоит в API - как использовать функцию: sprintf("форматирующая строка", аргументы) или "форматирующая строка".sprintf(аргументы). В данном случае оба варианта хороши, но второй - более js-подобный.
Автор же волен решать свои задачи, если они ему необходимы. Тем более если в массах они найдут отклик.

Как эта ф-я работает/должна работать?

// Add ECMA262-5 Array methods if not supported natively
//
if (!('indexOf' in Array.prototype)) {
    Array.prototype.indexOf= function(find, i /*opt*/) {
        if (i===undefined) i= 0;
        if (i<0) i+= this.length;
        if (i<0) i= 0;
        for (var n= this.length; i<n; i++)
            if (i in this && this[i]===find)
                return i;
        return -1;
    };
}

даже, если заменить знак "<" на ">" в последнем if , то она всегда будет возвращать индекс элемента массива
начиная с 0. Зачем тогда параметр i?

var myArr = ["aaa", "bbb", "ccc"];
myArr.indexOf('ccc', 0);             // вернёт 2
myArr.indexOf('ccc', 1);             // вернёт также 2...

Дык не работает же... о том и пишу....

Обновил первый пост. Не смотря на большую занятость, разработка мелкими шажками продолжается. Код на HTA полностью функционирует.

Первый этап скоро добью. Осталось порядка 50-60 функций, но это пустяки. Затем, покажу реализацию отброса неиспользуемых функций, чтобы результирующий код был как можно компактнее и проще.

dab00, в точку :-). Это и есть третий этап.

Функция подключения модулей.

Этот вариант функции пока подключает файл скрипта, можно указать каталог, тогда буду подключены все файлы в каталоге.

Немного предисловия. Ядро фреймворка состоит из нескольких файлов, функции которых будут лежать в глобальном пространстве. Большая часть функций ядра перечислена в посте № 1.

Далее, я сделал возможность не только расширения глобального объекта, но и возможность замкнуть это на свой объект.

var GlobalObject = this;

// Include.Libs - словарь модулей
// Include.DefaultNameSpace - область видимости по умолчанию
function Include(JsPath, NameSpace)
{
    var method, module, lib, code, stream;
    var FSO = new ActiveXObject("Scripting.FileSystemObject");
    var WshShell = new ActiveXObject("WScript.Shell");
    
    JsPath = WshShell.ExpandEnvironmentStrings(JsPath);
    // если файла нет, то оканчиваем работу
    
    if (FSO.FolderExists(JsPath)) 
    {
        var files = new Enumerator(FSO.GetFolder(JsPath).Files);
        var scripts = [];
        for (; !files.atEnd(); files.moveNext())
        {
            if (/\.js$/i.test(files.item())) scripts.push(files.item());
        }
       
        for (var i=0; i<scripts.length; i++) Include(scripts[i], NameSpace);
        return true;
    }
    
    if (!FSO.FileExists(JsPath)) return false;
    // избавляемся от относительных путей, формируем полный путь. 
    JsPath = FSO.GetFile(JsPath).Path;
    // устанавливаем пространство имен, на которое будет распространяться импортируемый модуль.
    // если оно не задано в функции, то испортируемые функции подключаются к глобальному объекту (точнее к указателю this).
    if (!arguments.callee.DefaultNameSpace)arguments.callee.DefaultNameSpace = GlobalObject;
    if (!NameSpace) NameSpace = arguments.callee.DefaultNameSpace;
    if (!arguments.callee.Libs) arguments.callee.Libs = {};
    lib = arguments.callee.Libs[JsPath];
    // если модуль ранее подгружался
    if (lib) 
    {
        // то импортируем уже загруженные указатели функций модуля в объект, который кеширует перечень функций
        // нужна оптимизация, которая предотвратит повторное присвоение функций в namespace
        for (method in lib)
        {
            NameSpace[method]=lib[method];
        }
        return true;
    }
    else 
    {
        lib = arguments.callee.Libs[JsPath] = {};
        // если библиотека не подгружалась ранее, то осуществляется ее чтение и интерпретация
        if (FSO.GetFile(JsPath).Size==0) return "";
        stream = FSO.OpenTextFile(JsPath, 1, 0, -2),
        code = stream.ReadAll();
        stream.Close();
        module = eval("("+code+")");
        // далее, данные помещаются и в кеш, и в namespace
        for (method in module)
        {
            lib[method]=module[method];
            NameSpace[method]=module[method];
        }
    }
    return true;
}

   
Include("test3.js");
A();

var s = {};
Include("test3.js", s);
s.A();

Include.DefaultNameSpace = GlobalObject;     
(function(){
    Include("test3.js");
    A();
}
)();

Модуль выглядит примерно так:

(
(function (){
    MsgBox("Hello from module")
}
)(),

{
A : function () {
    MsgBox("123");
},

B : function () {
}

}
)

Как мы видим есть функция инициализации, которая будет вызвана только один раз, в какой бы неймспейс модуль не подключался бы. Экземпляры функций при разных неймспейсах не создаются дополнительно. Все кешируется. Объектам раздаются указатели на функции. Принципиально отказался от приватных переменных.

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

Есть проблема отладки, так как используется eval.
Также будет добавлена проверка конфликта имен функций модуля.