Hi Fredrik,
Thank you for your response. Please don't think that I was
complaining. It was more the case that I had been building up this
impression that features were drifting and this particular JIRA
incident prompted me to ask whether that was really the case.
I don't know what policy I would set if I was in charge. Do you make
all implementations adhere to the lowest common denominator that all
languages support, or do you let languages that can do more do it? The
latter seems more productive by far.
I guess that I would say (looking ahead to Eric Anderson's reply to
your reply) that if you submit a patch that implements something like
cpp_verbatim in the idl, it should also implement java_verbatim,
python_verbatim, etc. because that comes essentially for free and you
don't need to know anything about the different languages. But if you
submit a patch that lets you do something cool in Erlang I wouldn't
hold it hostage to the c++ version.
But I haven't contributed any code, so I can't expect to get a vote. :-)
- Rush
On Dec 3, 2008, at 5:41 AM, Fredrik Hedberg wrote:
Hi,
Well, although I don't really think this is a major problem
(especially in this case, as this addresses a feature that is
already provided by C#'s native support for partial classes), I see
your point.
However, I'm not sure what the best solution is - some developers
are only fluent in a few languages, and others don't really have the
time, nor the incentive (guilty as charged), to implement a feature
across all the supported languages - the addition of a new meta-
component in JIRA where new features are discussed in a language
agnostic way perhaps?
As a side note; the patch in question is probably easily adaptable
for any other language generator in a matter of minutes, if it makes
sense for your language of choice.
- Fredrik
On Dec 3, 2008, at 1:52 AM, Rush Manbert wrote:
Just a small question.
This change is one of a number of changes that seem to be aimed at
only one language version of the Thrift-generated classes.
Have I gotten the wrong impression, or is the feature set starting
to diverge on a per-implementation-language basis? For instance,
someone wanted to derive Thrift classes from base classes in either
Java or C#, someone else says that deep copies are needed, but they
only seem to be concerned with Java. Now this change wants to be
able to extend Thrift classes in Java, maybe because that
capability has already been added for C#.
Am I wrong about this?
- Rush
On Dec 2, 2008, at 2:52 PM, Fredrik Hedberg (JIRA) wrote:
[ https://issues.apache.org/jira/browse/THRIFT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fredrik Hedberg updated THRIFT-219:
-----------------------------------
Description:
Since Java lack the equivalent of C#'s fancy 'partial' class
modifier, extending the logic of a Thrift-generated class means
you have to do it quite literally. This patch allows the developer
to write code templates that are injected into the generated
classes by the compiler, allowing him to extend the generated
classes in any way he wants.
The code templates are presumed to be found in something like /
tmpl-java/com/example/Document.tmpl, and are injected into structs
and services (.Iface and .Client).
was:
Since Java lack the equivalent of C#'s fancy 'partial' class
modifier, extending the logic of a Thrift-generated class means
you have to do it quite literally. This patch allows the developer
to write code templates that are injected into the generated
classes by the compiler, allowing him to extend the generated
classes in any way he wants.
The code templates are presumed to be found in /tmpl-java/
$packagename/$typename.tmpl, and are injected into structs and
services (.Iface and .Client).
Inject user-created templates into generated code
-------------------------------------------------
Key: THRIFT-219
URL: https://issues.apache.org/jira/browse/THRIFT-219
Project: Thrift
Issue Type: New Feature
Components: Compiler (Java)
Reporter: Fredrik Hedberg
Priority: Minor
Attachments: thrift-templates-1.diff
<snip>
