adjust representation of internal Items

[seanmonstar]

fixes #35

@reem I think this takes care of it.

[reem]

Why do we keep the raw representation around? Since changes in the typed representation aren't reflected in the raw representation, I don't see why we should.

Either we should disallow parsing under two different types or we should come up with a scheme to propagate changes between the two.

[seanmonstar]

I don't follow. The raw data is kept to parse a new header if the type is
different.

[reem]

I can set the value of a header's typed representation, then parse it under a new representation and I won't get the updated value.

I think that would be a non-trivial source of bugs, and also makes libraries much more dependent on one another.

[seanmonstar]

Oh I see. So, you think we should stick with the enum, and return None if
the typeids don't match?
On Sep 14, 2014 11:07 PM, "Jonathan Reem" notifications@github.com wrote:

I can set the value of a header's typed representation, then parse it
under a new representation and I won't get the updated value.

—
Reply to this email directly or view it on GitHub
#36 (comment).

[reem]

I've got a branch somewhere with most of a representation that just converts to the raw representation if you ask it for a different type. I'll probably PR later tonight or tomorrow.

[seanmonstar]

In that case, it's possible that a previous representation dropped some
data...
On Sep 14, 2014 11:23 PM, "Jonathan Reem" notifications@github.com wrote:

I've got a branch somewhere with most of a representation that just
converts to the raw representation if you ask it for a different type. I'll
probably PR later tonight or tomorrow.

—
Reply to this email directly or view it on GitHub
#36 (comment).

[reem]

That is also possible. I think both representations have their pros and cons and I'm not sure which is best.

[reem]

At minimum this can be refactored to not store the TypeId or the raw representation if we decide to not allow re-parsing.