TWiki and Perl OOP features

Right now, only a few of the TWiki modules act as Perl "classes", most notably TWiki::Meta (see MetaDotPm). If we can refactor most the other modules into this mode, a number of advantages accrue, especially in the presence of ModPerl:

• Improved separation of truly "global" variables from per-request state variables.
• proper ModPerl support: since TWiki application state would be stored in an object instance, reinitializing that state for a new request becomes trivial, and will not need much further work as TWiki evolves.

I don't know how practical this is. Trying to make TWikiDotPm into a Perl class would be a huge undertaking all on its own. TWiki's code contains literally hundreds of functions, and adapting each and every one to an object-oriented programming style without introducing bugs will be extremely difficult. Are the above benefits (feel free to add any others directly to the list above) worth the effort?

Also, how comfortable is the rest of the CoreTeam with OO Perl? Since I've been working a great deal in Java and C++ lately, I know I'd probably find an object-oriented structure easier to deal with than the largely procedural structure we have now.

The use vars lists at the top of TWikiDotPm are quite intimidating, and seem to be rather poorly organized. For example, $webName, $topicName, and a number of other variables that I understand to be per-request TWiki state are declared in the "config variables from TWiki.cfg" list. Paring down these lists by incorporating as much state as possible into a "TWiki request object" would definitely make the implementation a lot cleaner from my point of view.

-- WalterMundt - 06 Feb 2004

Update: I've managed to prune and reorganize the use vars lists, although I'd still like to continue along this path of ideas.

-- WalterMundt - 23 Feb 2004

Well, gee. As of Dakar, many of the modules are now objects. For this I say YAY. Also as of Dakar, there are no accessor functions, so use of these objects is completely implementation-dependent. For this I give a very large BOOOOOO.

I've used a number of object-oriented languages. In all of them you either had to use accessor functions or it was strongly encouraged to do that. Unless things have changed without my noticing, accessors are considered essential to using OO effectively.

So what happened? Was there not enough time? Not enough interest? Disagreement with this principle by the core team? (And, yes, here is another example where I don't have a clue as to how to find the answer. Per Peter's suggetion, I put Object in the Jump box and this was the closest topic I was able to find. I'm sorry, but I really don't want to be putting synonym after synonym into the Jump box hoping to land up on the right one, assuming there is a right one.)

-- MeredithLesly - 01 Apr 2006

From what I've seen of Cairo code, "not enough time" would seem to be a sufficient attribution. I think it is fair enough to leave the job of introducing an accessor to the first devleoper who actually needs it.

-- HaraldJoerg - 01 Apr 2006

Which leads use to non backward compatible code with every added accessor... at least for the new function (or the plugin) using it. Meredith got the point.

In OOD any missing accessor is meant to be missing. If there is no accessor than you should not need one, per design.

-- TobiasRoeser - 01 Apr 2006

For those not familiar with OO terminolgy, accessor functions are functions that are used to hide data within an object. So if I have an object X that has a field Y, I refer to it using X->getY() and X->setY(val) rather than X->{Y}.

I added accessors where I could. There are a few places where full data hiding wasn't practical, for one of three reasons:

1. The object exported such a brain-dead interface that the best thing to do was throw it away and start again, but the object was widely used within the core and beyond (as was the case with the Meta object)
2. To data-hide would (probably) have introduced unacceptable inefficiencies in the code. Perl is an interpreted language, and as such implements things like accessor functions really, really badly. I mean really badly. Try some benchmarks if you don't believe me.
3. I just ran out of energy/time.

Tobias is right; in OOD a missing accessor really means "don't access this". However TWiki was not designed according to OO principles, and there is a legacy of awfulness we have to live with.

Oh, and the final point that tipped the scales; in Perl, $X->{fred} doesn't necessarily mean $X->{fred}. You can bind the expression $X->{fred} to $X->getFred().

-- CrawfordCurrie - 02 Apr 2006

But the code using $X->{fred} could fail, if the implementation changed to $X->getFred(), couldn't it?

-- TobiasRoeser - 02 Apr 2006