Реализовать существующий язык сценариев для динамической ОО-программы - PullRequest
1 голос
/ 22 июня 2010

Я работаю над программой, которая обрабатывает много объектов и данных.Как я мог бы вводить манипуляции, имея своего рода «API» для моего приложения.Поскольку само приложение выполняет управление объектами и тому подобное, мне интересно, как это можно реализовать.Например, движки Unity3D и Panda3D позволяют использовать различные языки, такие как ECMA или Python для сценариев.Я не ищу «скриптовый» игровой язык для вставки, а указывает на то, как поддерживать различные скриптовые языки.

Ради аргумента предположим, что в моей программе есть объекты класса Cube.У куба есть методы класса, такие как вращение, перемещение, преобразование и такие свойства, как цвет, центр, размер.Теперь я хотел бы дать своему пользователю возможность использовать, например, JavaScript для управления объектом.Однако моя «базовая» программа написана на Ruby.

  1. Нужно ли мне писать целый пакет, который будет оценивать код пользователя и его синтаксис (как реализацию собственной версии JavaScript) с нуля?Или существуют существующие пакеты, скелеты, каркасы, гемы и т. Д.?
  2. Как мне реализовать безопасность, чтобы язык сценариев предоставлялся только классам, которым разрешено манипулировать (например, атрибут, который отмечаеткласс «манипулируемый»).

Мне всегда было интересно, как корпоративные приложения справились с этой задачей (и игровые движки тоже ...), поэтому спасибо за помощь и обратную связь.

Ответы [ 2 ]

3 голосов
/ 22 июня 2010

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

Должен ли я написать целый пакет, который будет оценивать пользовательский код и его синтаксис (как реализовать собственную версию JavaScript) с нуля?

Нет. Существует множество пакетов, которые вы можете включить в свою программу. Если бы ваша программа была написана на C, или даже если она предоставляла интерфейс C, ваше решение было бы простым: язык программирования Lua предназначен для встраивания в программы на C без особых усилий. Я делал это по крайней мере пару десятков раз.

Как мне реализовать безопасность, чтобы дать язык сценариев только тем классам, которым разрешено манипулировать (например, атрибуту, который помечает класс как «управляемый»)?

Вы делаете это, настраивая коллекцию имен, видимую для сценариев - как парень, владеющий языком программирования, я бы сказал, что вы контролируете среду (технический термин для обозначения доступа к именам) , Например, в случае с Lua вы должны передать сценарию каждого пользователя среду, которая позволяет пользователю точно назвать функциональность, которую вы хотите, чтобы пользователь имел, и не более. Если скрипт не может назвать его, он не может быть использован. Эта работа обычно называется песочница . (Например, «поместите пользователя в песочницу и не выпускайте его».) Песочница через управление пространством имен обычна для других языков, кроме Lua.

Мне всегда было интересно, как корпоративные приложения сделали этот трюк (и игровые движки тоже ...)

Я не знаю, как кратко суммировать этот трюк для SO-ответа. Но общая идея такова:

  • Язык сценариев имеет интерпретатор байт-кода

  • Существует тщательно разработанный протокол для вызова между скриптами и C

Для более глубокого обзора прочитайте книгу Роберто Программирование на Lua ; раннее издание бесплатно онлайн.

1 голос
/ 22 июня 2010

Я не уверен, что полностью следую вашим требованиям, но подойдет ли вам что-то вроде RESTful ? REST обычно рассматривается в терминах клиент / сервер, но я думаю, что некоторые идеи могут быть применимы и здесь.

Основная концепция может заключаться в том, что вы представляете представления объектов (вероятно, в JSON или XML) через ваш API. Клиенты будут извлекать эти представления, вносить любые изменения, которые они захотят, а затем отправлять измененные версии обратно в вашу программу. Ваша программа будет проверять изменения и (при условии, что они были законными) применять их.

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

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

...