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.
>
