>Hi Mike,
>
>>That's really too bad. Hiding complexity is always a good thing.
>
>
>Most of the time, I'd agree with this statement. In the realms of
>computer science and computer engineering, I'd have to say that
>I agree with this statement "sometimes."
>
>
>For instance, take a newbie CS/CE grad and ask him or her to write
>some hybrid code in C++ and assembly. Most "barely" understand
>what their C++ compiler is actually doing, much less the real
>underlying code. To take it a step further, ask them to use a
>disassembler to track down a problem in a program that is no
>longer supported (with no source), fix it, document the patch,
>and get the patched version working in a production environment
>"as soon as possible."
>
>
>These days, I'd say one in a thousand CS/CE grads could do
>this, mainly because universities are "putting the complicated
>stuff behind the scenes," hiding behind buzz words like Integrated
>Development Environments, Rapid Application Development, Object
>Oriented Programming, etc. "You guys don't need to understand it at
>that level" is a _common_ statement thrown around the geek world these
>days, and it's a damn shame.
>
>
>Anywho, Naomi, if you understand it at a lower level -- good for you!
>Kudos! You rock! Use it the way you understand it, and get that finer
>level of control...and flexibility, I might add.
>
>
>BTW, Mike. Nothing personal here, dude. It's just that I've been
>hearing IDE, RAD, easy this, and easy way that so often that it
>really irks me sometimes. In a lot of circumstances, what we're
>all doing here is not easy, in any way, shape, or form, and understanding
>VFP's nitty-gritty details and what's going on "under the hood" is
>not only a good thing, but a great thing. For those that understand
>it at that level, I commend you and tip my hat.

Nothing personal here either! :) OK, so tell me in exacting detail how the textbox class was coded.

Hiding complexity does not mean you make the code impossible to find. It means you make a chunk of code that does something complex into a unit.

You build a piece of code that is clear and you name it something clear. It does something complex like a spark plug, but you hide the complexity by calling it a spark plug and there after reusing it. That's how things are supposed to be built.

Where "hiding complexity" is bad is when code obscures the simple into ridiculously complex.

For example, I've inherited a program to print an employee pay stub. This code reads the employees records into one array, scans that array and builds two more arrays (for the left and right side of the sheet), then another array for a summary by category, then another array for non-billable and then a final array for all employees. The entire code is very difficult to trace.