Doesn't overriding bless seems unusually risky though?

I hadn't made up my mind, but having just read freind Ytrew's post, and justification, I do actually agree with you--but for Ytrew's reasoning rather than yours :) I don't have any call for using mod_perl, and almost certainly will never use Class::DBI.

I'm not yet convinced of the benefits of Inside Out objects either. The extra "protection" afforded seems minimal in that any enterprising subversive can bypass it easily enough anyway. I've also had occasion to go direct to instance data within a hash based module via the reference, when that data was not exposed. Most recently I needed access to the underlying IO handle in File::ReadBackwards, but no accessor method is provided. Whether I would do this in production code would depend very much upon my need, the urgancy of that need, and whether it was worth the risk of locally forking a CPAN module in the hope that I could get the changes adopted by the author. I'm would not allow OO dogma to prevent me from getting a working solution. I would probably opt for adding an accessor method to the module at runtime as an interim solution, if I needed access to the data in more than one place. If I only needed it in one place, a big ## !!TBD!! comment would probably suffice (for me).

I'm also not yet convinced whether what xdg is trying to do, with regards to cross-thread objects is either desirable or necessary, nor whether when it is done, if it will be retain sufficient performance to be usable.

I am however, eager to see the results of his efforts and looking forward to trying them out.

Ytrew makes a good point.

I don't have any call for using mod_perl, and almost certainly will never use Class::DBI.

The danger is that even if the author didn't use the code in those environments, releasing it on CPAN means someone else probably will, and will be surprised if there are incompatibilities.

Hmm. It would be easy to add a Not designed for mod_perl environments! disclaimer to the pod.

However, given that mod_perl is essentially a hack--a very useful and effective one, but still a hack--I would think that the onus would be upon the users of mod_perl to understand the demands and limitations that environment imposes upon the code it runs, and avoid those modules that it will have problems with, but that will be very useful to those that do not run in that environment.

Mod_perl may be very good and widely used, but I don't think that compatibility with it should be a requirement imposed upon all CPAN modules.

From the little I know of what xdg is doing, I wonder if it could ever be compatible with mod_perl?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm not yet convinced of the benefits of Inside Out objects either. The extra "protection" afforded seems minimal in that any enterprising subversive can bypass it easily enough anyway.

There is a frequent misconception that the "protection" afforded by inside-out objects is about hiding data. It's not. Encapsulation, from an OO sense, really has to do with objects providing a contractual interface and other parts of the code not needing or being coupled to any details about the implementation of that interface.

Classic Perl objects encapsulate weakly -- or rather provide what I call 'advisory' encapsulation. You shouldn't access object internals, but nothing prevents you from doing so. Inside-out objects enforce encapsulation. To some, that's important.

The other encapsulation challenge is in subclassing. With classic Perl objects, subclassing can't be done without violating encapsulation -- subclasses must use the same data structure as the superclass and must be sure not to collide with superclass properties including unpublished private properties. From that sense, inside-out objects can provide not just strong, but complete encapsulation, including for subclassing. (Albeit only for some implementations of inside-out objects and with limitations on doing so for multiple inheritance.)

recently I needed access to the underlying IO handle in File::ReadBackwards, but no accessor method is provided

This is actually a good example of what inside-out objects can do well. I recently uploaded File::Marker -- a demonstration module for my upcoming presentation. The object is an IO::File object -- you can use it directly and there are associated properties available through accessors. That's not possible with hash-based objects.

I'm also not yet convinced whether what xdg is trying to do, with regards to cross-thread objects is either desirable or necessary

If you read Threads and fork and CLONE, oh my!, you'll see that it's not an optional thing if one wants to be thread-safe (and fork-safe on Win32). The same is true of any XS code with C data structures -- they will not be properly replicated across threads, which is why CLONE was introduced in the first place. What I'm trying to do is minimize how much the average user needs to understand about this to be correct -- I'm trying to make sure that inside-out objects can be written simply and correctly without worrying about all the complex things needed to make them robust. I want it to just "do the right thing".

I take all the concerns about inside-out objects to heart -- I'm not sure they really are the right solution or whether the benefits they offer are worth the extra complexity. I'm not an advocate in that sense. I love perrin's critiques -- they speak to the pragmatist in me.

However, I volunteered to give a presentation on inside-out objects, so I've been trying to make sure that I understand all the various ramifications well enough to explain them fully to others. Having gone through all those details myself, I now see the need for an easy, minimalist toolkit to work with them safely and sanely. The technique can and should be fairly explored, not dismissed out of hand due to faulty or sub-optimal implementations.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

The technique can and should be fairly explored, not dismissed out of hand due to faulty or sub-optimal implementations.

I agree wholeheartedly. I've been quietly following your progress in anticipation of trying out the results.

With respect to the thread safety. I am not convinced is that there is either a need for, or a benefit to, sharing objects between threads. I believe that most everything that can be done by doing so, can also be done, and is (may be) better done through a "messaging" interface.

My opinion is based upon the results of various prototypes I created for a distributed object architecture several years ago. Cooperating objects could variously exist as

• Other threads within the same (OS/2) process.
• Other processes within the same box.
• Other processes or threads on different boxes.
• One or more TIRS (The Interactive Reasoning Shell), expert systems running under MVS or AIX.
• One or more IMS hierarchal DBs.

We tried various mechanisms, including cross-threaded objects (sic), and on the basis of my experiences then, cross-threaded objects simply ended up getting cross-threaded. Programmed absolutely correctly, they worked reasonably well, but the requirements for the application programmers and object constructors to understand and deploy locking and synchronisation at various levels, meant that they became too easily subject to deadlocks.

We opted for a message passing paradigm which allowed both application and object writers to essentially ignore locking and synchronisation issues and the SendMessage()/ProcessMessage() infrastructure took care of all that in a dependable manner while still allowing full advantage to be taken of asynchronism.

In practice, the perceived costs of message-ifying communications, were more than compensated for (in performance terms) by the avoidance of "belt&braces", unnecessary locking and sync-ing. In terms of reliability and programmer productivity, there was no contest.

So, my opinion is based upon experience, albeit possibly not entirely relevant experience, but I have followed your progress with interest, and open mind, and a desire to try out the results.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Well, it's really wrapping bless rather than doing anything different in the core. I just need an extra action when someone blesses an object. My initial view was to register separate, then I thought about being "helpful" with bless, then I began to cringe and wonder -- thus this post. Early gut reactions do seem to suggest that overriding bless is just a bit too clever.