I think there is no particular reason for this, just that this code grew over time. My general feeling about performance in Pike is also that in many cases these things do not make a huge difference. However, feel free to reduce it to one flags field in the Frame class and add getters for compatibility.
I have a general comment about adding things to pike 8.0. If you change existing code it means that those additions somehow need be properly tested before a release can be made. I think it makes more sense to add those changes to 8.1 first and backport them when they have been found to be sufficiently stable to be included in a _stable_ release. It also allows letting the APIs and conventions settle without shipping that to users. I know that there are no official rules about this, but I think it makes life alot easier.
Arne
On 09/26/16 15:58, Stephen R. van den Berg wrote:
General remarks/questions with regard to the information being stored in class Frame:
I see that you usually tend to separate out different bit-flags into their individual pike member variables of type int. Case in point: fin, rsv1, rsv2, rsv3 and mask.
Why don't you choose something closer to the wire-format where you use:
int flags;
enum { FIN = 0x80, RSV1 = 0x40, RSV2 = 0x20, RSV3 = 0x10 }
and then test for fin using: flags & FIN etc. ?
It's not like we require an ultra-userfriendly API to the basic frame flags. It just needs to efficient and readable.