[mp2] insideOut mp.

[Ali ISIK <fe...@gmail.com>]

Hi, folks,

I need some mod_perl wisdom regarding the current
situation with inside-out classes.

I am trying to compare, in particular, the following two:

    Class::Std
    Object::InsideOut

I can see that O::I has advantages in

    o   thread safety
    o   (at least partial) foreign-inheritance support (the
    ability to inherit from non-inside-out classes)
    o   speed (mainly due to array implementation of fields)
    o   complete mod_perl support

but I have some investment in Class::Std and I am
trying to figure out whether I will have to convert my
existing C::S CGI code to O::I for mod_perl compatibility.
Are there any show-stoppers with C::S?

I have seen some postings which declared Class::Std
mod_perl-incompatible.  The ideas put forth included:

    1)   crucial sub initialize() is in a CHECK block
    2)   custom :attributes break under mod_perl
    3)   some concerns about DESTROY

I see that (1) may by now have been solved (is it?),
as initialize() is now called from within new(), too.

(2) seems to refer to :CUMULATIVE, :PRIVATE etc.
Suppose I do not use these.  Should I be ok, then?
Are there any problems with the main :ATTR( ... )
facility?

How about (3) and other possible weaknesses?

I may need foreign-inheritance (inherit from CDBI)
and thread-safety (use fork() and port to Win).
Is C::S totally hopeless in these respects?

Thanks,

__aLi__

Re: [mp2] insideOut mp.

[Scott Penrose <sc...@dd.com.au>]

On 13/07/2006, at 8:33, Ali ISIK wrote:

> Hi, folks,
>
> I need some mod_perl wisdom regarding the current
> situation with inside-out classes.
>
> I am trying to compare, in particular, the following two:
>
>    Class::Std
>    Object::InsideOut
>
> I can see that O::I has advantages in
>
>    o   thread safety
>    o   (at least partial) foreign-inheritance support (the
>    ability to inherit from non-inside-out classes)
>    o   speed (mainly due to array implementation of fields)
>    o   complete mod_perl support
>
> but I have some investment in Class::Std and I am
> trying to figure out whether I will have to convert my
> existing C::S CGI code to O::I for mod_perl compatibility.
> Are there any show-stoppers with C::S?
>
> I have seen some postings which declared Class::Std
> mod_perl-incompatible.  The ideas put forth included:
>
>    1)   crucial sub initialize() is in a CHECK block
>    2)   custom :attributes break under mod_perl
>    3)   some concerns about DESTROY
>
> I see that (1) may by now have been solved (is it?),
> as initialize() is now called from within new(), too.
>
> (2) seems to refer to :CUMULATIVE, :PRIVATE etc.
> Suppose I do not use these.  Should I be ok, then?
> Are there any problems with the main :ATTR( ... )
> facility?
>
> How about (3) and other possible weaknesses?
>
> I may need foreign-inheritance (inherit from CDBI)
> and thread-safety (use fork() and port to Win).
> Is C::S totally hopeless in these respects?

My experiments and understanding is that Class::Std (also was my  
preference and investment in coding) does not only fail on threads,  
but forks as well. This means it can not work with mod_perl at all.

The reason is that the all important identifier is a memory location  
- and that changes on write after a fork.

I have not actually tried using C:S with mod_perl - and other wiser  
people may have better advice.

Scott
-- 
* - *  http://www.osdc.com.au - Open Source Developers Conference * - *
Scott Penrose
Open source developer
http://linux.dd.com.au/
scottp@dd.com.au

Dismaimer: Open sauce usually ends up never coming out (of the bottle).

Please do not send me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Microsoft is not the answer. It's the question. And the answer is no.