I'll drop this stream concept and a provide a conventional function syntax instead. That doesn't mean that I can't use it for streaming from memory, but I once again I started seeing that immense complexity in interface and access... Just not worth doing it. Simple code, simple functions. It's not a good design to add additional layers making code and execution more troublesome. This is also what's bugging me about my allocator model because it's just no the type code I like to see. I have so many ideas that suit awesome in OOP environments, but are complete garbage in usage and extremely simple in implementation. Also, I have some different plans for what kind of allocation is the best for my needs. There's a single design I can rely on and everything else can be done by the OS. I mean there are reasons for why they are made and why you can use their provided functions as much as you wish. However, the NXT still has no directly controllable dynamic memory. Atleast I couldn't find any detailed descriptions about how it is implemented. But I can only guess, so I'll make my concept true and design a block-based memory allocator as I described in a earlier blog entry. I can think of some nice things using that including a completely program reboot while it's running to clean up all the mess it started and get some new test runs without always needing to reboot the brick.
Anyway, I'm glad I dropped this idea and went over to simpler things in terms of layering. I'm also close to removing my serialization/deserialization system. I mean it has it's quite nice advantages, yes, but I don't think I'd like to maintain it or even implement a single function using it... What an irony. Me the one who dislikes OOP creates concepts that only really work in OOP. Too bad that OOP sucks balls (hm, balls...).