Announcement

Collapse
No announcement yet.

Oop 101?

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

  • #21
    More Thoughts On Object Oriented Programming

    I would like to take a shot at justifying Object Oriented Programming. But before I do I’d like to state beforhand that I’ve personally had a difficult time learning it and am in no way an expert at it. Also, as many here have stated at different times its no panacea to every possible programming challenge. Its just a useful and important tool. My reason for thinking that it is something important to learn is highly philosophical and is based on a linguistic principal first advocated by a very gifted linguist Edward Sapir. The idea is that the symbols we use to think and the meanings we attach to them largely if not completely condition the nature of what we are able to conceptualize with those symbols. In linguistics this is know as the Sapir-Whorf Hypothesis, and here is a link to further information on it…

    http://en.wikipedia.org/wiki/Whorf-Sapir_hypothesis

    Here is the first sentence or two from that article…

    "The hypothesis postulates that a particular language's nature influences the habitual thought of its speakers: that different language patterns yield different patterns of thought. This idea challenges the possibility of perfectly representing the world with language, because it implies that the mechanisms of any language condition the thoughts of its speaker community."

    It is my belief that this is largely true, and is the reason individuals from different cultures and times can have such widely varying world views and social philosophies. I also believe this idea is applicable in the realm of programming languages. I don’t believe I’ve ever seen a better description of this issue as it relates to computer languages as that from Bruce Eckel in his book “Thinking In C++”, second edition, Volume 1. This book is downloadable and free from his website at…

    http://www.janiry.com/bruce-eckel/

    In Mr. Eckel’s words…

    The genesis of the computer revolution was in a machine. The genesis of our programming languages thus tends to look like that machine.

    But computers are not so much machines as they are mind amplification tools (“bicycles for the mind,” as Steve Jobs is fond of saying) and a different kind of expressive medium. As a result, the tools are beginning to look less like machines and more like parts of our minds, and also like other expressive mediums such as writing, painting, sculpture, animation, and filmmaking. Object-oriented programming is part of this movement toward using the computer as an expressive medium……

    The progress of abstraction

    All programming languages provide abstractions. It can be argued that the complexity of the problems you’re able to solve is directly related to the kind and quality of abstraction. By “kind” I mean, “What is it that you are abstracting?” Assembly language is a small abstraction of the underlying machine. Many so-called “imperative” languages that followed (such as Fortran, BASIC, and C) were abstractions of assembly language. These languages are big improvements over assembly language, but their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists). The effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire “programming methods” industry.

    The alternative to modeling the machine is to model the problem you’re trying to solve. Early languages such as LISP and APL chose particular views of the world (“All problems are ultimately lists” or “All problems are algorithmic”). PROLOG casts all problems into chains of decisions. Languages have been created for constraint-based programming and for programming exclusively by manipulating graphical symbols. (The latter proved to be too restrictive.) Each of these approaches is a good solution to the particular class of problem they’re designed to solve, but when you step outside of that domain they become awkward.

    The object-oriented approach goes a step farther by providing tools for the programmer to represent elements in the problem space. This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as “objects.” (Of course, you will also need other objects that don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, you’re reading words that also express the problem. This is a more flexible and powerful language abstraction than what we’ve had before. Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run. There’s still a connection back to the computer, though. Each object looks quite a bit like a little computer; it has a state, and it has operations that you can ask it to perform. However, this doesn’t seem like such a bad analogy to objects in the real world; they all have characteristics and behaviors. …

    Bruce Eckel "Thinking In C++"


    To provide a concrete example to illustrate how the nature of the programming language affects our thought processes allow me to describe a basic forestry issue, and that is obtaining the expected board foot volume yield estimate from a standing tree. Over the years in forestry various workers have devised countless methodologies for making this estimate, but the one we’ll use is a formula developed by Dr. Harry Wiant while he was Professor of Forestry at West Virginia University. Below is a pure procedural approach using the Console Compiler.

    The nature of the problem is that to estimate the expected board foot volume yield of a tree (the amount of lumber that sawing it would produce), you need to know the diameter of the tree in inches at 4.5 feet above the ground as measured from the high side, and the merchantable height of the tree in feet. Merchantable height of sawtimber is usually to a eight or ten inch diameter top. Also, an estimate of the taper of the tree is necessary. Without going into all the details these are ratios usually expressed as intergers ranging from 75 to 85 – the higher the number the less taper. These ratios are know as a ‘Form Class’.

    Below is a procedural approach to the problem. First one would create a TYPE to contain the diameter, height, and form class. Then one would create a function where one would implement some volume determination method involving a formula or whatever. In the below example you can see Dr. Wiant’s rather complex result from his regression analysis. The function should take a parameter of the TYPE created to contain the tree’s diameter, height, and form class. The function should crunch the numbers contained in the TYPE parameter and return the tree’s expected board foot volume estimate.

    Code:
      
    #Compile Exe
    #Dim All
    
    Type Bole
      Dbh As Single
      Height As Single
      FormClass As Long
    End Type
    
    
    Function BoardFootVolume(Tree As Bole) As Single
      BoardFootVolume = _
      ( _
        (1.52968 * (Tree.Height / 16) ^ 2 + 9.58615 * (Tree.Height / 16) - 13.35212) + _
        (1.7962 - 0.27465 * (Tree.Height / 16) ^ 2 - 2.59995 * (Tree.Height / 16)) * Tree.Dbh + _
        (0.04482 - 0.00961 * (Tree.Height / 16) ^ 2 + 0.45997 * (Tree.Height / 16)) * Tree.Dbh ^ 2 _
      ) * _
      ((Tree.FormClass - 78) * 0.03 + 1)
    End Function
    
    
    Function PBMain() As Long
      Local t As Bole
    
      t.Dbh=16.0
      t.Height=32.0
      t.FormClass=78
      Print "A 16 In. Tree With A Sawlog Ht of 32 ft Contains " BoardFootVolume(t) " Board Feet of Lumber."
      Waitkey$
    
      PBMain=0
    End Function
    As can be seen in the above procedural program, a variable of TYPE Bole was created in PBMain to hold the tree’s diameter, height, and taper data parameters. The function BoardFootVolume() can be passed a Bole argument containing the tree’s data and it will ‘crunch’ this data with its code and return a volume result to PBMain().

    Below is an OOP implementation of the above program using PowerBASIC 5.0 and objects.

    Code:
    #Compile Exe
    #Dim All
    
    Class Tree
      Instance m_Dbh        As Single  'Diameter @ Breast Height; standardized as US 4.5 ft.
      Instance m_Height     As Single  'In Eastern US in Units of 16 ft. saw logs - 32 ft. in Western US.
      Instance m_FormClass  As Long    'Integer representing a tree taper factor. Ranges from 75 to 85.
    
      Interface ITree : Inherit IUnknown
        Property Get Dbh() As Single
          Property=m_Dbh
        End Property
    
        Property Set Dbh(Byval sngDbh As Single)
          m_Dbh=sngDbh
        End Property
        
        Property Get Height() As Single
          Property=m_Height
        End Property
    
        Property Set Height(Byval sngHeight As Single)
          m_Height=sngHeight
        End Property
    
        Property Get FormClass() As Long
          Property=m_FormClass
        End Property
    
        Property Set FormClass(Byval iFormClass As Long)
          m_FormClass=iFormClass
        End Property
                      
        Method BoardFootVolume() As Single
          Method= _
          ( _
            (1.52968 * (m_Height / 16) ^ 2 + 9.58615 * (m_Height / 16) - 13.35212) + _
            (1.7962 - 0.27465 * (m_Height / 16) ^ 2 - 2.59995 * (m_Height / 16)) * m_Dbh + _
            (0.04482 - 0.00961 * (m_Height / 16) ^ 2 + 0.45997 * (m_Height / 16)) * m_Dbh ^ 2 _
          ) * _
          ((m_FormClass - 78) * 0.03 + 1)
        End Method
      End Interface
    End Class
    
    
    Function PBMain() As Long
      Local t As ITree
    
      Let t = Class "Tree"
      t.Dbh=16.0
      t.Height=32.0
      t.FormClass=78
      Print "A 16 Inch Two Log Tree of Form Class 78 Contains " t.BoardFootVolume " Board Feet of Lumber."
      Waitkey$
        
      PBMain=0
    End Function
    It certainly is longer but a description of how it works is much simpler. All you do is create an object of Class Tree, let it know the diameter, height, and taper of the tree, and request of the Tree its volume. Note the subtle change in emphasis – before we were passing a piece of data to an external function whose only relation to the tree bole in PBMain() was through a common function parameter, and now we have a tree of class “Tree” and simply ask it for its volume. It’s a subtle change in emphasis but it makes it easier for us to think about tree objects from an algorithmic perspective. And if we can think about it clearer and more easily, it will be easier for us to conceptualize various algorithims that may be used in our programs dealing with trees. In your programming life have you not ever run into a situation where you were struggling with a few variables to get an algorithim working, and just by renaming a variable or creating an extra intermediate variable allowed yourself to think clearer about what you were struggling with and thereby effect an easy and maintainable solution? That’s all we’re talking about here in terms of the benefits of object oriented programming – different symbols defined in such a way that we are better able to make the mental mapping from the ‘problem space’ to the ‘solution space’ of Mr. Eckel’s terminology.

    One more quick issue I’d like to discuss. Up to now the big dichotomy within the PowerBASIC user base is that between DDT verses SDK. It strikes me that OOP in PowerBASIC leaves the avenue open for OOP implementations within these two different camps. I’d personally like to experiment a bit with encapsulating such Api ‘objects’ such as textboxes, labels, combo/listboxes into OOP classes. That could prove really interesting. Having implemented something like that, and given the skill & enterprise of the different GUI Designer programmers in the PowerBASIC Community, it wouldn’t be too long until one would have something like Visual Basic but with much more speed and a fraction of the bloat. I think it’s a good time to be a PowerBASIC programmer!
    Fred
    "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

    Comment


    • #22
      It certainly is longer but a description of how it works is much simpler.
      What??? Wow. I guess it is all in the eye of the beholder. To me, the OOP example is far more difficult to see how it works.

      In the procedural function, you have a single line that does the calculations. In OOP, you have no less than 6 coding blocks to do the same thing. How can that be easier to follow?

      Again though, it all boils down to what one is comfortable with. The debate on which is better will never be solved because there isn't a definitive yard stick common to all ways of thinking in order to draw a conclusion from. Personal preference seems to be the defining issue.
      Software makes Hardware Happen

      Comment


      • #23
        Fred,
        You convinced me good stuff.. Oh yeah I'm a bigger advocate than you.

        One more quick issue I’d like to discuss. Up to now the big dichotomy within the PowerBASIC user base is that between DDT verses SDK. It strikes me that OOP in PowerBASIC leaves the avenue open for OOP implementations within these two different camps. I’d personally like to experiment a bit with encapsulating such Api ‘objects’ such as textboxes, labels, combo/listboxes into OOP classes. That could prove really interesting. Having implemented something like that, and given the skill & enterprise of the different GUI Designer programmers in the PowerBASIC Community, it wouldn’t be too long until one would have something like Visual Basic but with much more speed and a fraction of the bloat. I think it’s a good time to be a PowerBASIC programmer!
        I've been working with this for some time and the big gotcha is no callbacks within a class. It's not a PB thing, C++ has some real ugly code to handle it and mine is a little better but .....

        I will probably post the code just so the non-believers can scorn and belittle me

        James

        Comment


        • #24
          As a moderately skilled Java programmer, perhaps I can offer a few insights.

          When writing a small project just for myself in Java, I have kind of the same "What the heck do I need all this for" feeling others have expressed. Most of my own projects end up just being one class, and a handfull of methods; nothing you couldn't do with PBMain() and a few functions.

          When I was coding Java at work, the scale of the projects were much different. The project, overall, was to move from a CICS environment to a completely browser-based environment. And not just migrate, but, as the motto went, "Don't just move, improve." Lots of programmers and analysts on this one.

          Work was passed out to individuals more or less as: Please write a class named XYZ, with the attributes of String V1, intergers V2 and V3; methods to get and set those attributes, and the following methods; (description of method names, input and return parameter types.) And then you were free to work on your code as you liked (within reasonable guidelines.) All you'd need to know to use someone else's classes were the method names and the parameter information.

          A good specific example of how objects made our project more efficient would be The Database Connection Pool. To submit some SQL to the mainframe you need to create a connection (TCP connection to the right port on the mainframe) identify yourself with userid and password, wait for verification of id, send the SQL string, receive back the result set, and close the connection. The slowest parts of this chain by far is the establishment of the connection and the verification of the user. For a server that's going to the database a few hundred times a minute it adds up.

          The way we handled it was when the system was initializing we'd create an instance of ConnectionPoolManager. This class would create and maintain about 10 permanant database connection objects. As each application program needed a connection, it would request one from the Pool Manager. Either a connection was loaned out, or a status flag was sent that said none were available. If none available we'd usually just pause for .5 sec and try again; 20 fails before the user gets a note. It was incumbent on the application program to use the connection and return it promptly when finished.

          Not to say OOP can't benefit small projects, but I see it helping most with large ones.
          The boy just ain't right.

          Comment


          • #25
            A couple I like ...

            David A. Taylor : Object Oriented Technology : A Manager's Guide.
            David A. Taylor : Business Engineering with Object Technology.

            Very high level, no code here, but I think he makes a lot of things clearer. Have faith, OOP has some nice advantages, and can integrate well with the procedural programming you know. I have really come to enjoy thinking in objects.

            Chuck

            Comment


            • #26
              Joseph,

              Not to keep picking on this, but nobody has yet to answer my primary question about OOP. Take your "large project". What if each programmer were give the same requirements. Could they not have just as easily compiled their section into a DLL and said "here, these are the parameters you pass to this specific function to get your return value." And, as for the example of creating a pool of database connections, could not the same program been done with procedural code as well? What does OOP have to do with the design of the solution here?

              I can hear people complaining that they don't want a dozen+ DLL files. Ok, I can appreciate that, but the source code for the DLL would be identical if it were in an ".inc" file as well as the ".dll" format, so the final project could have still been compiled as a single application (if that were a requirement\benefit), no?

              I'm really having a hard time seeing the difference between saying "this is the name of the CLASS, and these are the parameters you pass it" as opposed to "This is the name of the FUNCTION and these are the parameters you pass it".

              Am I the only one who doesn't see a big difference here?
              Software makes Hardware Happen

              Comment


              • #27
                OOP And Program Architecture

                Hi Jim!

                In terms of your comment regarding no callbacks in classes...

                I've been working with this for some time and the big gotcha is no callbacks within a class. It's not a PB thing, C++ has some real ugly code to handle it and mine is a little better but .....

                I will probably post the code just so the non-believers can scorn and belittle me
                I really wasn't thinking in terms of callbacks in classes, as the last thing I'm interested in is something like Microsoft's MFC (Microsoft Foundation Classes). What I was thinking of is much more modest, and is simply to wrap some of the common control creation code so as to avoid Api calls such as Get/SetWindowText(), CreateWindowEx(%Ex_CLIENT_EDGE, "edit","".....
                etc. My main problem with MFC is its fundamental design philosophy is to completely hide the Windows Api architecture due to its being evil. I like the Api and the Sdk design of coding with WinMain(), the Window Procedure, etc. All I'd like to accomplish is the simplification of some of the more routine stuff into some classes so as to avoid having to constantly be scouring Api reference material for SendMessage() parameter & equate info, for example. I think its doable, but just havn't gotten to looking at it yet.

                Fred
                Fred
                "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

                Comment


                • #28
                  Originally posted by Fred Harris View Post
                  The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists).
                  It seems to me that this statement makes a case for procedural languages as well as it makes a case for OOP. Procedural programmers get to create a custom abastraction layer that's appropriate for that particular job.

                  You can build a pre-fab house far faster and for less money than you can build a house from scratch. Which house do you want to live in?

                  Barry

                  Comment


                  • #29
                    A lot of the OOP positions here obscure what many will see as the added benefits of the improvements in COM so we can now use direct interface methods with existing application ... not to mention those we grow ourselves. In doing some comparisons converting some C++ code to work with a graphics engine, the PB resulting .exe executes faster than the compiled C++ by around 8% on a very,very slow shared memory Radeon GPU in a laptop.

                    So while primary benefit of the COM expansion plus extensions appears specifically directed to those who would be OOP developer candidates, a significant portion applies equally to those of us who will need to interface to COM compatible EXE/DLL/OCX apps and libs ... but do not want to roll our own.

                    What Fred,James and others have done is to begin adding some flavor and color to possible COM/OOP uses for the newer version of PB. In other words making code pictures worth many more words ... so those who learn from examples can perceive what benefits there may be for our own use. What is apparent is that this is a blockbuster release which will take some users much more time than others to perceive.

                    Thanks for that.
                    Rick Angell

                    Comment


                    • #30
                      Originally posted by Joe Byrne View Post
                      I can hear people complaining that they don't want a dozen+ DLL files. Ok, I can appreciate that, but the source code for the DLL would be identical if it were in an ".inc" file as well as the ".dll" format, so the final project could have still been compiled as a single application (if that were a requirement\benefit), no?

                      I'm really having a hard time seeing the difference between saying "this is the name of the CLASS, and these are the parameters you pass it" as opposed to "This is the name of the FUNCTION and these are the parameters you pass it".

                      Am I the only one who doesn't see a big difference here?
                      All valid points.

                      If I may be given a lot of leeway here, and speak is Java-ish terms... A Class is something like a blueprint to build a new object. We could have a class called DB2Connection. It will have attribute descriptions (variables) and methods (functions). But generally (no quibbling now) it's not ready to go. An object of the type needs to be created which will have its own address in memory, and its own copy of the variables. The code for the methods resides in the classs description, so it isn't unnecessarily recopied. When you have created a new DB2Connection object, and have had it attach to the mainframe and identify itself, is a unique entity. Suppose we had written: cnx1 = new DB2Connection Then the variable cnx1 points to OUR connection object and no one else can see it or use it unless we share that address; no one could sneak in and say "delete * from *" under your login.

                      This would be different than a function that was shared by all threads and did not contain individual data. This could be roughly replicated by defining a UDT and passing it in and out of funtions byref to simulate individual instance data.

                      It's not strictly necessary, but it's just one different way to do it.
                      The boy just ain't right.

                      Comment


                      • #31
                        You can build a pre-fab house far faster and for less money than you can build a house
                        from scratch. Which house do you want to live in?
                        I would rather live in the one more energy efficient. If I were to buy it, I would prefer one with quality construction and better materials. Prefab can mean many things. Much of a home can be built in a factory with better quality control and assembled in the field. The materials used in the factory can have the same or better quality than a stick built house.

                        I don't know if many have visited construction sites lately, but in tract homes the quality is not that great, and if they can hide it gets install whether broken or flawed materials.

                        Comment


                        • #32
                          It's not strictly necessary, but it's just one different way to do it.
                          Very well stated, and I believe is the crux of the matter. OOP, especially OOP in PB offers another way to skin the proverbial cat. I don't think anyone can make a case that its better, or worse, than procedural code, just different.

                          I don't have an inherent problem with OOP, but there are some (not many in this forum) who tout it as the 'only real way to program. I highly disagree with that outlook. I can see where its necessary when you have to communicate with 3rd party applications and tools as well.

                          But my bottom line is that I hope all the other great features of PB9 are not lost by all the talk of OOP.
                          Software makes Hardware Happen

                          Comment


                          • #33
                            Not to keep picking on this, but nobody has yet to answer my primary question about OOP. Take your "large project". What if each programmer were give the same requirements. Could they not have just as easily compiled their section into a DLL and said "here, these are the parameters you pass to this specific function to get your return value." And, as for the example of creating a pool of database connections, could not the same program been done with procedural code as well? What does OOP have to do with the design of the solution here?

                            I can hear people complaining that they don't want a dozen+ DLL files. Ok, I can appreciate that, but the source code for the DLL would be identical if it were in an ".inc" file as well as the ".dll" format, so the final project could have still been compiled as a single application (if that were a requirement\benefit), no?

                            I'm really having a hard time seeing the difference between saying "this is the name of the CLASS, and these are the parameters you pass it" as opposed to "This is the name of the FUNCTION and these are the parameters you pass it".

                            Am I the only one who doesn't see a big difference here?
                            All valid points, Because with few exceptions, I have always found "What thall shalt write in OOP, thall Shalt be able to write procedural"

                            Case in point, my statement about the Serial Port.....Sure I could either include different copies of the same DLL (Each just renamed as Serial Port 1, Serial Port 2, etc....and calling functions in each separate DLL, to keep things apart in the parent program. OR I could do the same with several INC files with the functions named slightly different), OR What I hope to prove once my copy of PB9 comes in, I can build a class object, and cut the code down to 1 template, and many copies sort of thinking

                            Thats the way I think of OOP as....1 Template.....Many Copies

                            Maybe a bad analogy, but its the most simple explanation of OOP as I can see it.
                            Engineer's Motto: If it aint broke take it apart and fix it

                            "If at 1st you don't succeed... call it version 1.0"

                            "Half of Programming is coding"....."The other 90% is DEBUGGING"

                            "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                            Comment


                            • #34
                              Originally posted by Cliff Nichols View Post
                              Thats the way I think of OOP as....1 Template.....Many Copies

                              Maybe a bad analogy, but its the most simple explanation of OOP as I can see it.
                              As far as OOP goes that's a great analogy. At it's most basic think of a class as a TYPE.

                              Now allow the TYPE to include functions. And these functions work on the data present in that type.

                              So far, not really any different from any non-OOP program, except that the TYPEs can't include functions (though you can have a code pointer which is similar).

                              Where things can become easier to read is when you start overriding various functions such as stdin, stdout, +, ++, etc.

                              As an example if I need complex math (because I'm working with circuits) I can override the "+" operator. Now (in pseudocode-ish style):
                              Code:
                              TYPE ImaginaryNum
                                 DIM realpart AS LONG
                                 DIM imgpart AS LONG
                              END TYPE
                              
                              FUNCTION AddImagNums( x AS ImaginaryNum, y AS ImaginaryNum) AS ImaginaryNum
                                 DIM Ret_var AS ImaginaryNum
                                 Ret_var.realpart = x.realpart + y.realpart
                                 Ret_var.imgpart = x.imgpart y.imgpart
                                 RETURN Ret_var
                              END FUNCTION
                              
                              FUNCTION PBMAIN () AS LONG
                              
                                 DIM avar AS ImaginaryNum
                                 DIM bvar AS ImaginaryNum
                                 DIM cvar AS ImaginaryNum
                              
                                 avar.realpart = 10
                                 bvar.realpart = 20
                              
                                 avar.imgpart = 5
                                 bvar.imgpart = 50
                              
                                 cvar = AddImagNums(avar, bvar)
                              
                              END FUNCTION
                              With classes most of the program remains the same. Replace the word "TYPE" and have the function now be part of the class so the resulting program (skipping the declarations) is:

                              Code:
                              FUNCTION PBMAIN () AS LONG
                              
                                 DIM avar AS ImaginaryNum
                                 DIM bvar AS ImaginaryNum
                                 DIM cvar AS ImaginaryNum
                              
                                 avar.realpart = 10
                                 bvar.realpart = 20
                              
                                 avar.imgpart = 5
                                 bvar.imgpart = 50
                              
                                 cvar = avar + bvar
                              
                              END FUNCTION
                              By overriding the "+" operator we still call the same function, we just use a more "natural" language.

                              From a program design point of view, the real shift is that you use a "data centric" viewpoint rather than process centric. What data do I have to track and what do I have to do with it. THEN how does the process work.

                              So if I was designing a process control system or simulation I might write a "base" class for a pump. And it would have functions designed for everything that a pump can do. Then I would create other classes which inherit the base class for the different types of pumps that would be available. And in those classes I might have to rewrite the functions I already have (different equations for different pumps say). BUT, because they're in a child class the function name would be the same.

                              Now you may say why can't I just create different types, etc? You can. Where this becomes useful is that i can write a function that takes a variable of type "pump" as an argument and it will work with ANY variable that inherits from the "pump" class. No matter how far removed.

                              So if the base class has 10 variables and a "child" class has 20 variables I can still pass the 2nd variable to a function that will accept the first and work with it just fine.

                              Overriding class functions is kinda like changing the CSS style sheets on a web page. With the same HTML you can make the page look completelty different.

                              Did this help? Or did I just confuse you more?

                              John
                              John,
                              --------------------------------
                              John Strasser
                              Phone: 480 - 273 - 8798

                              Comment


                              • #35
                                Originally posted by John Strasser View Post
                                At it's most basic think of a class as a TYPE.
                                I like the idea of extending struct to include code, calling it class of course. I did use that a little in C when I was using a C++ compiler. It was still procedural.

                                I've done the same thing using different syntax, way before the days of C++, in C and even in ASM. I suspect most programmers have. I had libraries of modules I used all the time, mostly code, but a lot of them had their own data. OOP provides a way to formalize that but it isn't new.

                                From what I've seen, and I don't know enough about OOP to be real confident of this, it seems that the only really new thing is the multiple inheritance or overloading, that lets the programmer using the objects ignore the type of data being fed to the objects. Maybe this is because most of my programming hasn't been in large projects but I don't really feel any need for that. I've sometimes mixed up my types as I code but not usually. It wasn't a big enough problem that it needed a big solution.

                                Barry

                                Comment


                                • #36
                                  Many members here have mentioned the idea of including code in a type, and, I might say - in a favorable way.

                                  Think back for just a second to the mid eighties or so when GWBASIC and such variants were in vogue. At that time we didn't even have TYPEs! Sure, you could create as many integers, singles, doubles as you wanted (within severe memory constraints, to be sure), but we all know how limited and poorly organized those programs were - the key point in the aformentioned being poorly organized.

                                  When TYPE variables were created in our favorite environment of the time be it TurboBasic, QuickBasic or whatever we were better able to organize our code, and our programs improved due to the amalgamation of related variables into a single TYPE.

                                  Now we have been given a new and improved version of the TYPE with greatly extended capabilities. And I have not heard one person yet state that the TYPE has been ruined by the inclusion of the ability to include functions within a TYPE. Everybody seems to be OK with that. Its just a continuation of the better organization principal as was the case when the TYPE was initially created. Data, and now the functions that specifically work with that data, are naturally and organically within the same enhanced TYPE, instead of scattered about various source code files.

                                  So, if the term OOP carries with it negative connotations for you, then don't use the term. Just use the new enhanced TYPE which we are now calling a 'Class' to better organize your programs. If over the years you came to appreciate the inclusion of the TYPE in BASIC, then by the same logic you should love the class!
                                  Fred
                                  "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

                                  Comment


                                  • #37
                                    I can't speak for how PB is doing this yet, but in Java and C++, overloading mainly refers to adding a fucntionality to an existing operation or method.

                                    For a concrete example, suppose you have need to write an isPrime() fuction that takes a long and returns a long. No problem.

                                    But then the project gets bigger and you need to know if a quad is a prime or not. At this point, without overloading, a new function called isPrimeQ() or such need to be written to take a quad input and return a long.

                                    With Java style overloading, you'd just write them as:
                                    Function isPrime(x as long) as long
                                    ...

                                    Function isPrime(x as quad) as long
                                    ...

                                    The right one would be selected at run time based on the "signature" of the parameter list. If it pleased you, you could write one that took a String as a parameter; in your function you'd have to convert it to numeric, but that's why there are different functions for different data types.

                                    Operators can also be overloaded, but this is more of a C++ thing, and honestly, outside my direct experience.
                                    The boy just ain't right.

                                    Comment


                                    • #38
                                      An old post of mine that might shed some light for you

                                      Hi Mark

                                      Many years ago, I wrote a post that you might find useful, where I basically added some courseware that I had developed. The syntax is actually VB, but the concepts and benefits should still be clear and applicable to the new PB with Objects.

                                      See if that answers your question.

                                      Here is the link:

                                      /support/pbforums/showpost.php?p=138792&postcount=4

                                      -- Jim

                                      www.jimako.com/blog

                                      Comment


                                      • #39
                                        With Java style overloading, you'd just write them as:
                                        Code:
                                        Function isPrime(x as long) as long
                                        ...
                                        Function isPrime(x as quad) as long
                                        ...
                                        The right one would be selected at run time based on the "signature" of the parameter list
                                        Could't you accomplish this with one function which takes a VARIANT parameter, querying the actual type of data with the VARIANTVT() function and coding accordingly?

                                        MCM
                                        Michael Mattias
                                        Tal Systems (retired)
                                        Port Washington WI USA
                                        [email protected]
                                        http://www.talsystems.com

                                        Comment


                                        • #40
                                          Or you can use

                                          Code:
                                          Function isPrime(BYVAL x as ext) as long
                                          that will accept any numeric variable. But I guess that it is too easy.
                                          Forum: http://www.jose.it-berater.org/smfforum/index.php

                                          Comment

                                          Working...
                                          X