[AccessD] Interfaces

Shamil,

>>I'd note all that below are "old school" 
>>definitions (beginning of 90ies) 

Yes, I admit that. 

>> ... COM and VB6/VBA, good but too inflexible ...
>> ... late bound interfaces/run-time binding 
>> are in the same or even bigger favor ...

Surprisingly, VB6/VBA is not fundamentally inflexible -- but the
orthodoxy of how to use it is. Remove Option Explicit from your module
header, and you can write code like: 

Public Sub Test()
    a = "ABC"
    b = 1234
    Set c = CurrentDb()
    Debug.Print a, VarType(a)
    Debug.Print b, VarType(b)
    Debug.Print c.Name, TypeName(c)
End Sub

Looking kind of dynamic, no? But how many times have the VB gods told
you that this style of code was wrong? And VB has always had late bound
interfaces/run-time binding using the Object type. In fact, it may be
possible to do a decent implementation of run-time introspection and
partial binding to foreign interfaces -- using VBA only, with no custom
support DLLs/ActiveX required.

My point is not to bash the new stuff -- it has its obvious merits. But,
if you are prepared to shed preconceptions, the old wave can probably do
95% of what the new wave can do.

>> ... Test driven development means that you tested 
>> all the interfaces by running unit tests ... 

That is the big problem with dynamic languages: verifiability. Thus, the
emphasis on test-driven development in the dynamic Ruby and Python
platforms. It is the latest attempt to bridge the chasm between
static/inflexible/verifiable languages (C, C++, Java, ...) and
dynamic/flexible/hard-to-verify (Lisp, Smalltalk, Python, Ruby).

I bring up Lisp and Smalltalk because they, in their day, were supposed
to revolutionize the world with their dynamic flexibility -- but they
didn't.

>> Ruby is the next challenge to MS C# and VB.NET...

In terms of purity of concept, Ruby is it. For the time being, I'm going
with Python, not because it is the 'ideal' language, but for purely
practical reasons that I am not going to outline in this post. 

-Ken