I don't think it's appropriate to take a data structure explicitly exported as a BrightScript component and expect developers to treat it like a different construct based on what you pass it to. The interface is well defined. I would expect the ByteArray's count to be the highest addressable byte offset that was written to, as I think anyone else who reads the docs for that component would as well. It's no less raw to make sure BrightScript behaves as expected when accessing the data, when it doesn't alter the data in any way.
Ignoring principle of least surprise, an argument can still be made that it's worth setting the data correctly in the receive() call as it's much
faster than if you manually fix in BrightScript (assuming you need it to report the length correctly). BrightScript is quite slow compared to C/C++, so any code required to make the structure
correct after a call to a component written in C/C++ should be done within that component.
Now, I don't want to imply I'm unhappy with what we have now. They networking components are
functional for what I used them for, so any argument I have is pedantic at best. I was able to basically forget about the problem and move on once I figured out the workaround.
-- GandK Labs
Check out Reversi! in the channel store!