My findings on PowerBasic OO

[Eric Pearson]

All I meant was "good luck using Word without using objects". Without the Component Object Model interface, or at least knowing a little bit about OOP.

Jeez Michael, I thought you'd applaud any analogy that mentions paintbrushes.

[Added] I wasn't aware of our friend Jose's work. I'll look at it, thanks.

[Michael Mattias]

I currently have a library I use to manage hierachical data using a 'tree' structure.

It is pretty much based on this UDT:

' TSIVTREE.INC
'  #INCLUDE version of Tree Management functions for use in EDI Pal
'  10.24.05  copied in needed functions only from test code and cleaned up
' [ more history omitted for space considerations]
...' ------------------------------------------
' UDT DESCRIBING EACH NODE OF THE TREE
' ------------------------------------------
TYPE vtNodeType
    Nodetype      AS LONG                   '  user-defined: e.g., file, XC, FG, Loop, Segment etc
    level         AS LONG                  '  level 0 = root (File) , 1 = XC, 2 = TA1 or FG
                                           '  this field is maintained by the tree software
                                           '  level is set when inserting nodes.
    EXPANDED       AS LONG                  ' true or false. User sets this.
    pParent        AS vtNodeType PTR          ' null = no parent (is root item)
    pFirstchild    AS vtNodeType PTR          ' first child
    pLastChild     AS vtNodeType PTR          ' last child of this node
    pNextsibling   AS vtNodeType PTR          ' next at same level  WITH COMMON PARENT
    pPriorsibling  AS vtNodeType PTR          ' prior at same level WITH COMMON PARENT
    pData          AS DWORD                 ' pointer to 'something' depending on node type;textptr, XC or FG, stuff like that
END TYPE                                    ' i.e., "user data"

The functions in the library are pretty much what you'd expect from something of this age: InsertNode, DeleteNode, and several forms of enumerating the data tree in different orders, with the programmer using all the pointers to figure out what is what.

As you'd expect from something written in PB in 2005, it's all procedural code.. and not all that 'intuitive' to follow.

However... one of the things which excited me about the most recent release of PB was the new "collection" object.

Seems to me I could offer this library with a COM interface ....

OBJECT 
    Sublevel 1 Collection
      items
        collection of sublevel 2 items 
         ......

.. and the data model would be pretty much as understandable as the ADO model for databases:

    Database
      Table(s) 
            Column(s)

.. except in my case I am mostly dealing with ANSI ASC X12 format data, which logically looks like:

FILE(s) 
  Interchange(s) 
     FunctionalGroup(s) 
         TransactionSet(s) 
            Segment(s) 
              element(s) 
                  subelement(s)

Where you see "(s)" it's either zero or one to many, depending on level.

I currently implement my EDI data handling using the "tree" model above; it's still not all that easy to understand unless you have condiderable experience with the model.

However, I think I just might be able to develop an API for EDI data using the "collection" object with a COM interface ... and I think this might be a heck of an interesting tool for niche-vertical market software developers who want to "EDI-Enable" their existing applications.

The user syntax to obtain an "element" (what you ultimately after) would be something like .....

    Value = File(I).Interchange(J.)FunctionalGroup(K).Transactionset(L).Segment(M).Element(N)

... which seems a lot simpler to me than calling an enumeration function and writing a callback procedure to find the same thing - which is what you have to do using my current tree library.

Not sure exactly how that fits this discussion, except to say that I can get to the same place multiple ways... and the user could pick his choice of techniques. Given where the software development industry is today , I'm currently of the belief an object-oriented/COM interface API could attract a lot more developer spending money than could a "flat" (STDCALL) procedural interface.

But I guess I won't know until I give it a shot, huh? Gotta love free market capitalism!

MCM

[Larry Charlton]

MCM, that's one thing I love about OO. It isn't that there is any problem in OO that can't be solved with procedural code or vice versa, but it is a great way to abstract a collection of functionality. Another is that if I encapsulate it well, I can write the quickest, crappiest, down-right offensivest code ever and know that it's all fixable later if I care.

The marketing stuff I have no idea except that if you try to pawn OO code to procedural programmers or procedural code to OO programmers it's likely to be an uphill battle.

[Michael Mattias]

This actually came up for me about six months ago. I mentioned to one user that I offered an "API" to do the same functions as the end-user product he had licensed, and since I was not going to tailor the product for him, perhaps he'd like to license the API and make whatever changes he wanted himself?

First thing out of his mouth in response was, "Hmmmm...maybe... can you send me some documentation showing the object model and the properties and methods you expose?"

MCM

[José Roca]

COM is a binary standard. It specifies the rules and the implementation is free. Classes are just a convenient way of doing it.

Compare the code in post #2 of this thread:

http://www.powerbasic.com/support/pbforums/showthread.php?t=48031

that uses a PB10 class, with the one in post #9 of this thread:

http://www.powerbasic.com/support/pbforums/showthread.php?t=24326

that does the same but using procedural code.

[Eric Pearson]

Hi José --

Nice work, I hadn't taken the time to look at that before and it has already taught me a few things. Thanks. Please excuse the basic questions; they come from ignorance not contrariness...

Doesn't that "procedural" code use Object Oriented Programming? It looks to me like you are providing Methods for an existing Object; instead of using METHOD MyOperation it uses CODEPTR(MyOperation). To me that seems like the difference between using CALL and CALL DWORD, i.e. not very much. No?

You're very good, but could you have written that code without understanding OOP?

-- Eric

[José Roca]

Hi José --

Nice work, I hadn't taken the time to look at that before and it has already taught me a few things. Thanks. Please excuse the basic questions; they come from ignorance not contrariness...

Doesn't that "procedural" code use Object Oriented Programming? It looks to me like you are providing Methods for an existing Object; instead of using METHOD MyOperation it uses CODEPTR(MyOperation). To me that seems like the difference between using CALL and CALL DWORD, i.e. not very much. No?

You're very good, but could you have written that code without understanding OOP?

-- Eric

It is a question of semantics. I'm using an array of pointers to callback functions. If you call the array an object and the callback functions methods, then you can say that it is OOP programming, but I prefer to call it low-level COM programming to no confuse matters. There are many important differences between COM and OOP as implemented in object oriented languages. For example, COM does not allow multiple inheritance, parametized constructors, overloaded methods, polymorphism, etc. All COM interfaces inherit ultimately from IUnknown, that implements reference counting and controls the life of the object , whereas OOP classes are created and destroyed with special purpose operators such new and delete. They can share some techniques, but are different programming paradigms.

[Michael Mattias]

To me that seems like the difference between using CALL and CALL DWORD, i.e. not very much. No?

This is the apples and oranges thing, or maybe the 'what' vs the 'how.'

In OOP, a property is a logical 'thing' ...

  Value = objectVar.PropertyName

That it might be (well, it IS) implemented as a 'call' to some particular piece of executable code is immaterial to the OOP programmer. The oop programmer knows it only as an "object property value'

A method is also a logical thing: but to the OOP programmer it's just "something you do to/with an object".... again, that it might be implemented as a 'call' is immaterial.

It's probably a lot easier for a new programmer to "think object" ... the rest of us still have a "call/procedural" model in our head - forming the basis of all our thinking.

It's not all that dissimilar from the change of thinking you had to undergo when you started writing Windows' GUI apps: from the MS-DOS procedural "ask if something happened and if so do something" model versus the Windows "I'll tell you when anything happens and you pick out those things of interest to you" model.

It's just a whole 'nother way to think about building an application program and managing its data.

MCM

[Larry Charlton]

There is nothing wrong with creating new properties/methods in a class as long as your ensure that they do not affect the functionality of any existing property/method..

I can't agree with Fred's earlier quote: "You can't tell whether a base-class change is safe simply by examining the base class's methods in isolation; you must look at (and test) all derived classes as well." unless the base-class is poorly implemented in the first place. If it is properly encapsulated, it doesn't matter how it is used in a derived class.

Here's maybe an example: Say you return the current date/time as a string. Let's say it's in the format mm/dd/yy hh:mm:ss.

If you decide that for many of your uses you'd like to change the format to mm/dd/yyyy hh:mm:ss, you can't know by just looking at the base class whether other users of the class are expecting that particular format and will break when you change the string format.

That's just an example and while it most definitely applies to classes it also applies to functions, libraries and more generally re-use of any kind.

The one change you can make safely always, are optimizations as long as the following are met. The change in no way references anything outside the class (doesn't call other classes, function, use outside resources such as web services, databases, files, etc), and in all cases returns exactly the same answer in the same format. Oddly this also applies to functions and sub-routines.

[Stuart McLachlan]

If you decide that for many of your uses you'd like to change the format to mm/dd/yyyy hh:mm:ss, you can't know by just looking at the base class whether other users of the class are expecting that particular format and will break when you change the string format.

That's just an example and while it most definitely applies to classes it also applies to functions, libraries and more generally re-use of any kind.

Anyone that makes that sort of change in an OOP Class or Procedural Function should be taken out and shot. Changing an output format in any sort of library is an absolute no-no.

That's why I said: as long as your ensure that they do not affect the functionality of any existing property/method.

[Fred Harris]

The one change you can make safely always, are optimizations as long as the following are met. The change in no way references anything outside the class (doesn't call other classes, function, use outside resources such as web services, databases, files, etc), and in all cases returns exactly the same answer in the same format. Oddly this also applies to functions and sub-routines.

There are more conditions than that. Any change in the number of base class instance variables will cause inheriting class code to fail that hasn't been compiled/linked against the new structure of the base class. That now, is the case with Non - COM C++ in situations where established client code is dependent on external Dlls. The reason for this is that the compiler needs knowledge of the sizes and locations of everything in base class code to compile the higher level classes that use that code.

Now, these sorts of restructurings within COM based components are possible and completely legal because client code has no knowledge whatsoever of the internal structure of the component it is using (its base class) in terms of any or how many instance variables it is using, or anything else. Its only connection to the server is a pointer to a pointer to a VTable. If the VTable structure is maintained, i.e., the interface, it doesn't make any difference to the client what changes are made within the server. The server could be completely rewritten, using ten times the number of instance variables, and everything would still work. That COM was designed this way, and that PowerBASIC has implemented COM and interface based OOP, is the reason that inheriting classes can't get at base class instance variables as if they were their own. It appears that the subtleties of this are such that many imbued with knowledge of the nature of classic OOP based implementation inheritance can't grasp it.

[Jim Fritts]

Updated links for Jose' Post #25
First
Second