|
in reply to Draft - Writng plugable programs with perl.
Personally, I think your system is overly complex. A "plug-in" is basically an entity that conforms to a given API that can be activated at runtime. I call this concept "intelligent classes". For futher info, see Re^3: Style or Clarity?. Basically, this is an advanced version of a dispatch table.
As for your passing information back and forth ... for the most part, this doesn't require a context object. It merely requires that all the plugins return the same data structure back from a given API function. A context object should only be used when there is actual context required. For further info, see what I did with PDF::Template and Excel::Template. I actually implemented a plug-in architecture for those classes, allowing for user-defined classes to be defined at runtime in order to handle custom tags. (The API is a little rough and mostly unpublished, but the architecture is still correct.)
In other words, it's good to bring this concept into the fore, but you made it more complicated than it needed to be.
------
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
|
Re^2: Draft - Writng pluggable programs with perl.
by yosefm (Friar) on Jun 14, 2004 at 13:28 UTC
|
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
| [reply]
[d/l] |
|
|
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
| [reply] |
|
|
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?
| [reply] |
|
|
|
|
| |
|
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
| [reply]
[d/l] |
|
|
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...
| [reply] |
|
|
