Change header value reading code to use enum constants and lambdas

[dwalluck]

Instead of using magic constants in HeaderValue, use the types already defined in Type.

[ctron]

I like that change. But do we still need that int field? Wouldn't it make sense to remove that?

[dwalluck]

I like that change. But do we still need that int field? Wouldn't it make sense to remove that?

We might not need it. In that case, I would just change type from int to Type and not add a new field.

But, how do we handle an unknown type? In the current code, it will throw an exception when parsing.

We can add an UNKNOWN enum, I guess. We have the UNKNOWN class there was well, but I think we have to modify it to hold the original type value int since the enum cannot hold it.

[ctron]

Yea, if we want to handle unknown ones, then we need a different strategy (I do miss Rust here 😁).

Maybe an interface, which gets implemented by both the enum, as well as Custom class (carrying the int).

[dwalluck]

Maybe an interface, which gets implemented by both the enum, as well as Custom class (carrying the int).

What is the goal, to hide the original raw value from the API?

Take a look at how I implemented it now. I stored the type inside the Unknown class.

If this.type == Type.UNKNOWN, then you must go through ((Unknown) this.value).getType() to get the original type.

[dwalluck]

If this.type == Type.UNKNOWN, then you must go through ((Unknown) this.value).getType() to get the original type.

Actually, we may be able to get rid of Unknown and set this.value = originalType. I thought we also had the actual binary data belonging to the unknown type that we needed to store, or is that not possible?

[dwalluck]

@ctron OK, the Unknown class now should store the raw int type and the raw byte[] value.