I'm sold -- I write most code as object modules now. Yes, it adds some work to make sure it's inheritable, and I have to think whether a method can or must be called as a class method, or can or must have an actual object. I've even written a couple that allow non-class function-style use. My coworkers aren't interested in dealing with the learning curve for objects, and don't care to hear about it.
I try not to harass them, but our code styles are diverging, and it becomes very difficult for them to maintain my code, since they know nothing about OOP. I don't want to abandon inheritance, or encapsulation, or polymorphism, and I darned well don't want to have to reinvent the wheel to get the same results when Perl has a fine method for it, but these philosophies are becoming difficult to reconcile. Obviously, though I understand it well enough to use it, I can't explain the advantages. They say "you could just do that with so-and-so", and I can't communicate the amount of work saved by the abstraction. Even now that we're in the process of migrating to a new platform and are going to have to deal with a lot of legacy hardcoding, it's hard to convince them we should have any standards. (exception -- everyone is happy to impose standards that were their own ideas; fortunately my boss isn't a tyrant :) Could someone point me to a concise description of the benefits of objects that might be short enough for my coworkers to actually be willing to read, and that still explains enough to make it make sense? __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
