[
https://issues.apache.org/jira/browse/THRIFT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Reiss updated THRIFT-163:
-------------------------------
Attachment: 0001-shared-generators-take-1.patch
This is actually way more primitive than I remembered. If I recall properly,
it successfully builds the generators as shared objects. Since this was
written, we've modified most of the generators to use a dynamic registry, which
was one of the big hurdles to getting this to work. I think the big chunks
that remain to be done are first modifying the compiler to load the appropriate
shared objects with libltdl and investigating whether it is possible to compile
some of the objects directly into the compiler so that we don't have to worry
about library search paths.
> 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
> Attachments: 0001-shared-generators-take-1.patch
>
>
> 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.
