No announcement yet.

PB-OOP : advantage and disadvantage

  • Filter
  • Time
  • Show
Clear All
new posts

  • Tim Wisseman
    Guest replied
    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!



    Leave a comment:

  • Eric Pearson
    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>

    Leave a comment:

  • Tim Wisseman
    Guest replied
    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).]

    Leave a comment:

  • Eric Pearson
    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>

    Leave a comment:

  • Gregery D Engle
    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.


    Leave a comment:

  • Tim Wisseman
    Guest replied
    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: ???


    Leave a comment:

  • stephane fonteyne
    Guest started a topic PB-OOP : advantage and disadvantage

    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