Как представлять классы в интерпретаторе на основе абстрактного синтаксического дерева
Я прочитал соответствующие вопросы, но ни один из них, похоже, не затрагивает этот вопрос напрямую. Я работаю над написанием интерпретатора PHP-скриптов. У меня есть AST, генерирующий правильные узлы для всего, кроме классов. Классы обработки немного отличаются от функций обработки, поэтому я ищу, как обрабатывать классы, которые являются автономными и расширяют другие классы.
Я посмотрел на ANTLR, но я не могу позволить себе накладные расходы, так как это для встроенной платформы. что я я ищу теорию, концептуально лежащую в основе классов в AST, чтобы они могли выполняться частью исполнителя интерпретатора. Хорошие ссылки с конкретными ответами на этот вопрос определенно приветствуются.
5 answers
ANTLR более или менее не имеет отношения к вашей проблеме.
Класс в PHP - это, по сути, отображение строк в атрибуты. Каждый атрибут может быть общедоступным, частным, защищенным. Каждый атрибут также содержит значение, которое может быть статической переменной или методом. Методы - это функции, которые (в PHP) принимают неявный параметр $this. Таким образом, вы можете думать о классе как в основном о причудливом объекте массива в PHP.
Когда вы создаете объект, вы даете ему указатель на объект вашего класса PHP. Когда вы вызываете метод для этого объекта, вы просматриваете метод через объект класса, который вы получаете через этот указатель.
Я надеюсь, что это поможет.
Возможно, вам нужны некоторые структуры для интерпретации, которые немного более удалены от исходной грамматики? Я не очень много знаю о PHP, но, похоже, вы действительно спрашиваете, как структурировать модель программы таким образом, чтобы это было удобно для интерпретации. Я бы расценил AST, созданный с помощью ANTLR, как слишком близкий к источнику для того, что вы хотите.
Я обнаружил, что лучший метод в компиляторе сверху вниз, лучший метод состоит в том, чтобы рассматривать классы в целом так же, как функции, в том смысле, что они являются просто узлами без необходимости оценивать аргументы перед спуском в дерево.
Различия заключаются в исполнителе, который должен создать область выполнения, в которой будут инкапсулированы методы и переменные, составляющие узел класса.
Я бы предложил использовать JavaCC (или бесплатную вилку) для анализа и создания вашего AST. JavaCC генерирует синтаксический анализатор, который не имеет зависимостей во время выполнения. Трудно написать меньший/более быстрый синтаксический анализатор, чем код, который генерирует JavaCC.
Взгляните на абстрактную грамматику phc, она делает именно это. (Кстати, похоже, что использование интерфейса phc может быть лучше, чем изобретение колеса).
Class_def ::= Class_mod CLASS_NAME extends:CLASS_NAME? implements:INTERFACE_NAME* Member* ;
Class_mod ::= "abstract"? "final"? ;
Interface_def ::= INTERFACE_NAME extends:INTERFACE_NAME* Member* ;
Member ::= Method | Attribute ;
Method ::= Signature Statement*? ;
Signature ::= Method_mod is_ref:"&"? METHOD_NAME Formal_parameter* ;
Method_mod ::= "public"? "protected"? "private"? "static"? "abstract"? "final"? ;
Formal_parameter ::= Type is_ref:"&"? var:Name_with_default ;
Formal_parameter ::= Type is_ref:"&"? var:Name_with_default ;
Type ::= CLASS_NAME? ;
Name_with_default ::= VARIABLE_NAME Expr? ;
Attribute ::= Attr_mod vars:Name_with_default* ;
Attr_mod ::= "public"? "protected"? "private"? "static"? "const"? ;