"implements" inelegance

[Marty Lee]

Howdy All,

I'm puzzled by the apparent inelegance that arises when
the "implements" keyword is used. Say that we have the
following two classes, the second class implementing the
first class:

Class 1: "MyInterfaceClass"
With: "MyInterfaceMethod"

Class 2: "MyImplementsClass"
Implements "MyInterfaceClass"
(including MyInterfaceMethod)
and extends with: "MyImplementsMethod"

It should be possible, I think, to declare a new instance
of "MyImplementsClass" and be able to reference both
methods. However, if a new object variable is
declared "as MyInterfaceClass" then I can use
the .MyInterfaceMethod but not .MyImplementsMethod. If
instead I declare an object variable "as
MyImplementsClass" then I can use the .MyImplementsMethod
but not the .MyInterfaceMethod.

To work around the issue I've been using the following:

Dim _
myImplements as MyImplementsClass, _
myInterface as MyInterfaceClass

set myImplements = new MyImplementsClass
set myInterface = myImplements

By having two names for a single object I can get to all
methods. But how ugly! Any suggestions on improving the
esthetics? (I'm working in Word 2000 VBA.)

thanks,
Marty

 

[Jezebel]

I think there may be something else going on here that's causing your
problem.

If you declare an object as MyImplementsClass you *should* be able to refer
to anything in it that is public, including both MyInterfaceMethod and
MyImplementsMethod. That's certainly the way it's intended to work (and the
way it normally does work!).

 

[Word Heretic]

G'day "Marty Lee" <[email protected]>,

Go straight to Amazon - do not pass go, do not collect $200. Purchase
the VBA Developer's Handbook from Sybex by Ken Getz et al.

Worth its damn weight in gold, and its a muther of a book. It explains
all the ins and outs of reusing your implementations as that's the
whole damn idea right.

Howdy All,

I'm puzzled by the apparent inelegance that arises when
the "implements" keyword is used. Say that we have the
following two classes, the second class implementing the
first class:

Class 1: "MyInterfaceClass"
With: "MyInterfaceMethod"

Class 2: "MyImplementsClass"
Implements "MyInterfaceClass"
(including MyInterfaceMethod)
and extends with: "MyImplementsMethod"

It should be possible, I think, to declare a new instance
of "MyImplementsClass" and be able to reference both
methods. However, if a new object variable is
declared "as MyInterfaceClass" then I can use
the .MyInterfaceMethod but not .MyImplementsMethod. If
instead I declare an object variable "as
MyImplementsClass" then I can use the .MyImplementsMethod
but not the .MyInterfaceMethod.

To work around the issue I've been using the following:

Dim _
myImplements as MyImplementsClass, _
myInterface as MyInterfaceClass

set myImplements = new MyImplementsClass
set myInterface = myImplements

By having two names for a single object I can get to all
methods. But how ugly! Any suggestions on improving the
esthetics? (I'm working in Word 2000 VBA.)

thanks,
Marty

Steve Hudson

Word Heretic, Sydney, Australia
Tricky stuff with Word or words for you.
Email (e-mail address removed)
Products http://www.geocities.com/word_heretic/products.html

Replies offlist may require payment.

 

[Jezebel]

I'm sorry, you're quite right. Implements doesn't work properly in VBA. I
was talking from my VB experience, but having just copied a couple of
classes into a VBA project, the symptoms are exactly as you describe.
'Implements' seems to work at design time, but not at runtime. (Perhaps
we're both missing something!)

Don't let that interfere with your understanding of how implements is
supposed to work --

Since VBA makes the subroutine private, it is clear that I
can't use this method if I instantiate a new
MyImplementsClass object.

This isn't right (in VB). The methods of the interface class are Public in
the template (MyInterfaceClass in your example) and Private -- prefixed with
the name of the template -- in the implementation. That's as it should be.
These methods are referenced (in effect) indirectly via the template, not
directly as is the case with the implementation's public methods.

 

[Marty Lee]

Jezebel,

I will definitely look at VB, VBA is wearing on my
nerves. Thanks very much for trying those examples and
reporting the results, it makes it much easier to
understand why I seem to be picking up conflicting advice.

Marty

 

[Word Heretic]

G'day "Marty Lee" <[email protected]>,

It is 'publicly' available to your class for its definition. However,
that class need to 'publicly' implement the provided implementation. A
tad messy sure.

Jezebel,

I will definitely look at VB, VBA is wearing on my
nerves. Thanks very much for trying those examples and
reporting the results, it makes it much easier to
understand why I seem to be picking up conflicting advice.

Marty

Steve Hudson

Word Heretic, Sydney, Australia
Tricky stuff with Word or words for you.
Email (e-mail address removed)
Products http://www.geocities.com/word_heretic/products.html

Replies offlist may require payment.

 

[Marty Lee]

G'day Word Heretic,

I'm reading between the lines, but I think you are
suggesting that a VBA class that implements an interface
needs to be altered. That is, all the inherited
properties and methods need to be manually changed from
Private to Public. I tried the suggestion. For example
I have an interface class called ISquare. It provides for
a "Square" method (for calculating the sqaure of a
number), so the implementing class (SquareClass) inherits:

Private Sub ISquare_Square(lngNumber as long)

I manually changed this to:

Public Sub ISquare_Square(lngNumber as long)

Now the method is available to any object instantiated as
SquareClass. But to use the method, you have to invoke it
as:

<object>.ISquare_Square

rather than:

<object>.Square

As you say, messy. I agree with Jezebel; either we are
missing something about VBA or VBA's handling of
inheritance is screwed up. Object oriented programming is
supposed to "hide" complexities, not create them.

Marty

(The real email address is at 'msn', not 'nsm')

 

[Lars-Eric Gisslén]

Marty,

I my oppinion implementing an interface is not about inheritance at all.
With inheritance you inherit functionality from the patent Class. When you
implements an interface _you_ provides the functionality. What you do when
you implements an Interface is that you guarantee that your Class will
follow a specified Interface. That is is as far from Inheritance as you can
get.

I have been developing with a fully OOP language for about ten years now and
in my oppinion VB/VBA does not belong to OOP languages. In VB/VBA you can
define your own Classes but that's all there is to it. The most fundamental
in OOP is infact inheritance, which VB/VBA does not support at all, and
another important thing is abstraction, which require inheritance, and that
require a quite big mind shift when designing application compared to
procedure oriented programming like in VB.

Regards,
Lars-Eric

 

[Jezebel]

Here's a bit from the VB documentation "Creating and Implementing an
Interface" (in their example, the template class is 'Animal' and the
specific implementation is 'Flea'), on why these methods should be private:

You may be wondering why the procedures are declared Private. If they were
Public, the procedures Animal_Jump and Animal_Bite would be part of the Flea
interface, and we'd be stuck in the same bind we were in originally,
declaring the Critter argument As Object so it could contain either a Flea
or a Tyrannosaur.

 

[Lars-Eric Gisslén]

Marty,

<object>.ISquare_Square

rather than:

<object>.Square

I think that is the correct behaviour. As you have a method ISquare_Square
you can also have a method Square that is not a part of the interface you
support. If you would be able to use <object>.Square to call
..ISquare_Square, how could the compiler resolve your call if you also have a
Square method?

Regards,
Lars-Eric

 

[Marty Lee]

Hi Jezebel,

That's an interesting reference, although it leaves me
feeling that "the explanation doesn't explain". Perhaps it
would help if I had more context. I tried searching the
MSDN site for all the words (Animal Flea Jump) or for all
the exact phrase "Implementing an Interface" but could not
find the text. Can you point me to that documentation?

Thanks
Marty

 

[Marty Lee]

Howdy Lars-Eric,

It all depends on where you start. Truly, there is
much to be said for your point. On the other hand, I
believe the whole purpose of having an interface class
(Jezebel calls this a "template class") is to ensure that
a ".Square" method is always and readily available to any
class that should implement the template. Perhaps this is
a small point, but it seems to me that forcing the calling
routines to use:

<object>.ISquare_Square

actually prevents a "ready availability" of a
universal ".Square" call.

As a side note, please forgive my throwing around terms
like "inheritance". I'm an newbie programmer with no OOP
experience. Getz and Gilbert use the term "Interface
Inheritance" in their "VBA Developers Handbook" so I
thought it might be OK. Many people have commented on the
lack of true OOP mechanisms in VB, so I will try to stick
with "interface/template" classes and "implementing"
classes.

best,
Marty

(as always, the real address is "msn" not "nsm")

 

[Jezebel]

I pulled it from the VB documentation. It's part of the series explaining
Implements and (what MS call) polymorphism. The specific document is called
"Creating and Implementing an Interface".

 

[Word Heretic]

G'day "Marty Lee" <[email protected]>,

She tells the truth. I recognized the ref straight away. Try
inheritance and those sorts of keywords - its there. I wish I could
disagree with Jez's basic sumnation (coz our code would be easier) but
it's spot on.

It's the type of issue that VS.NET addresses whilst still completely
missing the point. <sighs> I guess I've been implementing languages
for too long.

Hi Jezebel,

That's an interesting reference, although it leaves me
feeling that "the explanation doesn't explain". Perhaps it
would help if I had more context. I tried searching the
MSDN site for all the words (Animal Flea Jump) or for all
the exact phrase "Implementing an Interface" but could not
find the text. Can you point me to that documentation?

Thanks
Marty

Steve Hudson

Word Heretic, Sydney, Australia
Tricky stuff with Word or words for you.
Email (e-mail address removed)
Products http://www.geocities.com/word_heretic/products.html

Replies offlist may require payment.

 

[Jezebel]

If you were a conspiracy theorist, you might suspect that MS has removed the
indexing to VB documentation, in favour of VB.NET. But anyway, here it is:

http://msdn.microsoft.com/library/d...n98/html/vbmscVisualBasicDocumentationMap.asp

 

[Malcolm Smith]

Indeed. Which is why I keep an old copy of the MSDN to hand at all times.

Malc

 

[Marty Lee]

Thanks again,

I do appreciate having that reference! The search
engine at MSDN does seem a little muddled, but when I took
that survey Microsoft made of MSDN users I was strikingly
ineffective at suggesting better approaches.

Marty