That certainly is an object. Well, it is to everyone who didn't attend 'Comp Sci: OOP and Pissing on people 101'. It may not meet your definition of an object, but Perl doesn't meet many peoples definition of an object orientated programming language either.

Why not pat someone on the back and say 'Yes. It is an example of code that encapsulates code and data into a uniform interface. And wait till perl 6, when it will have even more object properties to play with.'

Update: I really need to get more sleep before posting things like that. In fact, if I got more sleep I wouldn't post things like that. I'm sorry, ariel, for the rudeness.

However I do not think that 'patting someone on the back is rude' - it may just have different overtones depending on where somebody comes from. dragonchild clearly had a revelation on how to structure code well, so ++ for seeing it. Perl isn't more OO than C++ or Java but it does use some of the ideas of OO when dealing with data.

I guess I'm a little sensitive because I keep being cornered by people who prefer to talk it rather than do it (I'm not accusing you of this) and one of the favourite seems to be whether certain things are OO, functional or whatever.

I can recall having exactly the same thought as dragonchild and then thinking "oh, wait, can't inherit, can't add properties, damn". I was still quite proud of it though.

I think my next project may be a little proggie that monitors what I type and pops up and says "Do you really want to flame him? y/N?" whenever I lack the judgement.

____________________
Jeremy
I didn't believe in evil until I dated it.

OOP is about using objects, as well as adding objects. It's a paradigm shift, not just a few new keywords and syntax goodies. People were writing OO code before OO existed and people are writing procedural code with OO syntax.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I disagree that it's *just* about using objects. The distinction between typical programming that is common in C and FORTRAN, and true OOP, is that you don't think of the program as working step after step, but of objects invoking methods of other objects in a non-deterministic way.

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

First, in Win32, ints are 32 bits, not 16.

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