Basic POO question

[Chris Holbrook]

Am I really doing this right?

I pass a reference to an object and when it is received it is a reference to an Interface!

A bit of magic. The girl in tights throws a big silver ball and the man in the sparkly suit catches a bunch of live pigeons.

Yet it appears to work in my program without so much as a puff of smoke.

        method a
            local l as long
            l = stdfun(me) '<============== call the regular function
                           '                passing the OBJECT handle
            ...
        end method

'-------------------------------------------
function stdfun ( x as InterfaceX ) as long  
     function = x.b      
end function

[Dominic Mitchell]

It is not magic. The help file clearly states that ME references the current object.
In your case, ME references the interface method a is a member of.
If it was a class method, it would reference the class.

[Chris Holbrook]

It is not magic. The help file clearly states that ME references the current object.
In your case, ME references the interface method a is a member of.
If it was a class method, it would reference the class.

So when the same help file asks the question,"What is an object, anyway?" and replies beginning with

An object is a pre-defined set of data (variables), neatly packaged with a group of (code) which manipulate the data and provide any other functionality you need...

The full definition given here of objects does not contain the word "interface", which appears to contradict your explanation. Or maybe you are right and an INTERFACE is an object, but for some reason is not described under this heading. Or, is it glossing over the distinction between an OBJECT and a CLASS? If an interface is an OBJECT, then where is its "pre-defined set of data (variables)"? Or is a Class a collection of related objects, having INSTANCE variables and CLASS METHODS in common? Clearly, for a single CLASS, ME can mean n + 1 things, where n is the number of interfaces.

If ME is an object reference then the Help page on "what is an OBJECT" needs to be revised.

[Dominic Mitchell]

I guess the term object is a bit misleading.
An object that exposes two interfaces can be represented graphically as follows:

   Object(class)
   +-----------------------------------+
   |  class methods and                |
   |  instance variables               |
   |                                   |
   |  +----------------------------+   |
O-----| IX (properties and methods)|   |
   |  +----------------------------+   |
   |                                   |
   |                                   |
   |  +----------------------------+   |
O-----| IY (properties and methods)|   | 
   |  +----------------------------+   |
   |                                   |
   +-----------------------------------+

Think of those rectangles as the addresses of blocks of memory.
When you use ME within a class method, you get a reference(a pointer) to the object itself.
When you use ME within a method or property of an interface, you get a reference to the interface not the object.

What is needed is a more detailed post, but I am short on time right now.

[Chris Holbrook]

What is needed is a more detailed post, but I am short on time right now.

Au contraire, what is needed is accurate and comprehensive documentation accompanying the product.

But if that does not exist, then your contribution will help newcomers to the Object Experience if it is accessible.

I notice that most of the posts in this forum are from experienced practitioners - no surprise. I will contribute some nursery-level examples to redress the balance.

**** I forgot to say - an appealing analogy is that of INTERFACES as described by you as being facets of a CLASS. Or you could say that ME can mean two things, either an INTERFACE or a CLASS, depending upon the context. I always thought of OBJECTS as being instances of a CLASS, as in "a class of objects".

[Bob Zale]

...what is needed is accurate and comprehensive documentation accompanying the product...

Chris--

You are mistaken. The PowerBASIC Object and COM documentation is extraordinarily accurate and complete. It's the best and most succinct description of this topic I've ever seen. You do your friends here a great disservice by suggesting it is poor, so some would just ignore it. You need to GOTO: OBJECTS and COM Programming and read it very carefully, word for word. It contains a huge amount of very tightly packed information, so you must use care. The moment you read anything you don't fully understand, go back and re-read it until you "get it". {smile} Otherwise, you'll get lost in a hurry when that information is used as the base for another topic. If there's anything you still don't understand, ask the question -- you'll get an answer.

Some important corrections:

1- ME means one thing and one thing only. It returns a reference to the current object. Nothing more. Nothing less. Nothing else. Never. It's not a CLASS nor is it an interface. It's a reference to an object. The current object, when and where it was used.

2- A Class is not an object. An Interface is not an object. A Class is the definition of an object. An Object is an instance of the Class. An Interface is a definition of the Methods which may be used to manipulate data in an object. A good analogy is a TV set. The plans for the TV are like the Class. The TV itself is like the Object, an instance of the plans. You can make many TV sets from one set of plans, just as you can make many objects from one definition of a Class. The knobs on the TV are like Methods, because they are used to manipulate the TV. All the knobs, taken as a whole, are like an Interface. A pre-defined group of Methods used to manipulate the data.

More questions? Please ask. I'll see you get the correct answers.

Best regards,

Bob Zale

[Edwin Knoppert]

Though a point of warning, each interface of the instantiated class gives his own objptr.
Having multiple interfaces may appear confusing, later on they'll serve you fine.
Learning to work with PB com support may take some time.
I did 1 or 2 weeks about using it in the simpliest way.
(How to deal with it and what to avoid)

[Erich Schulman]

Sometimes it is not a question of the docs' accuracy and completeness, but that they were not written according to how your brain learns. In this case, seek out documentation that explains it a different way. Unfortunately, that likely means something not based on or including PB. If you have no other language experience, something based on Python would probably be easier than something based on C++. But Python COM does hide some things from you that PB keeps visible. Just stay away from anything .net. Bottom line is to get a handle on COM itself first.

If you do get something based on another language, remember that COM classes are unrelated to Python and C++ classes. One such book I have read also describes interfaces as being like a listing of what can be done while the object is where each interface is actually implemented.

Sooner or later, you will have to return to the PB docs for COM, but a different teacher might help you get off the ground.

/* I have only minimal VB experience, so I can't say if a VB-based text would be helpful. It might be enough like PB to be helpful. Or VB might have only just enough in common to get you more confused. Perhaps someone with more VB experience can address that. At least with C++ and Python, you know they are not like PB. */

[Edwin Knoppert]

>Just stay away from anything .net
You must mean VB.NET
C#'s classes and for example function overloading is really good.
VB.NET does not do overloading but optional parameters.
This may confuse people and imo mis the good stuff.

It's time to remove all languages except C# from .NET.
C# is so BASIC like.

[Chris Holbrook]

You are mistaken. The PowerBASIC Object and COM documentation is extraordinarily accurate and complete. It's the best and most succinct description of this topic I've ever seen. You do your friends here a great disservice by suggesting it is poor...

You are clearly very proud of your documentation. Good for you! But it's not only me... Dominic's post also demonstates confusion about what is an object, and what an interface. He's a pretty good and experienced programmer.

Maybe because I a) simply don't care about COM, b) have used object Pascal and derivatives for 20 years I have skimped on my reading - it's a possibility.

If there's anything you still don't understand, ask the question -- you'll get an answer.

I asked - post #1... haven't got an answer though. I call the function with an Object (ME). I receive the Object as an Interface. My question, "Am I really doing this right?"

Some important corrections:
[/B]

ME means one thing and one thing only...It's a reference to ...the current object, when and where it was used.

I understand.

A Class is the definition of an object. An Object is an instance of the Class.

I know - in fact I said so in post #5.

The knobs on the TV are like Methods

Bob, you are showing your age!

After my initial post I did a bit of investigation, limited to the IUNKNOWN type of interface in a single class. I concluded that the ME part of a method reference is fixed and the <methodname> part is an offset into a table of methods appropriate to the interface which the programmer has defined (it is not type-checked to distinguish between interfaces, so it is perfectly possible to call a function expecting a different interface, BTW. Maybe this has something to do with COM and polymorphism? This appears to contradict what Edwin says, BTW.

I'm sure someone will correct me if I got this wrong.

[Trevor Lane]

Au contraire, what is needed is accurate and comprehensive documentation accompanying the product.

At what stage is the documentation complete?

If I hire a car to get to an airport should I complain that the manual does not include directions to the airport?

If I buy a spanner to fix a washing machine, should I expect a service manual for the washing machine with the spanner?

It might be expected that if you buy a tool to do a job, you at least understand the job.

[Chris Holbrook]

Sometimes it is not a question of the docs' accuracy and completeness, but that they were not written according to how your brain learns. In this case, seek out documentation that explains it a different way. ...Sooner or later, you will have to return to the PB docs for COM, but a different teacher might help you get off the ground.

Eric, thanks for that analysis, you may be right about the brains. Mine likes pictures!

For me, it's not a question of getting off the ground, but rather of landing on an unfamiliar runway. I'm happy to avoid COM until it pays me not to.

[Chris Holbrook]

It might be expected that if you buy a tool to do a job, you at least understand the job.

Thanks, I shall try to bear that in mind!

[Edwin Knoppert]

Check this out:

Class Class1

    Class Method Create
    
        MsgBox "Class1 Method Create " & Format$( ObjPtr( Me ) )
    
    End Method

    Interface Interface1: Inherit IUnknown

        Property Get Int2() As Interface2
            Property = Me
        End Property

    End Interface

    Interface Interface2: Inherit IUnknown

        Property Get Int1() As Interface1
            Property = Me
        End Property

    End Interface

End Class

    Local i1 As Interface1
    Local i2 As Interface2
    Local i3 As Interface1
    Local i4 As Interface2
    Local p1 As Dword
    Local p2 As Dword
    Local p3 As Dword
    Local p4 As Dword

    i1 = Class "Class1"
    i2 = i1.Int2
    i3 = i1
    i4 = i2.Int1
    
    p1 = ObjPtr( i1 )
    p2 = ObjPtr( i2 )
    p3 = ObjPtr( i3 )
    p4 = ObjPtr( i4 )
    
    MsgBox "i " & Format$( p1 ) & ", " & Format$( p2 ) & ", " & Format$( p3 ) & ", " & Format$( p4 )

Class ptr:

---------------------------
PowerBASIC
---------------------------
Class1 Method Create 1418948
---------------------------
OK
---------------------------

---------------------------
PowerBASIC
---------------------------
i 1418972, 1418948, 1418972, 1418972
---------------------------
OK
---------------------------

[Bob Zale]

Dominic's post also demonstates confusion about what is an object, and what an interface. He's a pretty good and experienced programmer.

Yes, Dominic is an experienced programmer. However, if he is confused, I'll be happy to answer his questions, too. I'll be very happy to answer anyone's questions. Just ask! Everything I said here (and much more) is covered explicitly in OBJECTS and COM PROGRAMMING in the PowerBASIC documentation. If you read and understand that section, you will have everything you need to know to create and use objects. Objects internal to your program, and objects external to your program (COM Objects).

An Interface is an abstract definition of a set of Methods (functions). An Interface is one of the components (parts) of a Class. If you start with an Interface, add some Instance Variables, maybe some Class Methods, and perhaps another Interface or two, you end up with a Class. If you instantiate a Class, you get an object. An Object Variable is a reference (pointer) to a Class.

You cannot have a pointer to an Interface, because an Interface is just a definition. You may be confusing an Interface with a VFT, a Virtual Function Table, or a VTable (all one and the same). A VFT is a vector of pointers to methods which are used in an object. Actually, you don't need to worry about a VFT at all, because PowerBASIC handles it for you completely. You should just be aware of its existence, just in case you come across a mention of it.

Best regards,

Bob Zale
PowerBASIC Inc.

[Bob Zale]

"I pass a reference to an object and when it is received it is a reference to an Interface!"


I really don't understand this. What makes you think that this item is a pointer to an interface? A reference (pointer) to an object remains a reference to an object as long as the object exists. It does not morph itself into something else.

Now, an Object Variable is declared as an Interface name. Very similar to the way a UDT variable is declared as a TYPE name. That is just to tell the compiler that you will be using Methods of that Interface whenever you use this Object Variable. That's how a compiler can allow you to have many Methods of the same name. Or to use the same interface in more than one Class.

Best regards,

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

Objects. Classes. Instances. Virtual Function Tables. Interfaces. Kind of makes me long for

10 PRINT "HELLO"

[Erich Schulman]

Think of a restaurant's kitchen as an object. The menu is the kitchen's interface. You(r PB programs) are the client. (Of course, you can create a COM server with PB, too, but let's not make this too hard.) Looking through the menu, you find you can pick tempura, quesadillas, linguini, or whatever you want. But it has to be something on the menu. Ask the Pizza Hut object for sushi and you'll be disappointed with an error. You don't have to know anything about the raw ingredients or how to cook things when you are the client. So it's the same when you call Excel.Application or whatever through its interface.

A COM server makes you the chef. You get to decide what your clients may order. Because I hate mushrooms, I keep them off the menu and nobody can have them :laugh: But you'd better know how to cook (implement) every dish (interface) on the menu correctly or you'll get some unhappy clients (bug reports).

Perhaps you are trying to take on COM clients and servers in early and late binding all at once. If so, back off. Get comfortable with just being a client and using late binding only. Then go on to early binding. You can even skip COM servers entirely until once and if the need arises.

[Bob Zale]

Interesting, Michael. There's a handy-dude down the street from me with just that disposition. He wants to do just enough handy-work to pay the rent a month late, and to get a twelve-pack for tonight. {smile}

Of course, the truth is... the only way we can set ourselves apart from all the ordinary programmers is to make those small extra efforts. Learning about the tools at your disposal is one (of many) important factors.

Of course, I already know you understand that. But it never hurts to repeat it.

Best regards,

Bob Zale

[Chris Holbrook]

"I pass a reference to an object and when it is received it is a reference to an Interface!"
I really don't understand this. What makes you think that this item is a pointer to an interface?

because the function called describes it as "...AS <interfacename>"

Now, an Object Variable is declared as an Interface name. Very similar to the way a UDT variable is declared as a TYPE name.

No, not the same, because "An interface is not an object" - whereas a UDT is a Type!

My question, still there in post #1 - am I doing this right? Throwing an OBJECT and catching an INTERFACE?