Re: Using early-bound interface on a late-bound object


"Larry Serflaten" <serflaten@xxxxxxxxxxxxxx> wrote in message
news:e8xLh8zuFHA.1032@xxxxxxxxxxxxxxxxxxxxxxx
>
> "Jiho Han" <jhan@xxxxxxxxxxxxxxxx> wrote
> > Right, so in my original code, I wouldn't have MyCompany.Contact
referenced.
> >
> > Really, the question seems to be whether at the time a late-bound object
> > is assigned to an early-bound interface, does everything get "taken care
> > of" once to gain all the benefits of early binding from that time on or
it
> > still need to resolve things as we move along like you say.
>
> The variable that is declared (Dim'ed) as a specific type will be early
bound.
> How a variable is declared is the deciding factor.
>
> If the assignment of an object to such a variable is successful, then all
calls
> using that variable will be early bound. There is a chance that the
assignment
> may fail, if, for example, your types are mismatched. Eg, trying to
assign a
> command button object to a variable declared as a Textbox.
>
> If the assignment is successful, then all the calls will be wired in as
early bound.
> FWIW: That doesn't happen at runtime. When you compile your program,
> the compiler determines which interfaces to use, and since your variable
is
> declared as a specific type, the compiler knows all it needs to know to
call
> the methods directly. So, in a nutshell, the compiler has already
compiled the
> program using early bound methods, all you need do is supply the object
that
> supports the declared interface (or declared type).
>
>
> > So which is it? Some of the others seems to be in disagreement. It'd
really
> > help if someone can point me to some authoritative document or reference
> > somewhere...
>
> Personally I've found the knowlege of an experienced programmer to be
slightly
> more accurate than some of Microsoft's documentation, but perhaps this
will
> help you 'see the light'. ;-)
>
> Speeding Object References
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/htm
l/vbconspeedingobjectreferences.asp
>
> BTW, I have also created a similar project as you stated elsewhere. It
was
> more of a proof of concept than any actual need, but I was able to supply
> additional functionality to a program simply by dropping special DLLs in
the
> application folder. The DLL's all supported the same interface that
allowed
> for discovery of the functionality (names and purposes) and calling
syntax.
> With the names and syntax in hand, I would expose the new functions to
> the user and know what parameters were expected in the call to its
'Execute'
> method. I though it was pretty neat at the time (around 1996-97 using
VB4)
>
> Good luck!
> LFS
>

There are quite a few large application suites which have taken this
approach. One ERP, iirc, <decided to delete the name to hide the guilty>,
used it exclusively during its early design and for its 'exposed
automation'. It also provides for an interesting division of labor - the
design crew could play with their tool box of 'interfaces' and the
implementation crew could play with their box of 'objects'. It also helped
within customer shops when they mirrored this 'division' to keep their
customization under control.

The company could react very quickly to customers needs. "You need this kind
of behavior? No problem we will just add a new Interface and have the
component do something a little different." And a new component went out the
door.

Unfortunately, it has a dark side. First, it confused beginning and
intermediate programmers alike. (The company pitched it has being completely
customizable using VB/VBA, by untrained bean-counters, and trust me it was.
Everyone soon stuck his finger in from CEO to janitors.), and second, they
quickly had multiple installed customers-bases all abusing the suite
differently. <g>

The system quickly become unknowable, and relief came only through the
employment of very expensive 'consultants' (previous employees), who ended
up with ocean-front property and exotic vacations. I wasn't one of them.
<sigh> I just got to clean up some of the messes.

I just thought you might be interested to learn that your idea was put into
practice. Also not as a condemnation. It was in fact a very good idea. But
as a warning that any system based on too much flexibility can become a
system with, well, too much flexibility. <g>

-ralph


.