PB-OOP : advantage and disadvantage

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
OOP-bloatware++.

Just say NO to bloatware!

Tim


------------------

[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>

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!
COM!
COBRA!
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).]

[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>

[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
in.

Just my opinion.

------------------
-Greg

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: ???



------------------

Hi programmers and PowerBasic support,

The OOP programming have more advantages then
stuctured programming

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

Disadvantages:
- OOP is to learn as pointers

Greetings,
stephane

------------------