Announcement

Collapse
No announcement yet.

My findings on PowerBasic OO

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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.
    Last edited by Eric Pearson; 13 Jan 2012, 12:14 PM.
    "Not my circus, not my monkeys."

    Comment


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

      It is pretty much based on this UDT:
      Code:
      ' 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 ....

      Code:
      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:
      Code:
          Database
            Table(s) 
                  Column(s)
      .. except in my case I am mostly dealing with ANSI ASC X12 format data, which logically looks like:
      Code:
      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 .....
      Code:
          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
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #23
        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.
        LarryC
        Website
        Sometimes life's a dream, sometimes it's a scream

        Comment


        • #24
          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
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #25
            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:



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

            PowerBASIC and related source code. Please do not post questions or discussions, just source code.


            that does the same but using procedural code.
            Forum: http://www.jose.it-berater.org/smfforum/index.php

            Comment


            • #26
              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
              "Not my circus, not my monkeys."

              Comment


              • #27
                Originally posted by Eric Pearson View Post
                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.
                Forum: http://www.jose.it-berater.org/smfforum/index.php

                Comment


                • #28
                  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' ...
                  Code:
                    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
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #29
                    Originally posted by Stuart McLachlan View Post
                    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.
                    LarryC
                    Website
                    Sometimes life's a dream, sometimes it's a scream

                    Comment


                    • #30
                      Originally posted by Larry Charlton View Post
                      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.

                      Comment


                      • #31
                        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.
                        Last edited by Fred Harris; 21 Jan 2012, 01:03 PM.
                        Fred
                        "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

                        Comment


                        • #32
                          Updated links for Jose' Post #25
                          First
                          Second

                          Comment

                          Working...
                          X