All Blitz methods are what in C++ would be called 'virtual' - they use dynamic binding at runtime. The assembly code emitted for obj.DoStuff() is the same regardless of whether the method is abstract, final, extended in another type or a combination of those.
Actually GW is right : final methods can be compiled more efficiently in some situations. In his example, the instruction "t2.DoStuff" calls a final method, thus the compiler knows for a fact that if t2 actually point to an instance of a type derived from tMyType2 (rather than to an instance tMyType2), then it doesn't changes anything as DoStuff cannot be overriden (so it can only be tMyType2.DoStuff that gets called). This means there is no need for a dynamic dispatch here, a direct call (as when calling a plain function) is sufficient.Wether BlitzMAx does it or not is another story.
Local variables do not take memory.
Of course they do. There are a limited amount of registers (very little on intel CPUs) so that even if the compiler stores *some* local variables directly in registers there's always a point where it has to be stored on the stack (your saying 10, ok maybe). But the real point is that there is not just one function on the stack at one point. If your first function (with local variables stored in registers) is calling another function, where will it store these local variables while the second function is executing? Right, on the stack, so in the end the more local variables has the first function, the more it takes memory at one point.And actually usually functions do not work that way, they do store local variables on the stack (only they might load their values in registers *too* at the beginning for speed purpose).
That's a very good reason for giving a get/set interface to external code. Remember, premature optimization is the root of all evil. Do what seems cleanest and most convenient; worry about efficiency in the unlikely case that it ever becomes a problem.
That's a very good advice in general. But getters and setters generally make the code much less readable - not cleaner - IMHO, unless the compiler provides some syntactic sugar for calling getters/setters as if you were accessign simple fields (ala C# properties). That's why it would be really nice if BlitzMax provided such a syntactic sugar : you get