I have just started playing about with interface inheritance using the
'Implements' thing

All works fine in the VB proper because you go ...

Dim xObj as ILib.IClass
......
......
Set xObj = CreateObject("Lib.Class")

and this makes the connections between the interface definitions and their
implementations

How do I do this in VBScript ???

When you Set xObj = CreateObject("Lib.Class")

- the concrete class Lib.Class doesn't have the properties and methods
- can't use the DIM statement to tie up with the interface

----So what do I have to do


TIA

Andy

You can't - or more to the point - it's unnecessary. All VBScript object
references are late bound so there is no benefit to using interfaces anyway.
The reason for interfaces is to allow multiple objects to be defined *before
the implementation code is written* to support specific methods and
properties (eg. where more that one team is coding but they all work to the
same set of interfaces predefined in the design stages).

In VBScript all you can do is code against what is there so you do that
against the concrete classes, not the interfaces.

Chris.

[quoted text, click to view]
I have just started playing about with interface inheritance using the
'Implements' thing

All works fine in the VB proper because you go ...

Dim xObj as ILib.IClass
......
......
Set xObj = CreateObject("Lib.Class")

and this makes the connections between the interface definitions and their
implementations

How do I do this in VBScript ???

When you Set xObj = CreateObject("Lib.Class")

- the concrete class Lib.Class doesn't have the properties and methods
- can't use the DIM statement to tie up with the interface

----So what do I have to do


TIA

Andy

You can't do this from VBScript.

A COM object has a number of interfaces. If I create a COM object called
MyProject.MyClass that has an interface called IMyInterface then your COM
class has;

IUnknown - this lets any client query the object for a reference count and
to see what interfaces it supports

IDispatch - this is a list of functions the object supports that allows
late-binding via querying for a function by name.

_MyClass - this contains all public methods on MyClass and is called the
default interface. It is implemented for you under the covers by VB.

IMyInterface - this contains all public methods on IMyInterface.

When VB is the client of a COM object it can see and use *all* of these
interfaces. However VBScript is limited to IUnknown (all COM objects have
this and all COM clients must understand it) and IDispatch.

So VBScript clients can only use late binding for COM and/or the default
interface. So why can it see your public methods that are in _MyClass?
Because it is up to whatever builds the COM object to decide what goes in
IDispatch and the VB compiler chooses to only put the public methods in your
default interface into IDispatch. It will not put the methods in
IMyInterface into IDispatch.

In a nut-shell that is why you can't access custom interfaces on your VB
objects from VBScript.


[quoted text, click to view]

OK many thanks for the explanation but ...

I really want to use my middle tier code to support both a desktop client
and an ASP client (a major point to having an n-tier design)

What is the best way to achieve this - do I scrap the use of interfaces and
simply have a 'concrete' class library or is there some other way


Andy

[quoted text, click to view]

Yes. If you are using ASP/VBScript then you might as well not use
interfaces.

Well, you can hack it kinda. You can keep your interface but add methods to
your mail class that calls that interface, or the interface of your choice.

So you might have MyClass with MyFirstInterface and MySecondInterface that
both have a DoSomething method. The reason you implemented
MySecondInterface.DoSomething was to fix a big in the previous one. You
have existing clients that bind to the old one and some to the new one.

Well you can add DoSomething to MyClass also. Originally
MyClass.DoSomething would just have called DoSomething on MyFirstInterface
and your VBScript code would call MyClass.DoSomething. When you implemented
the second interface you can make your VBScript clients use it by updating
MyClass.DoSomething to call MySecondInterface.DoSomething. Or you could
create DoSomething2 and have your VBScript clients call that.

It is messy and defeats the point a little, but if you really want
interfaces it is the only way.

Ok I think I understand now

It does seem that there is a bit of a hole here though

- We split out the various tiers to so that various front ends use common
processes

- We use Interfaces to allow easier versioning and reuse

- Then ASP blows it by not allowing you to use these two excellent
techniques together

Oh well - many thanks for the help


Andy

[quoted text, click to view]

Got it in one :)