Re: [Re: RPGILE V4.3 Gotcha]

[boldt@xxxxxxxxxx]

Hi Jim!

Although the discussion on decimal precision has run it's course,
the discussion has taken us to some other interesting topics.

Jim wrote:
>Of course I know OOP.  I picked it up at the last company I worked at
>where they used Delphi.  They didn't use OOPs too much, but I started
>looking at it, bought the compiler at home and read the manuals.  Then
>I wrote a few programs, logged onto Delphi news groups, downloaded
>OPPs (Other People's Programs) and looked at them, etc...
>
>And then I looked at OOPs in C and VBasic and, know what?  They
>worked just about the same way.
>...
>Oh yes,  I definitely felt like a complete idiot with OOPs, Pascal in
>Delphi was no problem, but the OOPs had me scratching my head,
>because I had never seen it before.  I say if you don't learn something
>new every day, it was a wasted day.

Have you tried C++?  Or Java?  (From your comments, I take it you
haven't done any OOP in Perl.)  All of these OO languages approach
things slightly differently.  Java and Perl take care of memory
management for you, but in C++, you have to manage memory yourself.
Developing GUI interfaces in Java requires extensive use of
inheritance, whereas Perl experts tend to recommend other styles
of OO app design.  Java uses single inheritance, C++ and Perl allow
multiple inheritance.  All of these factors affect application
design in fundamental ways, making it difficult to transfer skills
from one OO language to another.

There's a lot to OO, and I'm still picking up things myself.
Yesterday, I thought I understood OO, but then I read a section in
the book "Advanced Perl Programming", and now I wonder what I know!

That section in that book illustrates the potential for overuse of
inheritance.  For example, many OO texts use the example of
employees in a company.  Using inheritance, you could design a base
class called Employee.  You could then have derived classes called
Manager and VicePresident, such that a Manager "is a" Employee, and
a VicePresident "is a" Manager.  But what happens when an employee
is promoted?  In this case, a better design would use "has a"
relationships.  For example, an Employee "has a" Role, which could
be regular employee, manager, or vice-president.  To promote an
employee, simply assign a new Role to her.


>Actually, I once bought a book on compiler design to do just that, but the
>book was so full of gobblygook I couldn't' understand a word it was saying.
>I don't know if the book was just written horribly or I don't know enough
>higher mathematics to understand it.

Don't feel bad - the book probably was gobblygook!

As some readers here know, I took over development of expressions
in the RPG IV compiler from two other developers.  They were
running late in their schedule when they scrapped the existing
code and wrote a new expression parser, which they were very proud
of.  When I looked at the code, I was shocked to find the most
disgusting piece of junk I'd ever seen!  I first thought there was
no way it could work, it just looked so bad.  Hard to understand,
which meant that it would be a real pain to maintain and enhance.
When I challenged them on the code, they said they got the
algorithm from a book!

IMHO, most books on compiler writing are just too academic with
too little practical information.  Don't worry about LR parsers,
even though they're supposed to be more efficient - they can be
too difficult to understand.  I lean towards the top-down approach,
typified by the recursive-descent style.  For a reasonably
understandable discussion on compilers, look at the last chapter of
"Algorithms + Data Structures = Programs" by Niklaus Wirth, one of
the classics of CompSci (but now, unfortunately, out of print - I
still occasionally refer to it).  Once you understand the
recursive-descent technique, you can apply that understanding to a
more practical, table-driven approach, like we use in the RPG IV
compiler.

Here's what we do:  We use a simple language with operations
geared towards parsing, such as MATCH, CHOOSE, EMIT, ERROR, etc.
The syntax is first drawn using syntax charts (AKA railroad
diagrams).  The syntax productions are then coded using the
parser instructions, and the parse tables are generated from
that code.  The parser operations are performed by a simple
virtual machine which executes the parser instructions.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---