[
https://issues.apache.org/jira/browse/THRIFT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638032#action_12638032
]
Mark Slee commented on THRIFT-163:
----------------------------------
I think this is an excellent idea, and its one that we had discussed doing
internally even before open sourcing Thrift. Theoretically, all of the language
generators could just use this plugin architecture. There will be a bit of
heavy lifting in setting up the dynamic loading, but I'm sure there's someone
on the project who's already roughly familiar enough with that to start
thinking about tackling it.
But overall, this would be great to have. I think it'll promote greater sharing
of extended functionality that doesn't belong in the core compiler.
> Create an Plugin Framework so Developers can plug-in arbitrary
> code-generation features
> ---------------------------------------------------------------------------------------
>
> Key: THRIFT-163
> URL: https://issues.apache.org/jira/browse/THRIFT-163
> Project: Thrift
> Issue Type: New Feature
> Reporter: Nathan Marz
>
> It would be really nice to be able to plug in arbitrary code-generation
> extensions to the Thrift compiler. There are a lot of application-specific
> problems that can be elegantly solved by augmenting the Thrift compiler. For
> example, in my application, I need to be able to find all instances of an
> object of a certain type reachable from a Thrift object. (Java reflection is
> too expensive). I doubt that the community would accept this is a feature
> within the core compiler, but if I could do it via my own extension that
> would be ideal.
> There are a number of steps that need to happen to make this work:
> 1. Create an interface that extensions implement - this could be as simple as
> one method called "generate_body" which is called within the class
> definition. This allows extensions to create field declarations and new
> methods. Possibly we might need a "generate_constructor" if the extension
> needs to do anything in the object's constructor.
> 2. Create a way for the compiler to dynamically load extension modules - I'm
> not that familiar with how to do this in C++. We might need a configuration
> file for each module which specifies what language it generates for.
> I think one of the main objections to this will be robustness - how do we
> ensure that extensions don't conflict with one another or with the Thrift
> compiler itself? I would propose that we take the Firefox route to addressing
> this and don't worry about it. It should be up to the extensions designed to
> choose sufficiently good method and field names to prevent conflicts.
> Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
