Plus, I think most plugin methods will /not/ seek to
override existing methods, and will be of the
"cgiapp_plugin_available" type. I think, where a name
is not provided by the user, it is more consistent and
intutitive that those methods would be put in a
default namespace, not the module's namespace. This
further differentiates the cgiapp_plugin_available
attribute from the cgiapp_plugin_override attribute -
which I think makes sense.
What is the difference between the plugin choosing a default namespace (and importing a method to access that namespace into the caller), and importing one or two methods directly into the caller?
I appreciate the effort and thought you have put into this, but I honestly think you guys are complicating a very simple process. Now I wouldn't consider myself an expert on these matters, and would appreciate some more input from others on the list, but I like the simplicity of how C::A::ValidateRM and C::A::Session work right now...
What I am looking for in a plugin is commonly refered to as a Decorator Pattern, where you take an existing class or object, and decorate it with more functionality (that is probably an oversimplification, but it should serve the purpose).
I want my Base class to have more functionality, without having to cut and paste a bunch of code all over the place. when I use the C::A::Session plugin I know that anywhere in my app I can call $self->session and I get my session object.
If we start importing different plugins into different namespaces, we just complicate the system, and make it more difficult to use (and to share code between developers).
Say for example I write a plugin called C::A::Auth which is an authentication plugin. This module depends on C::A::Session. So the Auth module will need to know how to access the Session object. The Auth module should be able to 'use C::A::Session' and then call $self->session to access the session object (which will always give it the same session instance that the rest of the app uses). It could also call $self->query to get the login and password from a form if need be.
If we start playing with namespaces, this situation becomes much more complicated. The Auth module will not be able to load the Session module by itself, because it may already be loaded into an unknown namespace in another location in the App. If it loads it into its own custom namespace, then any session objects that are created will not be shared with the rest of the app, and we get 2 sessions objects for a single request. So we have to leave it up to the developer to pass the namespace info about the Session to the Auth module when they use it. To me that is unnecesary complexity.
Lets look at namespaces from a different angle. Say in your application you want to debug some code by printing out the contents of some variables. A common thing to do is load Data::Dumper, and you have access to the 'Dumper' function to dump your data structures into human readable form. By default the 'Dumper' function is imported into the callers namespace when the Data::Dumper module is 'use'd. Is this inherently bad? Is this a dangerous thing to do? I don't think it is. This is how perl works, and it is how developers expect perl to work. I don't think the plugin system is that different. The main difference is that we are talking about methods instead of functions, but I don't think it is a very big leap to get there.
I won't have much time in the next little while to work on this stuff, so feel free to continue on and refine, and even implement your ideas. It might make things clearer to actually see an implementation of your system to see how it will work in practice.
Cheers,
Cees
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
