I've been experimenting with some approaches for making inside-out objects a little more user friendly. (c.f. Anti-inside-out-object-ism for some of the common complaints). One of the more obscure issues has to do with thread-safety. I presented an approach for that in Threads and fork and CLONE, oh my!. I'm considering ways of making that more automatic and transparent.
One approach I've considered is a helper module that would override/redefine bless to register objects transparently for use in CLONE (which would also be imported automatically). Usage would be just as with a normal constructor:
package My::Class;
use InsideOut::Helper qw( bless );
sub new {
my $class = shift;
my $self = \do { my $scalar };
bless $self, $class;
}
Behind the scenes, this bless would do something like this:
my $REGISTRY;
sub bless {
&CORE::bless;
$REGISTRY{ $_[1] }{ refaddr $_[0] } = $_[0];
return $_[0];
}
$REGISTRY would also be used in CLONE to fix up inside-out objects during thread creation.
I'm a little cautious redefining something as critical as bless so I'd like feedback on this idea. Some specific questions I have include:
Should bless be automatically redefined or explicitly as shown in the example above? It would almost always be imported, but making it explicit highlights the fact that bless is doing something unusual. Without the import, it could be called as InsideOut::Helper::bless( $self, $class ) of course.
Is there anything unusual about bless' syntax or function that I need to watch out for in redefining it? (Should I use a prototype that matches the builtin?)
Is redefining bless a bad idea? Should I just import a separate function like register instead to register the object after it's blessed using the built-in bless? E.g. register( bless $self, $class )
Side notes -- the example above is incomplete as inside-out lexical properties also need to be registered somehow for use with CLONE. (I'm working on a good, simple syntax for that.) The InsideOut::Helper name is also just a placeholder as I haven't come up with a name for this module, yet. (That said, what do people think about a new InsideOut top-level name to make a sharper distinction from the more traditional Class? I'm not sure it's needed, but I could see a case for it.)
Also, at least some inside-out generators automatically import a function like id as an alias to refaddr for use like this:
my $NAME_OF{ id $self } = "Larry";
# instead of
my $NAME_OF{ refaddr $self } = "Larry";
Do people feel this kind of aliasing is helpful or symbol pollution?
Your feedback is greatly appreciated.
-xdg
Code written by xdg and posted on PerlMonks is [http://creativecommons.org/licenses/publicdomain|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.
Unless I misunderstood, you're trying to guage community reaction here? If that's the case, here are my thoughts, for what they're worth:
- I like your register( bless ... ) idea better. It's not a whole lot more to do, still takes care of a lot of drudgery, but doesn't make me quite so nervous. I don't like overriding builtin functions in general, much less one like bless.
- Perhaps you could use the Class::InsideOut:: prefix instead of just InsideOut::. Perhaps it's a little too long, I'm not sure, but it seems a bit more descriptive.
- The refaddr to id alias doesn't bother me all that much, as long as it's done in standard ways. It's certainly less to type. :-)
Closing, I just want to point out I don't feel very strongly about these opinions. They're just my gut reactions. If you wanted a more thorough discussion... well, maybe someone else will post that. :-)
Overriding bless is something I have attempted, see Overriding CORE::GLOBAL::bless. There are some caveats, particularly concerning precisely when the override takes effect. Admittedly, the purpose I was intending was not for production use, but in leak tracing.
I posted my conclusions here; I have not yet released an updated Devel::Leak::Object, but I may do at some future point.
Hope this helps
--
Oh Lord, wont you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, wont you burn me a Knoppix CD ?
(Missquoting Janis Joplin)
I was considering overriding it only for the current package, not globally, but the point in your conclusions about it needing to be done at compile-time are well taken. I went through a similar learning process overrriding rand for Test::MockRandom. The pod for that has a pretty good description of when and how such overriding needs to happen.
-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.
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?
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.
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?
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.
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".
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/speedycgi/) *) 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)
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.
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.
I am not convinced is that there is either a need for, or a benefit to, sharing objects between threads.
Ah! I think I see the confusion. The protections are needed even without sharing objects between threads (where changes to an object in one thread are visible in another). Just creating a new thread can break any previously created inside-out object. In any new thread, inside-out objects that use a memory address as the "index" to the inside-out properties will break as the memory address changes. The new thread is a completely separate copy of all the data structures of the original and thus all the refaddr's change.
use threads;
sub dump {
my $self = shift;
print "name: ", $self->name(), "\n";
}
$obj = Some::InsideOut::Class->new( name => "Larry" );
my $thread = threads->create( \&dump, $obj );
$thread->join();
Without CLONE, $obj in the new thread won't point to the same data as in the original thread. CLONE gives an opportunity to fix up the data structures. Note -- this isn't using threads::shared; changes to $obj in the new thread wouldn't be seen in the original, but CLONE is still necessary.
I'm not even tackling threads::shared support -- though jdhedden claims to have it working in Object::InsideOut, so it's apparently possible.
I'm not sold on threads personally, but the real problem comes on Win32 where fork is really creating a thread. CLONE keeps Win32 fork safe for inside-out objects.
-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 protections are needed even without sharing objects between threads (where changes to an object in one thread are visible in another).
This is only true if
- You create objects prior to spawning your threads
- You attempt to reference or use those objects from multiple threads concurrently and expect them to remain consistent.
I'm suggesting that neither of these is either desirable nor necessary for threaded applications provided you do not try to use threads as you would forks.
I cannot address your comments regarding fork on win32. With the absence of proper signal emulation; the conflicts with global resources, file handles, sockets, environment, etc.; and the performance penalty that the fork emulation layers upon threading; I (personally) would prefer it if the fork emulation did not exist.
In my attempts to use it, it simply isn't sufficiently compatible with Unix fork to make it usable in for the normal "forking idiom" (Silly forker :).
Of more concern to me is that the requirements imposed by the attempted emulation, have a disastrous effect upon the use of threads as threads. It forces me to jump through hoops to avoid the expensive and unwanted automatic duplication of resources, to be able to get 'virgin' threads without pre-existing baggage.
I realise that the emulation came first and threads (as in ithreads) leverage much of the excellent work that went into the original fork emulation, and I am not detracting from that work, but it would be so much better (for me, and my uses) if I could specify use threads qw[NOCLONE];.
Ie. When I create a thread, give me a virgin interpreter running in that thread and let me create the things I need. Please :)
I've never really understood the fork and exec idiom anyway. Why bother going through the process of duplicating the current process in to an exact clone--even with COW--if the next thing you are going to do is throw it all away and load a completely different executable image into that process? Why not just load the image into a new process and have done with it?
I know fork & exec isn't the only use of fork, but it is the most prevalent.
This is only true if...
I can agree with that. However, in writing an inside-out helper for others, I feel I have to plan if not for the worst case, at least for many of the suboptimal practices that people may use. (Insofar as Perl will let me -- I can't do much about pseudo-forks on Win32 Perl 5.6.) So while I agree, it doesn't let me off the hook of helping people with automatic support for CLONE.
-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.
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.
I'd suggest that you call it "register" instead, as you proposed later. And force the user to export only the functions they need, explicitly. That way, it's easier to maintain: if you export fifteen functions, I need to check the codebase to see if any of those fifteen functions are still in use before I can remove the module from the codebase. If you only export what you actually use, then maintaining the code and removing unused modules becomes much easier. I'm lazy; I'd rather write down what I know when I know it (such as what functions I'm using from a given module), rather than waste time trying to reconstruct what I've forgotten.
Is redefining bless a bad idea? Should I just import a separate function like register instead to register the object after it's blessed using the built-in bless? E.g. register( bless $self, $class )
I don't see the need to redefine "bless"; just tell people to use "register" instead of "bless". You call the core "bless" function, so you should be able to use register exactly as you do "bless". In general, I find redefining builtin functions is always more confusing than not doing so. If I read "register", I know immediately that I don't know what's going on, and that I need to learn more. If I read "bless", I might be fooled into the wrong assumptions.
Just my $0.02
--
Ytrew