With apologies for soapboxing...
---------
From: Chad Walters [mailto:[EMAIL PROTECTED]
> I would actually love to see some mechanism to allow for the compiler to
be abstracted to the point where we could implement it in a broad choice
of languages (C++, Java, Ruby, etc.) and still produce the same target
language bindings. This would free non-C++ shops from needing the C++ tool
chain.
---------
I hate C++ as much as the next guy, but at least the compiler is somewhat
cross-platform. You can build the compiler under Windows by using Cygwin.
That the C++ client libraries are not cross-platform, however, I see as a
much more considerable issue.
-Justin
On 8/25/08 4:36 PM, "Torsten Curdt" <[EMAIL PROTECTED]> wrote:
Hey guys,
I've looked into Thrift recently and a few questions came up:
1. Why a native compiler? Would it me a little bit simpler to have the
compiler/code generator written in java? No language debate - just a
curious question for the reason :)
2. Wouldn't it make sense to have a bit of better separation than
having all code mixed up in the t_*_generator.cc files? Maybe more a
template approach so adjusting the code that gets generated becomes a
little bit easier?
3. Why not use the hash code of the attribute names as the sequence id?
4. Why only composition? Even a flattening model of multiple
inheritance should be quite easy to implement (if overloading is
forbidden). While in OOP I am big fan of composition over inheritance
it makes the generated API kind of ugly. Maybe a include mechanism
would be another way of simplifying composed structures. (Although I
do realize that with the current model of sequence ids that might be a
PITA to maintain)
5. If I noticed correctly the names of the attributes are included
when serialized. Why is that? Shouldn't knowing the sequence id be
good enough?
6. How do you guys suggest to deal with deterministic semantical
changes. Let's say you have
struct test {
required string a;
required string b;
}
and then you want to combine those values into one attribute
struct test {
required string ab; // = a + b
}
There are a couple of problems I see here. For one ab will have to
have a different sequence id. And I guess then the 'required' will
become a problem for sequence of a and b(?). And finally the
conversion of ab = a+b needs to be handle on the application level
while rule is very straight forward and deterministic and *could* be
expressed in more generic manner.
7. Wouldn't it make sense to separate out the service and exception
stuff from the actual message versioning/serialization code?
cheers
--
Torsten
