It's very easy to convert a C program that doesn't use objects to one that uses them, but if there is still a strong dependence on how the events of the program should fire, it's not OOP.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important

Second, if you were to use integers in Perl 5, you would indeed care how many bits it had. When using the normal floating point values in Perl, you care about its range and precision. If you demand too much precision in a real number, your arithmetic fails. If you demand too many bits in an integer, you also get the wrong answer. That's no different than when programming in C.

If Perl 6 provides seemless bignums, then you won't have that problem. But you still "care". You rely on the fact that ints grow to any number of bits.

In Perl you have IV's and lots of stuff behind the scenes. But in C, you don't care how an int is implemented, either! You know that adding two ints obeys the rules of arithmetic, but what registers are used, how the CPU's ALU is constructed, what the pipelines do, and all that is something you don't care about. It just magically works that 5+4 produces 9.

—John

I know this may seem a bit offtopic, but man, perl 6 will kick major ass if it provides seemless support for bignums. I'll be changing a lot of the things I do in matlab and C++ to perl if it does.

Just Another Perl Backpacker

See RFC 43 for the proposal. This one appears to be accepted for Perl 6.

—John