Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

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

by yosefm (Friar)
on Jun 14, 2004 at 13:28 UTC ( #366530=note: print w/ replies, xml ) Need Help??


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

Well, of course I used a context object just for the point of showing what it means. The obvious place for it will be in recursively parsing some nested data, like in templates. I actually relied on what I saw in MT::Template::Context (from MovableType) when I wrote that part.

If I only wanted to write a complaining program, it could probably be golfed quite a lot if reduced to the bare essentials (anyone wants to give it a shot?), but then It wouldn't teach us about much plug-ins, but rather about golf.


perl -e'$b=unpack"b*",pack"H*","59dfce2d6b1664d3b26cd9969503";\ for(;$a<length$b;$a+=9){print+pack"b8",substr$b,$a,8;}'
My public key


Comment on Re^2: Draft - Writng pluggable programs with perl.
Download Code
Re^3: Draft - Writng pluggable programs with perl.
by dragonchild (Archbishop) on Jun 14, 2004 at 13:50 UTC
    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

        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
      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 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://366530]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2014-12-25 19:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (162 votes), past polls