1) You can only provide custom functions for a limited set of function field names, so you need to know all those names in advance. Useful, certainly, but not useful for the same kind of problem as I have.
Thats exactly something that is NOT possible in a compiled language.
Either you know upfront what you are after or it will not work outside a scripting language.
So if you do not know what is passed in you must wrap that into an object that you pass in and then either extract the information from that one or let it perform a specific task to use the information straight away.
On your answer at the "top":
I fear you do not understand that such a "sugar" can not work within a compiled environment out of the box.
Such a thing (which is dynamic extension, you try to take a TMap and dynamically *at runtime* extend its capabilities to those of TBAMap) is heavily reflection based and reflection is slow.
A programmer might even want to have their own private set of extensions that they often use with built in classes. I have a ton of functions that oeprate primarily on a single existing class that I did not write. I have to use the non-object oriented syntax to call these functions. Creating these as methods in subclasses doesn't make sense because, as I said before, I can't directly use my custom functions on objects returned by other libraries or BMax built in functions.
Show me sample code that shows exactly this problem and I really mean exactly this problem not some kind of strange problem related in some way with it.
And especially show me how the usage of decoration does not work in that case, because I can simply show THAT it works!
SuperStrict Type TBAMap Extends TMap ' Decoration class to extend TMap without changing its implementation or directly extend it. field map:TMap Method Encode:String() Local Result :String Local K:String For K = EachIn map.Keys() Result = Result + String(K) + "=" + String(map.ValueForKey(K)) Next Return Result EndMethod EndType Local map:TBAMap = New TBAMap ' Change to map:TMap = New TBAMap and it will work map.map = new TMap map.Insert("test", "test value") Notify map.Encode()
That code does not care how the library object is implemented or anything the like. It only takes it to perform operations on it.
You could even use that to implement features of a class that the decorator wasn't even extended of.
For example you define an Abstract A with the given abstract methods you need.
then you have B extends A with full implementation of it
and then you take C extends A with a field "A" to which you assign an object of class B (in this example). Now you can reimplement the whole set of features (or just call that object original implementation).
there is no need you would even want to Cast from A to B if the stoerd handled was not a B upfront, if you use a decorator
The stream wrapper classes of BM by the way are all decorators as well and not pure extensions.
If you are interested in really learn how to use the real power of OO programming instead of trying to get script like approaches into it, I suggest reading a book on Design Patterns.
I personally prefer "Head First: Design Patterns" above all others I've read on the topic