preferred/standard object implementations?

[dshahin]

As a recent convert to the world of OO-Perl, I've been doing a lot of reading into how other languages do it (java, python etc.) It seems that the major perceived weakness in Perl's object model is also perceived as a strength: flexibility.

I've been writing a module that inherits from Net::Telnet::Cisco and in doing so, I found I had no choice but to dig into the ancestral modules to determine how the author had implemented mechanisms for private variables and inheritance that are taken for granted in more strict OO languages

Bearing all this in mind, it made me realize that if the development group I'm in wants to start implementing our product as OO-modules, it would behoove us to pick some standards for inheritance and encapsulation. The Class::Struct and Class::MethodMaker modules are very appealing for their simplicity to implement, with MethodMaker winning on terms of further inheritance. Maybe you know of some other cool ways to do this? What I'm really asking is, what is the preferred way to implement an object with a good simplicity/power ratio?

dshahin

[Hrunting]

In my office, we're working on a project right now that is massively OO, with deep levels of inheritance and complex relationships. This is the most complex OO project I've ever worked on, and it's being done entirely in perl with the mindset that later parts or all of it will be ported to Java and possibly C. With that in mind, I'll tell you what we've come up with:

We're not using Class::Struct and/or Class::MethodMaker. I can't really say why other than we don't really need it.

Documentation is key. All our modules start out with their documentation first, and things are documented before their implemented (so if I say, add a feature that requires a method or object variable, I write the documentation first). After documentation comes tests based on that documentation, and then code.

When dealing with inheritance, about the only thing we take for granted is the internal structure of the object (a hash, in almost all cases). For everything else, we use only fully documented features. We may know that the 'variable' entry exists in our hashref, but if it's not documented, we don't use it. If we need access to that entry, we either document the entry or (more often) code in a method to access it.

With that in mind, our code is actually surprisingly simple. Modules are tiny in terms of length of code and the efficiency of the system, while constantly being tweaked, is actually very good. We're not doing some things where we could (for example, we don't use AUTOLOAD because the complications that arise when porting that function to other languages make it a bit of a hassle), but for the most part, the pieces fit together.

So I would say the major thing is documentation. It doesn't really matter how you do things, just as long as everyone is clear on how they are being done. That requires extensive detailing of what you can and can't do, and then a strict adherence to those details.

Do that, and you can implement objects however you want.

[salvadors]

I guess this isn't really a sensible suggestion unless you want to do some *really* mad stuff, but I'm slightly surprised that more people don't use globjects - where they bless the entire glob, rather than just a hash or array.

Then you can use, for example, the hash to store your public variables, the array to store your private ones, the scalar to keep a count of something, etc ...

This is what Data::Locations does, but it takes it to mad extremes: it's also a self-tied filehandle which rolls its own reference counting for garbage collection.

Removing the comments from this and getting potential employees to code review it at interview is a good way of seeing what someone's advanced level perl is like.

Tony