SkData need not be a Flattenable, since it does not need subclass/factories

SkData need not be a Flattenable, since it does not need subclass/factories

BUG=
R=mtklein@google.com

Committed: https://code.google.com/p/skia/source/detail?r=11754

[mtklein, 2013-10-10 21:32:02]

One naming nit, otherwise lg2m.

https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
File include/core/SkFlattenableBuffers.h (right):

https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
include/core/SkFlattenableBuffers.h:102: SkData* readByteArrayAsData() {
Mentioning byte array here seems weird to me.  readData() / writeData()?   We
don't really include the details of encoding in any of the other names.

[sugoi, 2013-10-11 12:03:35]

https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
File include/core/SkFlattenableBuffers.h (right):

https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
include/core/SkFlattenableBuffers.h:102: SkData* readByteArrayAsData() {
Shouldn't it be pure virtual and defined in SkOrderedReadBuffer, like most the
other ones above ? I know it uses readByteArray, but I can foresee that a secure
version of this code may add a few safety checks in here.

https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
include/core/SkFlattenableBuffers.h:102: SkData* readByteArrayAsData() {
On 2013/10/10 21:32:03, mtklein wrote:
> Mentioning byte array here seems weird to me.  readData() / writeData()?   We
> don't really include the details of encoding in any of the other names.

+1

[reed1, 2013-10-14 13:32:13]

https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
File include/core/SkFlattenableBuffers.h (right):

https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
include/core/SkFlattenableBuffers.h:102: SkData* readByteArrayAsData() {
On 2013/10/10 21:32:03, mtklein wrote:
> Mentioning byte array here seems weird to me.  readData() / writeData()?   We
> don't really include the details of encoding in any of the other names.

I think there is no value-added to storing SkData in any separate way from just
an array of bytes, since that is precisely what it is (our public docs make it
clear that we don't interpret its contents in any way).

I see this has purely a helper function (since we have several internal
callers). read/write byte-array is already virtual, so this builds upon that.

Put another way, reading an SkData is just a convenience/choice by the caller. A
different caller may want to read the contents into a buffer of their own
choosing, and we should completely support that (since there is no loss of
information or abstraction). Thus we document that SkData read/writes are built
upon the lower-level byte-array interface.

[mtklein, 2013-10-14 14:28:53]

On 2013/10/14 13:32:13, reed1 wrote:
>
https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
> File include/core/SkFlattenableBuffers.h (right):
> 
>
https://codereview.chromium.org/26928002/diff/1/include/core/SkFlattenableBuf...
> include/core/SkFlattenableBuffers.h:102: SkData* readByteArrayAsData() {
> On 2013/10/10 21:32:03, mtklein wrote:
> > Mentioning byte array here seems weird to me.  readData() / writeData()?  
We
> > don't really include the details of encoding in any of the other names.
> 
> I think there is no value-added to storing SkData in any separate way from
just
> an array of bytes, since that is precisely what it is (our public docs make it
> clear that we don't interpret its contents in any way).
> 
> I see this has purely a helper function (since we have several internal
> callers). read/write byte-array is already virtual, so this builds upon that.
> 
> Put another way, reading an SkData is just a convenience/choice by the caller.
A
> different caller may want to read the contents into a buffer of their own
> choosing, and we should completely support that (since there is no loss of
> information or abstraction). Thus we document that SkData read/writes are
built
> upon the lower-level byte-array interface.

lgtm

[reed1, 2013-10-14 14:33:18]

Committed patchset #1 manually as r11754 (presubmit successful).