On May 26, 2008, at 4:22 PM, David Reiss wrote:
In the current libraries, all these classes pollute the global
namespace. They should all be encapsulated under a Thrift module
I am 100% in favor of this.
given better names (such as Thrift::Protocols::BinaryProtocol instead
TBinaryProtocol).
This I'm not so sure about. We could do this in C++, Java, and Python
too, but I don't think it is the right call. The cost of the extra
"T"
is tiny, and it makes it easier to do imports without bringing in
names
like "Protocol" and "Transport".
Do you mean if you try `include Thrift` in your code? I would argue
that such a practice is not appropriate for production code. However,
if this is something people are concerned about, it wouldn't be much
trouble to include a 'thrift/old' library which provides top-level
names like TBinaryProtocol that map to
Thrift::Protocols::BinaryProtocol. I would also point out the
wonderful EventMachine library, which is architected very well and it
uses EventMachine::Protocols::Foo as its namespacing. It works pretty
well.
The
method names are not idiomatic to ruby - I'm seeing things like
readStructEnd instead of read_struct_end and isOpen instead of open?.
I'm fine with changing these, but I am super biased against camelCase.
What do others think?
Idiomatic ruby code uses underscores instead of camelCasing. Look at
any system-provided ruby library and you'll see methods like
File.writable_real? instead if File.isWritableReal.
I'm also seeing attempts to mimic Interfaces/virtual classes, which
is
just plain ugly (see TProtocol where every method returns nil).
As long as there is a nice way of documenting what methods are
expected
to be implemented in the concrete subclasses.
How about comments? They're just as good as methods that do nothing,
except they make no attempt at mimicing an interface. Those methods
should be commented anyway for rdoc purposes. This also has the
benefit of raising an exception if someone calls an unimplemented
method instead of simply doing nothing, as the current code would. We
could also provide a sample implementation that defines all the
methods, so users can look at that for what they're expected to do.
Is there a git repository somewhere?
There is an unofficial repo at <git://thrift-git.thruhere.net/thrift.git
>.
A lot of non-committers have been using it to develop and share
experimental branches. I can give you an account so you can push
branches if you send me your ssh public key. If you prefer
github, it
is mirrored at <http://github.com/dreiss/thrift/tree/master>, but
I've
been encouraging developers to also push their changes to thruhere
so
everything will be in one place.
How frequently is that mirror updated?
Every 5 minutes.
But I assume it's meant to be read-only? I'm thinking maybe I should
fork that, then simply regularly push back to thruhere so, as you
said, it's all together.
-Kevin
--
Kevin Ballard
[EMAIL PROTECTED]
