No announcement yet.

PB-OOP : advantage and disadvantage

  • Filter
  • Time
  • Show
Clear All
new posts

  • PB-OOP : advantage and disadvantage

    Hi programmers and PowerBasic support,

    The OOP programming have more advantages then
    stuctured programming

    - Data abstration
    - Encapsulation
    - To use again code
    - Extension program
    - Inheritance
    - Polymorfm
    - Updating en correcting code

    - OOP is to learn as pointers



  • #2
    What about the compiler?

    We have a 16 bit compiler that is very limited on how large a
    program you can compile before
    you have to break it up into a group of DLL files. When
    that happens you can no longer use Globals to share variables
    with the code in the DLL's. To share variables with
    the code in the DLL I have to resort to using tricks with
    pointers that make the code messy and added about 20% to the
    size of my programs. Adding OOP to the 16bit OOP compiler would
    make a bigger mess of things. It would even further limit how
    large of a program can be made before you have to break
    things up because the compiler has run out of memory, again.

    PB has issues that need to be addressed. Ever since the
    release of PBDLL 5.0 I have not been able to use arrays in a
    UDT in a large program without endless problems, crashes and
    data corruptions, because of a compiler issue. Register
    variables have issues.

    It bothers me that people are demanding more keywords added, OOP
    thrown into a 16 bit compiler that will just further limit how
    large a program it can compile and it also bothers me that
    it is taking so long before the current compiler issues are
    taken care of with a patch that fixes all known major issues.

    My goodness, the UDT array compiler issue (bug) is just a week
    away from being 3 years old (Compile date of PBDLL5.0).
    Whoo hooo! I think I will bake a cake and throw a birthday
    party for the little defect.

    Cramming OOP into a 16 bit compiler is just plain crazy. Do so
    while ignoring compiler issues is even worst.

    My suggestions are:

    PB7: First build a 32 bit compiler with all issues fixed.
    (I know, I know, you have millions of lines of asm code, it
    would be hard to do.)

    Next: Add a visual designer

    Next: ???



    • #3
      Granted OOP is a nice feature but it adds a lot of bloatware to
      any project. I believe that OOP adds more flexability to the
      language but sacrafices tons of overhead.

      Personally I hate programming in an OOP environment. Such as
      TestPoint which is 100% OOP, it is a 16bit circuit board
      language and it takes so long to just set up the classes and
      then when I want to build something on that I have to use
      classes for everything. It takes so much longer then normal.

      I do agree that OOP does take a different mindset then normal
      programming but I still don't grasp the advantages other
      then flexability with the code, and to be honest I don't see
      any flexability with the OOP environments that I've programmed

      Just my opinion.

      [email protected]


      • #4
        Sorry, Tim, but IMO several of your comments are out of line.

        > We have a 16 bit compiler that is very
        > limited on how large a program you can compile

        There is an issue with the amount of literal data that a program can currently contain, but as far as I know that's the only significant limitation. Is there something that I have not yet run across (or heard about)? I have made several large single-module programs with both PB/DLL and PB/CC, and I have never "hit the wall". IMO giving people (especially lurkers that have never used PB and may be considering it) the impression that the compilers are "very limited" is an exaggeration and IMO an unfair characterization.

        > Adding OOP to the 16bit OOP compiler
        > would (...) further limit how large of a
        > program can be made

        On what do you base that assumption?

        > the UDT array compiler issue (bug) is
        > just a week away from being 3 years old

        That's an interesting method of counting. If you discover a bug tomorrow, is it more urgent because the compiler is three years old? It may seem that way to you, if you are personally affected by it. PowerBASIC has repeately stated that they are aware of the UDT problem, that relatively few people are affected by it, and that it is slated to be addressed in the next update. I understand your impatience, but I don't think you see the big picture.

        Not only that, but my PBDLL.EXE and PBCC.EXE are date-stamped 6/1/99 and 7/1/99 respectively, which is around 15 months, not 3 years. Or does it still count as a 3-year-old bug, even though nobody discovered it while the previous version was being distributed? (And isn't that an indication of how many people have been affected by it?)

        > First build a 32 bit compiler with
        > all issues fixed.

        It's reasonable to assume that that's PowerBASIC's goal. But I'm not sure that fixing bugs and adding new features are mutually exclusive. To be blunt, what you seem to be saying is "fix the things that are important to me before you add features that other people want." I agree that known issues should be addressed, and I believe that they will be, but I think it is a mistake to assume that PB can't do both, or (especially) that people should refrain from making their wishes known until the current version is "perfect". Or to assume that adding new features to the compilers will degrade their performance.

        > ignoring compiler issues

        That's inflamatory, and an exaggeration. How many software companies do you know of that release a maintenance patch instantly, every time a bug is discovered?

        -- Eric

        Perfect Sync: Perfect Sync Development Tools
        Email: mailto:[email protected][email protected]</A>

        "Not my circus, not my monkeys."


        • #5
          I know how is this for an idea. . .

          We have PBDLL and PBCC, why not keep them pretty much the way
          they are. They do serve an import market left behind by VB.

          PowerBasic Inc could produce a new product:

          BloatBasic++ Version 12.0
          High version number means it is extra good!
          100% OOP!
          Massive Run Time Libraries!
          Supports BASIC, C++ and PASCAL Keywords!
          The compiler comes on a single CD ROM!
          Just like C++ Only with Basic Keywords!
          Pro'fish'ional and colorful IDE!
          Just like Visual Basic, only ahh. . . better?


          [This message has been edited by Tim Wisseman (edited September 24, 2000).]


          • #6
            Stephane --

            If a person knows what "Data abstration" and "Encapsulation" are, then they already know what OOP is, and they know what benefits would be provided, so seeing your list will not affect them.

            If a person does not know what those things are, then seeing your list will not affect them because they do not understand what you are saying. If you want to convince people that OOP is good, then you need to explain why. Just saying "Data abstration" and "Encapsulation" has no value.

            Repeating the same list in message after message is pointless, and will not accomplish what you are trying to accomplish. In fact it may have the opposite effect because some people are getting quite angry with you, and no longer take you seriously.

            -- Eric

            Perfect Sync: Perfect Sync Development Tools
            Email: mailto:[email protected][email protected]</A>

            "Not my circus, not my monkeys."


            • #7
              Eric, have you ever tryed to compile a source file of more than
              60,000 lines using PBDLL? I hit the 16 bit wall of memory
              somewhere between 45,000 and 55,000 lines of code.

              The UDT problem was effecting programs (other peoples) long
              before the problem was found. The nature of the problem was
              such that it was almost impossible to trace back to the UDT.
              A GPF that ramdomly hops from place to place in a program and
              then disappears completely when debug code is added to find it,
              this is not something that can be
              very easily traced back to an array in an UDT. Your gut
              tells you to trust the compiler and assume a programming
              error like a bad pointer or an array out of bounds.

              But you are correct, R&D knows about the problem and will fix
              it in due time.

              The first week that I got PBDLL 5.0 and ported a large program
              from VB to PB 5.0 I was hit by the UDT problem, That was back
              in 1997. So the UDT array issue is a very special "friend" of
              mine. I know, I know, most people do not use array's in UDT so
              it is unimportant to most programmers.

              I still say again, adding big new things to a 16 bit compiler
              like OOP while ignoring important compiler issues is madness!
              It is what some users are demanding, the users are demanding
              things that are crazy, not PB Inc.

              From what I have seen from PowerBasic INC, they will
              likely do the right thing, they have to date without fail.
              I hope they ignore 90% of the madness that has infected this
              forum and continue to do what they have done so well for so
              long. I am sure they will, as long as Bob is around.

              Great idea can fail, we all have to be careful. Adding arrays
              to UDT's seemed to sound like a good idea, but so far they have
              failed to work correctly. To me array's in UDT is
              pretty minor compared to full on 100% OOP. PB needs to at lease
              do a few simple tricks like correct use of register variables
              before it desides to jump off the OOP++ cliff. (I hope they
              do not do OOP.)

              If PowerBasic Inc releases a little patch before the summer
              of 2002 that just fixes the few issues that we have now, I
              will be very pleased and happy. It is a great compiler already.
              It is the best at what it does. They is nothing better around,
              if there were I would not be here.

              I "complain" because PB is my FAVORITE compiler, it needs
              a little help (I am sure it will get it, in due time).

              I would pay $500 for a compiler like PB, if I had
              to pay for a patch to PBDLL, I would buy it the instant
              it was possible.

              I just do not want to see it lost to worderful world of

              Just say NO to bloatware!