Oh... I didn't get you in the first round and went a bit off topic then!
OK then, my thoughts on this:
Hmmm... basically what you 're saying is that each block should handle its content "internally" (i.e., use methods to "hide" the content representation from the programmer). This means that the block will also have to display itself, because hiding the content representation from the programmer is no good if display the block using a function which, well, needs access to that same representation! (print_side_block() or something like that, it's in the code).
However, making blocks display themselves is bad, very bad, because we 'll be getting UI code in the block classes. All my instincts scream against doing this.
There is a solution, of course. The elegant thing would be to create a "UI handler" object, which would be responsible for displaying ANYTHING on screen. Let me connect this idea with Martin's templates and improvise a bit:
1. The block is created. Content is added to it using appropriate methods that it exposes.
2. The time comes to display the block. Let's assume we have a "UI handler" object, which we will conveniently refer to as $UI.
3. Call $UI->display($block_object). Now, $UI will need to do a little sniffing so as to decide what to do with the block object.
4. Did I tell you that ALL the block classes, and all other visual elements, will need to be derived from a class like UI_object?
5. $UI sees that $block_object is derived from UI_object. It is thus assured that $block_object will provide any methods needed to expose its content. For example, let's call $block_object->get_display_stuff() and get the results. get_display_stuff() is defined in class UI_object and overridden in all derived classes (chaining up to the parent, of course).
6. We now have the $display_stuff. $UI knows what type of object $block_object is, and it knows the $display_stuff. It can then decide what to do to display it. For example, it can assign $display_stuff to $SMARTY template engine object variables and then call $SMARTY->display($template_file). The value $template_file will be deduced from the object's type.
The above solution makes it extremely easy to convert between any display engine you want or will want in the future. It also completely disconnects UI elements from the HTML that will be used to display them. It hides the internal representation of their "content" from the programmer. It bells and it whistles.
But the price is obvious... LOTS of work, a complexity increase that the current status of Moodle may not warrant.
When designing the block system, making each block responsible for displaying itself would be an obvious feature to implement. But we didn't do it, exactly because of all the above. I hope it helps, one way or another.
PS: Now that Greece have reached the Euro finals we 're "informally" celebrating all day here! Good thing, celebrating!