Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^3: Draft - Writng pluggable programs with perl.

by dragonchild (Archbishop)
on Jun 14, 2004 at 13:50 UTC ( #366543=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Draft - Writng pluggable programs with perl.
in thread Draft - Writng plugable programs with perl.

You're missing the point. I don't care about your code - your design is too complex. There is no need for most of the trappings you're using. All you need is a set of classes / objects that all conform to a given API. They don't even have to be constricted to that API, or even do the same things when called.

As for context ... context objects, imho, should be used only when there is no other option. They are basically global variables, with all the pitfalls that entails without any of the benefits. Plus, there's a ton of bookkeeping involved and every single object needs to know about it, and possibly every single method. It is messy, dangerous, and ugly.

My point is that you're taking a system designed for a very specific purpose and extrapolating it out to a generic concept. That's a dangerous thing to do and you're doing it poorly.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested


Comment on Re^3: Draft - Writng pluggable programs with perl.
Re^4: Draft - Writng pluggable programs with perl.
by yosefm (Friar) on Jun 14, 2004 at 14:52 UTC
      As for context ... context objects, imho, should be used only when there is no other option. They are basically global variables, with all the pitfalls that entails without any of the benefits. Plus, there's a ton of bookkeeping involved and every single object needs to know about it, and possibly every single method. It is messy, dangerous, and ugly.

    That depends on the implementation. If used correctly, a context object is just like a fancy OO way of giving arguments, one that allows you to do some more interesting stuff. Otherwise, you're definitely right.

    For example, the MovableType guys created a 'stash' in their context object, that allows just anyone to put stuff in it, making it exactly the pitfall you described.

    I'll say again that I only put it in the tutorial to 'float a phrase' and show what it might look like.


    perl -e'$b=unpack"b*",pack"H*","59dfce2d6b1664d3b26cd9969503";\ for(;$a<length$b;$a+=9){print+pack"b8",substr$b,$a,8;}'
    My public key
Re^4: Draft - Writng pluggable programs with perl.
by sutch (Curate) on Jun 15, 2004 at 01:35 UTC
    Why do you say that a context object too complex? Doesn't it help reduce complexity?

    Imagine a web application framework that needs to pass the request, the response, a database handle, an error logging object, a template, a user information object, etc. What would you recommend in place of a context object to handle this?

      Where on earth are you passing these objects to and from?!? Oh, my Gods! Neither mod_perl nor CGI::Application are anywhere near that complex. Frankly, this is what parent processes and sessions are for.

      Now, you may say "Well, isn't a session a context object?" and you'd be right. But, a session contains only enough information to maintain state between requests. The rest should be handled with Singletons.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

        I agree that singletons make sense in certain situations.

        In my example above, I was considering that a web application framework was running under mod_perl and serving up multiple sites. So each site could potentially pass a database handle specific to the application requested via the URL, an error log specific to the application requested via the URL, a template object specific.... I'm curious, how would you recommend implementing a framework that requires many objects passed among the objects which make up the framework?

Re^4: Draft - Writng pluggable programs with perl.
by perlfan (Curate) on Aug 19, 2004 at 21:26 UTC
    I have to agree. I have found this tutorial extremely helpful, but I felt as if the use of the context object was overly complex for what your aim is here. I think I spent about 1 hour total trying to figure out what it was for. When it he light bulb hit, I tried to simply return a value. After finding that this work, I felt like I wasted that time. Being able to pass an object reference in/out is helpful, but not needed to get your point across.

    I really did like your tutorial - just not the communication part...

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (10)
As of 2014-08-20 08:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (107 votes), past polls