I remember many years ago when I was learning Fortran, there was this ancient programmer in my shop who refused to use a compiler. Instead, he insisted on punching binary machine code on punched cards, because he wanted to stay close to the actual computer code and really know what was going on. I thought this was completely stupid, and vowed when I grew up, I would never become a programmer with that kind of attitude.

So here we are with OOP, and classes. And some of us want to be able to ‘see’ under the hood and know exactly what’s going on.. Doesn’t this defeat one of the big advantages of using classes (having reusable ‘black boxes’).

On the other hand, I know exactly what you mean, Arthur. Although I’ve only been programming in OOP-VFP for a few months, it has happened on more than one occasion, that the class I downloaded had a serious bug in it, and I had to get under the hood, figure out the problem, and correct it. And these classes were from ‘reputable sources.’

I think the difference between now and olden times is that then we could all trust the compiler not to be ‘buggy’. That is not as true now as it was then.

Let me end by saying that in my case, reading the code in a class is very helpful, and I’ve learned a lot of VFP by studying what my more experienced colleagues have done. However, as I get more experience, this utility will disappear, and I will begin to complain about lost productivity.


>It's not object orientation or class definitions upon class definitions upon class definitions that scare me. I like changing the properties of a low-level class and watching the characteristic of single dialog in the system change. What scares me is having to build a foundation upon something where I must work with a component when I do not know what's inside.
>
>There are people who are comfortable to have a wizard create a screen (form) for them. There are people who can live with entire program derived from templates. It drives me nuts. I don't want my program to function the way some nameless tycoon thinks it ought. I want to know what it's doing every step of the way. In fact, once I get a program working properly, I have been known to extract every since VCX and form into a class and put it in a program in the form of text so that I can see every single thing it does. I like to look at different versions of DLL's to see what functions they import and export. I'm not a control freak, honest I'm not.
>
>I'm like that TV show on Fox ... I trust no one. Especially nameless corporate interests.
>
>A week before ZDNet released information that a particular file sharing program installed a secondary program that allows a third party to gain access to your hard drive and CPU, I wrote a couple-page document for our receptionist that went all the way from explaining what's in a DLL to DLL sharing between programs and problems that can arise when some program you install puts a new DLL on your computer. I wanted to explain exactly why a user should not install untested applications. I wrote that, if you didn't write the program and don't know the person who did, you are in blind faith trusting that whatever you're installing will act in a respectable manner. I wrote that an unknown program, once running on your computer, could literally connect to the internet and do anything it wanted.
>
>It seems I was right.
>
>So, in defense of programmers who need know about every file in the program, I say I would rather deal with all that than have one file -- upon which my program relies -- for which I do not have the source code. It's hard enough for me to run Visual Foxpro itself with all the bugs that must lurk therein that I never know of. You can not have too many source code files.
>
>There is comfort in being able to look beneath the figurative bed.
>
>Ever seen the source code to an entire operating system? Looking at the code for Linux gives me an almost religious sense of reverence. And yes, if I REALLY wanted to, I can recompile the actual server OS. I think that's SOOOO COOL.
>
>Code is good.