With respect for your oft-expressed and totally consistant views on what you will amd will not use in your production codebase. Based upon those previously expressed views, you would use neither threads nor inside-out objects.
Is there any chance you would have use for what xdg is doing, whether it overrode bless or not?
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] |
You're right, I probably wouldn't use inside out objects anyway, so take my advice with a big grain of salt. Doesn't overriding bless seems unusually risky though? I've seen a lot of posts here and on the mod_perl and Class::DBI lists over the years about things that break nearby when people mess with the core pieces of perl's OO machinery.
| [reply] |
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.
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] |
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.
-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] |
