Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^2: Overriding bless for inside-out object safety

by BrowserUk (Patriarch)
on Jan 04, 2006 at 17:28 UTC ( [id://520965]=note: print w/replies, xml ) Need Help??


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

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.

Replies are listed 'Best First'.
Re^3: Overriding bless for inside-out object safety
by perrin (Chancellor) on Jan 04, 2006 at 18:00 UTC
    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.
      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.
        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.

        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.

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://520965]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (4)
As of 2024-03-29 04:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found