-
Notifications
You must be signed in to change notification settings - Fork 133
[jnigen] Make Visitor constructable inline #3521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
8f64d10
739af13
76baded
b3f2d76
95bec8c
7f22761
ce206be
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -15,6 +15,15 @@ abstract class _Element { | |
| /// Users can extend this class to create custom visitors that modify the AST | ||
| /// before code generation. | ||
| abstract class Visitor { | ||
| const Visitor(); | ||
|
|
||
| factory Visitor.callback({ | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's unfortunate this has to be called Does it work to just call it How about Or we should consider making the default constructor not the default name. E.g. that makes the inline visitors more pretty and the custom subclasses slightly less pretty. class MyVisitor extends Visitor
MyVisitor(...):super.base();Side note. I feel we should make a decision whether we want users to subclass or implement visitor. It should either be a base class (non-implementable) or interface class (non-extendible). If it's only implementable and not extendible, then we don't need a default constructor for sub classes.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The downside of making it only implementable is that users have to override every method. That's not a big deal for JNIgen's visitors, but FFIgen will have heaps of visit methods. I've gone with the |
||
| void Function(ClassDecl node)? visitClass, | ||
| void Function(Method node)? visitMethod, | ||
| void Function(Field node)? visitField, | ||
| void Function(Param node)? visitParam, | ||
| }) = _VisitorImpl; | ||
|
|
||
| /// Visits a class declaration. | ||
| void visitClass(ClassDecl c) {} | ||
|
|
||
|
|
@@ -28,6 +37,43 @@ abstract class Visitor { | |
| void visitParam(Param parameter) {} | ||
| } | ||
|
|
||
| class _VisitorImpl extends Visitor { | ||
| const _VisitorImpl({ | ||
| void Function(ClassDecl node)? visitClass, | ||
| void Function(Method node)? visitMethod, | ||
| void Function(Field node)? visitField, | ||
| void Function(Param node)? visitParam, | ||
| }) : _visitClass = visitClass, | ||
| _visitMethod = visitMethod, | ||
| _visitField = visitField, | ||
| _visitParam = visitParam; | ||
|
|
||
| final void Function(ClassDecl node)? _visitClass; | ||
| final void Function(Method node)? _visitMethod; | ||
| final void Function(Field node)? _visitField; | ||
| final void Function(Param node)? _visitParam; | ||
|
|
||
| @override | ||
| void visitClass(ClassDecl c) { | ||
| _visitClass?.call(c); | ||
| } | ||
|
|
||
| @override | ||
| void visitMethod(Method method) { | ||
| _visitMethod?.call(method); | ||
| } | ||
|
|
||
| @override | ||
| void visitField(Field field) { | ||
| _visitField?.call(field); | ||
| } | ||
|
|
||
| @override | ||
| void visitParam(Param parameter) { | ||
| _visitParam?.call(parameter); | ||
| } | ||
| } | ||
|
|
||
| /// A collection of class declarations. | ||
| class Classes implements _Element { | ||
| Classes(this._classes); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
abstract base class