4.21.2012

More total Awesomeness

Did I mention how much awesomeness is in today? First I discovered this massive VM execution performance boost for "batch" operations on many elements, then I officially joined my internship company (I got stunned by the very first moment - already loving the professional start procedure) and then I even got around defining a good type system which does sursprisingly support fully blown OOP. I didn't it like that in the beginning, it rather came out of a wish to describe structures more detailed with patterns. Stuff like telling that this structure has a memory of cells with as much entries as the value of a property of this struct. It's essentially for describing dynamic structures and how the size different when knowing certain values. But how to described how many elements an array has if it's size depends on a multi-tude of other member values? Simple: override the size operator for the given struct member (yep, you can define operators for members without storing it in the actual object, defined for the wrapping type as well) and insert a custom code that functions like a method, taking an operators prefix parameters (those beeing on the left side) as a this pointer and the postfix parameters (those on the right side) as operator input. I already got a quite detailed concept, so it's hard to explain everything here. However, having operators telling a member's count as well as element access (done via the @ operator), you can create quite a varied range of structures and avoid needing to allocate stuff by hand. Just imagine you want to allocate a flexibly-sized struct. Usually, you'd create a struct with settings and pointers pointing to the memory location. This can be avoided by allocating only the fixed portions first and then use a builder function to re-allocate it using the fixed size properties and the size operators. Isnt't that interesting? I mean if you don't want to use this feature, you can still tell that want to have a pointer (which's called avariable in this language, since I wanted to avoid RTTI on the objects themselves, leaving data as stripped as it should be) or just give a fixed size, in which's case allocation is done only one time and you can still manage it yourself.

One downside of this dynamic concept is that you will only notice size mismatches during execution (though for not fixed size, since this is known). Well, you can't really check before the real data kicks in - invent something that does and you can sell it for big fortune teller money. There's no real function call overhead compared to builtin ones since every parameter passed to an operator will be generate once on the stack and can be left/altered there using the multitarget notation I described in the last post about this topic. If you don't pass any parameter, nothing will be generated. If the function doesn't need to use or check them, nothing will happen. So yeah, it's seems to flow together in a very natural way. Still a lot of stuff to designed and define, but since a lot of basics are already done now (the type system really a major one along with the multitarget idea), everything else should come as well. Surprisingly, indeed. I wonder why.

No comments: