in reply to Re^5: Overriding bless for inside-out object safety
in thread Overriding bless for inside-out object safety

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.

Replies are listed 'Best First'.
Re^7: Overriding bless for inside-out object safety
by xdg (Monsignor) on Jan 04, 2006 at 20:12 UTC
    From the little I know of what xdg is doing, I wonder if it could ever be compatible with mod_perl?

    There's only a few things that I've heard of that cause problems for mod_perl.

    • Many inside-out object toolkits use attributes and the CHECK phase to set up various things and that doesn't work under mod_perl

    • Without hooks for Storable, inside-out objects can't be serialized*

    • Perl threads clone the interpreter; mod_perl uses a persistant interpreter. I'd imagine the combination would be ugly, regardless of whether inside-out objects are involved or not

    What I'm working on will address the first two problems. Object::InsideOut does this already today. The last is a tangential issue, though I'm also providing support for inside-out objects and threads, regardless of mod_perl issues.

    *Expecting to serialize an object by violating encapsulation and treating it like a data structure isn't a very good practice to start with as it's inconsistent usage of imperative and object-oriented styles of programming: freeze( $object ) instead of $object->freeze. Thankfully, Storable does the right thing if hooks are provided.

    -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.

[reply]
[d/l]
[select]
      Perl threads clone the interpreter; mod_perl uses a persistant interpreter. I'd imagine the combination would be ugly,

      That was my main concern, but I hear that mod_perl2 "uses threads". I am unaware if these are in any way compatible with ithreads, hence my reluctance to say "it can't work".

      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.
[reply]
Re^7: Overriding bless for inside-out object safety
by Arunbear (Prior) on Jan 04, 2006 at 21:11 UTC
    Why is mod_perl 'essentially a hack', and why would you never use Class::DBI?
[reply]
      Why is mod_perl 'essentially a hack',

      Because:

      • you have to tailor your perl to fit it's demands.

        Much of what passes as perfectly good and safe normal (ie.non-mod_perl) code, is unsafe in a mod_perl environment.

      • One bad, or memory hungry script can take your entire server down.

      Beyond that, I can only quote from one of several comparisons I've read: 

      Some nice things about fastcgi/speedycgi (http://daemoninc.com/speedyc
+gi/)
*) suexec works with it (I consider this huge)
*) don't have to worry about running multiple web servers (one for
   images/static and one for dynamic).
*) one process can't pollute another's.
*) can make changes to .pm's and they are seen as soon as
   you "touch" the main file. (for speedy, I believe fcgi works
   a little different).
*) bad code doesn't take away the httpd's ability to serve files.
*) can probably be hacked to use internet domain sockets as
   opposed to unix domain so that we can run the cgi's on
   a different box. (fastcgi already does this, speedy does not)
*) the architecture just *feels* better to me than having a perl
   interpreter inside the webserver (but my mind is still open).
*) fastcgi is language independant (speedy is not)

      [download]
      why would you never use Class::DBI?

      Because IMO, it places the code in the wrong place and encapsulates objects in the wrong way.

      If you are going to back objects with an SQL DBMS, then the SQL should be in stored procedures and object methods should call those. I was told a long time ago that the secret to using SQL/RDBMSs is in getting the dbm to do as much of the work for you as possible.

      Instantiating all your data as objects in your program, leaves you faced wih much higher transmission costs if you update after every local change, or you risk concurrency issues if you cache locally.

      As always, that is just my opinion. I am not trying to detract from other's use of these things. Just expressing my own preferences.

      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.
[reply]
[d/l]

In Section Meditations