Классы в скрипте

отредактировано April 2011 Раздел: FastScript
Понадобилось использовать классы, которые объявляются в создаются в скрипте. Так как в стандартной версии такого нет, был реализован "на коленках" наследник TfsScript с нужным функционалом.

Имеет ли смысл развивать этот проект, или в будущем всё же появится реализация классов в скрипте ???
«1

Комментарии

  • отредактировано 04:20
    DimaBr написал: »
    Понадобилось использовать классы, которые объявляются в создаются в скрипте. Так как в стандартной версии такого нет, был реализован "на коленках" наследник TfsScript с нужным функционалом.

    Имеет ли смысл развивать этот проект, или в будущем всё же появится реализация классов в скрипте ???

    Вот пример:

    Я задавал этот вопрос разрабам, они сказали что очень заняты.
    Реализовать можно, но ничего общего с классами Delphi они иметь не будут и поэтому их можно будет использовать только в скрипте, в программе нельзя.
  • отредактировано November 2010
    Как можно использовать скриптовые классы в программе, если на момент компиляции о их существовании ничего не известно. Что-то вы путаете.
    Можно легко использовать записи (record), учитывая что запись-простейший класс, хотя можно подумать и о реализации самих записей.
  • отредактировано 04:20
    DimaBr написал: »
    Как можно использовать скриптовые классы в программе, если на момент компиляции о их существовании ничего не известно. Что-то вы путаете.
    Можно легко использовать записи (record), учитывая что запись-простейший класс, хотя можно подумать и о реализации самих записей.

    Я и говорю скриптовые классы в программе использовать нельзя, только в скрипте.
    Насчет записей попробуйте такой код, он не прокатывает:

    addClass(TPoint,'');
  • отредактировано 04:20
    Добавил реализацию записей в скрипте, пример обновлен.
  • отредактировано 04:20
    DimaBr написал: »
    Добавил реализацию записей в скрипте, пример обновлен.

    Архив повержден
  • отредактировано 04:20
    Пример обновлен.
  • отредактировано 04:20
    DimaBr написал: »
    Пример обновлен.

    Demo.rar - неожиданный конец архива
  • отредактировано December 2010
    Не знаю, прекрасно качается и открывается
    файлообенник
  • отредактировано 04:20
    Пример понятный, возможности замечательные.

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

    Реакция разработчиков непонятна.
  • отредактировано 04:20
    Спасибо огромное. Я уже думал что это вообще никому не нужно.
  • отредактировано 04:20
    Да, очень интересно было бы использовать такой функционал.
  • отредактировано 04:20
    DimaBr написал: »
    Спасибо огромное. Я уже думал что это вообще никому не нужно.

    Напиши здесь как можно использовать записи как классы, архив открыть не могу.
  • отредактировано 04:20
    Архив открывается. Вот пара скринов:
    23fb6f091bee.jpg
    23d560f64afe.jpg
  • отредактировано 04:20
    Архив не открывается :) . Прошу, выложите еще раз, возникла потребность в классах и типах внутри скриптов. Спасибо.
  • отредактировано April 2011
    Если вы думаете что в архиве есть исходники, то вы ошибаетесь. Был задан вопрос, на который никто так и не ответил.
  • отредактировано 04:20
    Скажите, а какое реальное использование у этих классов, кроме красивого обращения к полям ? :)

    Мы практически ничего не можем сделать с такими классами, не переопределить методы, а уж тем более наследоваться от абстрактных классов.
    Это фактически просто красивая обертка для объединения переменных.
    То же самое и структуры, обычно когда просят добавить структуры в скрипт, имеют введу не обертку для доступа к переменным того же скрипта, а обертку для реальных структур, чтобы можно было использовать функции со структурами в качестве параметров для внешних функций. Что сделать на автоматизме не возможно, структуры это область данных доступ к которой осуществляется по смещению, которое считает компилятор.

    А объявления в скрипте никакого функционала не добавляют, кроме "красивого" кода :)
  • отредактировано 04:20
    >Скажите, а какое реальное использование у этих классов, кроме красивого обращения к полям ?
    Реальное - например использование FastScript для выполнения программ написанных на Delphi, уменьшение повторяющегося кода.

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

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


    Не в упрёк будет сказано, но FastScript остановился в развитии. Я понимаю, что он написан для FastReport и выполняет практически все его потребности, но раз уж вы позиционируете его как отдельный продукт стоит ли останавливаться на достигнутом ? Мне кажется многие бы хотели иметь в приложении полноценный Delphi-Scripter. Сделал Script.LoadFromFile('MyForm.pas') и всё работает. К тому же скорость FastScript ну совсем уж не Fast :) (
  • отредактировано March 2011
    DimaBr написал: »
    Реальное - например использование FastScript для выполнения программ написанных на Delphi, уменьшение повторяющегося кода.
    Без виртуальных методов и без их переопределения, это не возможно.

    DimaBr написал: »
    Если вы смотрели демку, то в первом наследовании это реализовано
    Смотрел, я говорю не про доступ к полям предка, а про виртуальные функции и vmt.
    Т.е. чтобы работала такая конструкция(а так же возможность вызова inherited).
    type
    TTest = class
      private
        fAAA: string;
        procedure SetA(Value: string); virtual;
      published
        property AAA: string read fAAA write SetA;
    end;
    
    TTest2 = class(TTest)
      private
        fBBB: integer;
      published
        procedure SetA(Value: string); overload;
        property BBB: integer read fBBB write fBBB;
    end;
    
    { TTest }
    procedure TTest.SetA(Value: string);
    begin
      fAAA := Value;
    end;
    
    procedure TTest2.SetA(Value: string);
    begin
     // do something
    end;
    
    // --------------------------------------------
    var Test: TTest2;
    begin
      Test := TTest2.Create;
    //  Test.AAA := 'ГІГҐГЄГ±ГІ1';
    //  Test.fAAA := 'ГІГҐГЄГ±ГІ2';
      Test.SetA('ГІГҐГЄГ±ГІ3');
      Test.BBB := 12345;
      ShowMessage(Test.AAA+' - '+IntToStr(Test.BBB));
      Test.Free;
    end.
    

    Иначе все это сводится до красивой обертки данных, о чем я и говорил.

    DimaBr написал: »
    Запись - это тот же класс без свойств и методов. Реализовав классы - легко реализуются структуры
    В скрипте, да. А я говорю об обертке между кодом Delphi. Т.е. AddRecord(TRect) - невозможно, у TRect нет rtti.
    DimaBr написал: »
    Не в упрёк будет сказано, но FastScript остановился в развитии. Я понимаю, что он написан для FastReport и выполняет практически все его потребности, но раз уж вы позиционируете его как отдельный продукт стоит ли останавливаться на достигнутом ? Мне кажется многие бы хотели иметь в приложении полноценный Delphi-Scripter. Сделал Script.LoadFromFile('MyForm.pas') и всё работает. К тому же скорость FastScript ну совсем уж не Fast :) (
    Скрипт компилируется в промежуточный XML, следовательно , чем больше код скрипта, тем дольше время исполнения.
    К слову последние версии скрипта немного оптимизированы и исполняют большие скрипты быстрей чем предыдущие версии.
    Для FS на данный момент можно сделать многое, если его переключить на новый rtti D2009-XE, т.е. автоматическое добавление всех динамических методов, событий , без AddEvent итд. Вот только теряется поддержка младших версий Delphi у которых бедный rtti.
  • отредактировано 04:20
    DimaBr написал: »
    Не в упрёк будет сказано, но FastScript остановился в развитии. Я понимаю, что он написан для FastReport и выполняет практически все его потребности, но раз уж вы позиционируете его как отдельный продукт стоит ли останавливаться на достигнутом ? Мне кажется многие бы хотели иметь в приложении полноценный Delphi-Scripter. Сделал Script.LoadFromFile('MyForm.pas') и всё работает. К тому же скорость FastScript ну совсем уж не Fast :) (
    Не в упрёк будет сказано, это Вы остановились в развитии. При должном желании и усердии "Сделал Script.LoadFromFile('MyForm.pas') и всё работает" это уже давно работает, только немного головой надо подумать (читай покопать немного исходники FastScript).

    И это "К тому же скорость FastScript ну совсем уж не Fast" ложь. Всё работает как надо если запускать скомпилированный предварительно скрипт. FastScript делает компиляцию в xml и потом уже её выполняет. Так вот, компиляция действительно не быстрая, но там как-бы скорость и не нужна...
  • Stalker4Stalker4 123
    отредактировано 04:20
    tisker написал: »
    Всё работает как надо если запускать скомпилированный предварительно скрипт.
    Далеко не во всех случаях, можно скрипт предварительно откомпилировать.
  • отредактировано March 2011
    tisker написал: »
    "Сделал Script.LoadFromFile('MyForm.pas') и всё работает" это уже давно работает
    Вы хотите сказать, что FS может проглотить файл с классами, секцией interface, initialization, fnalization, с "человеческой" секцией uses, с рядом лежащим файлом DFM ?
    Тогда может я что-то пропустил ? Это всё уже реализовано ???
    tisker написал: »
    И это "К тому же скорость FastScript ну совсем уж не Fast" ложь.
    Простой тест доказывает обратное, у меня FS выполняет 30 секунд, а Delphi меньше 1
    var I: integer;
        X: extended;
    begin
      for i := 0 to 10000000 do
        X := Sqrt(I);
      ShowMessage('1');
    end.
    
  • отредактировано March 2011
    DimaBr написал: »
    Вы хотите сказать, что FS может проглотить файл с классами, секцией interface, initialization, fnalization, с "человеческой" секцией uses, с рядом лежащим файлом DFM ?
    Тогда может я что-то пропустил ? Это всё уже реализовано ???
    Простой тест доказывает обратное, у меня FS выполняет 30 секунд, а Delphi меньше 1
    var I: integer;
        X: extended;
    begin
      for i := 0 to 10000000 do
        X := Sqrt(I);
      ShowMessage('1');
    end.
    
    +1.

    Никто не задумывался над вариантом компилировать код обычным delphi-компилятором, который генерирует машинный код? Компилировать pas файлы в библиотеки (dll) или приложения (exe) и запускать их из памяти?

    В таком случае скорость работы будет идентична обычному приложению. (естесственно после компиляции, когда копия машинного кода уже в памяти)


    p.s. архив все равно битый. Может стоит заархивировать его zip?
    p.s.s. ответ на вопрос - да, конечно стоит.
  • отредактировано 04:20
    DeusEx написал: »
    Никто не задумывался над вариантом компилировать код обычным delphi-компилятором, который генерирует машинный код?
    Для этого нужно таскать компилятор с собой + все дополнительные библиотеки
  • отредактировано 04:20
    DimaBr написал: »
    Для этого нужно таскать компилятор с собой + все дополнительные библиотеки
    Скрипты обычно используются в достаточно крупных высоконагруженных системах, думаю проблема не в объеме компилятора и библиотек.
    Например, в моем случае - объем не имеет значения, важна только скорость работы откомпилированных скриптов. (сервер ММОРПГ игры обслуживающий миллионы пользователей)
  • отредактировано 04:20
    Это вы работаете в такой сфере, и других сфер не замечаете. Я, например уже сотне пользователей написал мини-скрипты в VBA, дабы сократить монотонную работу И думаю что таких как я - много, а программистов серверов ММОРПГ единицы.
  • отредактировано 04:20
    DeusEx написал: »
    +1.

    Никто не задумывался над вариантом компилировать код обычным delphi-компилятором, который генерирует машинный код? Компилировать pas файлы в библиотеки (dll) или приложения (exe) и запускать их из памяти?

    В таком случае скорость работы будет идентична обычному приложению. (естесственно после компиляции, когда копия машинного кода уже в памяти)
    А что мешает вам сделать это сейчас, непосредственно с использованием компилятора. Просто разнести логику скриптов на классы в разные DLL/BPL.
    Распространение компилятора со своим приложением - нарушение лицензии, т.е. пользоваться таким скриптом могут только те, кто купил Delphi.

    К слову для игр, компилятор Delphi далеко не самый лучший выбор. Текущие версии поддерживают простой набор команд x86, т.е. ни о какой оптимизации see или даже простого mmx и речи не идет. В вашем случае лучше использовать связку VC++ и Lua, и не ждать от интерпретатора, предназначенного в первую очередь для работы с отчетной системой компилируемого кода :)
  • отредактировано 04:20
    написал: »
    А что мешает вам сделать это сейчас, непосредственно с использованием компилятора. Просто разнести логику скриптов на классы в разные DLL/BPL.
    Распространение компилятора со своим приложением - нарушение лицензии, т.е. пользоваться таким скриптом могут только те, кто купил Delphi.

    К слову для игр, компилятор Delphi далеко не самый лучший выбор. Текущие версии поддерживают простой набор команд x86, т.е. ни о какой оптимизации see или даже простого mmx и речи не идет. В вашем случае лучше использовать связку VC++ и Lua, и не ждать от интерпретатора, предназначенного в первую очередь для работы с отчетной системой компилируемого кода :)

    Вот в том то и дело, что народ часто путает тёплое с мягким...
    Начинают тестировать производительность, смаковать синтаксис, цокать языком на отсутствие языковых конструкций, хотя на самом деле делают это по сути от безделья. Не замечая, что "тормоза" движка совсем не тормоза, если рассматривать картину по решаемым задачам в целом и сравнивая производительность других модулей, участвующих в решаемой технической задаче или их комплексе. Например нагруженная БД гораздо более существенный "тормоз"...
  • отредактировано April 2011
    написал: »
    А что мешает вам сделать это сейчас, непосредственно с использованием компилятора. Просто разнести логику скриптов на классы в разные DLL/BPL.
    Распространение компилятора со своим приложением - нарушение лицензии, т.е. пользоваться таким скриптом могут только те, кто купил Delphi.

    К слову для игр, компилятор Delphi далеко не самый лучший выбор. Текущие версии поддерживают простой набор команд x86, т.е. ни о какой оптимизации see или даже простого mmx и речи не идет. В вашем случае лучше использовать связку VC++ и Lua, и не ждать от интерпретатора, предназначенного в первую очередь для работы с отчетной системой компилируемого кода :)
    Сервер не распространяется, поэтому такой вариант возможен. Об этом сейчас и думаю.

    Что лучше для игр - личное мнение каждого (на мой взгляд: любой проект можно написать на любом языке, на том же уровне производительности, вопрос только в затраченном времени и усилии), у меня контролируется производительность каждой функции, каждого оператора, если появляется узкое место - всегда находится способ это исправить, в очень исключительных случаях приходится делать ассемблерные вставки.
    написал: »
    Вот в том то и дело, что народ часто путает тёплое с мягким...
    Начинают тестировать производительность, смаковать синтаксис, цокать языком на отсутствие языковых конструкций, хотя на самом деле делают это по сути от безделья. Не замечая, что "тормоза" движка совсем не тормоза, если рассматривать картину по решаемым задачам в целом и сравнивая производительность других модулей, участвующих в решаемой технической задаче или их комплексе. Например нагруженная БД гораздо более существенный "тормоз"...
    Да, народ может и путает, но в моем случае БД используется только для постепенной загрузки данных в кеш-сервер, и дальше работа с кеш-сервером (также периодический дамп данных в БД обратно). И узкими местами в данный момент являются - количество поддерживаемых соединений, более 33000 пока не удается и вся нагрузка идет на процессор, который обрабатывает tcp-ip соединения. А если часто используемые скрипты тоже будут кушать процессор, то количество соединений еще больше упадет. Да, 33000 очень высокая цифра, но на нее никто и не ориентируется, в нашем случае достаточно будет 5000 игроков на 1 сервер, но тем не менее важно определить на сколько сильно влияет на производительность в целом каждый элемент системы.

    Скрипты очень хорошо подходят для "квестов" (заданий). Но слабо подходят для реализаций интеллекта NPC, которых одновременно на сервере может находится более 10.000. Хотя мне был бы интересен вариант вынести логику NPC в скрипты и дать возможность сторонним разработчикам пробовать выстраивать свою логику, к тому же это полезно будет, если движок будет переносится для другой игры и логику придется менять.

    Еще скрипты полезны тем, что многие обновления можно реализовать без перезагрузки сервера, это очень удобно :)

    Ладно, не буду навязывать свои проблемы :) Кто ищет работу - есть вакансии (Киев) :)
  • отредактировано April 2011
    написал: »
    Без виртуальных методов и без их переопределения, это не возможно.
    Т.е. чтобы работала такая конструкция(а так же возможность вызова inherited).
    Специально для вас "взял новый напильник".
    9b0405264b42.jpg
  • отредактировано 04:20
    DeusEx написал: »
    Что лучше для игр - личное мнение каждого (на мой взгляд: любой проект можно написать на любом языке, на том же уровне производительности, вопрос только в затраченном времени и усилии), у меня контролируется производительность каждой функции, каждого оператора, если появляется узкое место - всегда находится способ это исправить, в очень исключительных случаях приходится делать ассемблерные вставки.
    Конечно, каждому свое :)
    Просто если приложение оперирует большим потоком данных такими, как вектора и координаты, то лучше выбирать компилятор поддерживающий хотя бы mmx. Естественно все выбирается под конкретную задачу.
    Насчет ассемблерных вставок, разве делфийский asm может обрабатывать команды mmx/sse (movups/movq/CVTPD2PS/CVTPD2DQ) ?
    У меня он бывало и более простые инструкции x86 не принимал.

    DeusEx написал: »
    Скрипты очень хорошо подходят для "квестов" (заданий). Но слабо подходят для реализаций интеллекта NPC, которых одновременно на сервере может находится более 10.000. Хотя мне был бы интересен вариант вынести логику NPC в скрипты и дать возможность сторонним разработчикам пробовать выстраивать свою логику, к тому же это полезно будет, если движок будет переносится для другой игры и логику придется менять.

    Еще скрипты полезны тем, что многие обновления можно реализовать без перезагрузки сервера, это очень удобно :)
    Так же возможно облегчить работу скрипта, к примеру перенести честь нагрузки на функции/классы приложения и использовать их в скрипте.
    Но это уже часть реализации.


    DimaBr
    Методы теперь вызываются, но вот полиморфизма нет.
    Т.е. у вас жестко привязывается к типу объявленной переменной, а не созданного класса.
    Достаточно поменять объявление Test2: TTest2 на Test2: TTest :
    var Test: TTest;
        Test2: TTest;
    begin
      Test := TTest.Create;
      Test2 := TTest2.Create;
      ShowMessage(Test.AAA+' - '+ Test2.AAA);
      Test.Free;
      Test2.Free;
    end.
    

    и функции у вас почему-то не работают:
    type
    TTest = class
      public
        function GetA: string; virtual;
    end;
    
    TTest2 = class(TTest)
      public
        function GetA: string; override;
    end;
    
    { TTest }
    function TTest.GetA: string;
    begin
      Result := 'TTest';
    end;
    
    { TTest2 }
    function TTest2.GetA: string;
    begin
      Result := 'TTest2/' + inherited GetA;
    end;
    
    // --------------------------------------------
    var Test: TTest;
        Test2: TTest;
    begin
      Test := TTest.Create;
      Test2 := TTest2.Create;
      ShowMessage(Test.GetA+' - '+ Test2.GetA);
      Test.Free;
      Test2.Free;
    end.
    

Оставить комментарий

Многофункциональный текстовый редактор. Чтобы отредактировать стиль параграфа, нажмите TAB, чтобы перейти к меню абзаца. Там вы можете выбрать стиль. По умолчанию не выбран ни один стиль. Когда вы выберете текст, появится встроенное меню форматирования. Нажмите TAB, чтобы войти в него. Некоторые элементы, такие как многофункциональные вставки ссылок, картинок, индикаторов загрузки и сообщений об ошибок могут быть вставлены в редактор. Вы можете перемещаться по ним, используя стрелки внутри редактора и удалять с помощью клавиш delete или backspace.