On Tue, Sep 11, 2012 at 9:31 AM, David Medinets <[email protected]>wrote:
> I am looking to simplify some. Here is the code I am looking at:
>
> private Mutation cloneMutation(Mutation m) throws IOException {
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> DataOutputStream dos = new DataOutputStream(baos);
> m.write(dos);
> dos.close();
>
> ByteArrayInputStream bais = new
> ByteArrayInputStream(baos.toByteArray());
> DataInputStream dis = new DataInputStream(bais);
>
> Mutation m = new Mutation();
> m.readFields(dis);
> return m;
> }
>
> The readFields method in Mutation starts like this:
>
> @Override
> public void readFields(DataInput in) throws IOException {
> ...
> }
>
> It seems harmless to have readFields return 'this' instead fo void.
> Any objections?
>
> On a slightly different note, it seems like readFields should actually
> be a constructor. Because it's job is to set the row, data, value, and
> entries. Just as the other constructors do. Any objections to
> converting it to a constructor.
>
That readFields method is inherited from Writable, so you can't change it.
When I made IteratorSetting extend Writable recently, I thought it would be
nice to have a constructor IteratorSetting(DataInput din) that calls
readFields, so I added it. I wouldn't be opposed to adding such a
constructor to Mutation.
Billie