Bill Catlan wrote:
I also respectfully disagree with you here Cees. While perl does allow you violate your namespace (and that of others)As long as some thought is put into writing the
plugins, I don't really see a big problem here.
Yes and no. Thought is one thing, but having to
research the plugin methods exported by all /known/
plugins is another. As plugins proliferate, like we
hope, what a chore that would become. Respectfully, I
think avoiding name space collisions is essential. Otherwise, your building in an (unnecessary) problem.
when you deem it appropriate that's not it's behaviour by default. The concept of namespaces came about just for this kind of thing... separating methods, variables so that they won't override each other.
Michael Peters wrote:
Ok, some more thoughts and ideas on all of this...
This method would work, but I think it has the
possibility of adding new confusion, and it adds an extra level of
indirection. I want to be able to write a plugin that replaces 'load_tmpl' for
instance...
Shouldn't method overloading be done in a base class, not a plugin? But, please see below for further thoughts.
I see Cees point here. A plugin should be able to introduce new methods as well as override existing ones. This happens with apache modules too. Some create new conf directives, others override existing directives with their own semantics. As long as the plugin documents this I think it's a great idea.
package MyApp; use base 'CGI::Application'; use CGI::Application::Plugin::TT; use CGI::Application::Plugin::Config::Simple prefix =>'conf_';
[snip] $self->process(...); my $param = $self->conf_param(..);
I like Mike's idea about using an accessor better. I
like that it allows object caches and I prefer the
object oriented approach over descriptive prefixing. But, I suppose the programmer could specify no
accessor name and achieve your result of having the
plugin methods clobber any previous methods defined in
a parent class. Or maybe a method attribute could
specify that behavior, and the app programmer could be
warned in the docs and/or logs.
I think the OO method is better long term.
But that object itself still needs to be stored in
the application module's internal hash, otherwise you would be
creating a new copy of the plugin object everytime you called it. So there
is really no difference here.
Right, but since the user has already given this plugin a namespace, putting it into $self->{_PLUGINS}->{_namespace}
would mean that no one would clobber some else's stuff. Then
the plugin would be able to store other stuff in itself.
Initially I think I like this although I would just simplify it with just two options. Either it has a name, or it doesn't. This would decrease the likelihood of an error on the user's part. The third example does essentially the same thing as the second except the name is chosen by someone other than the user.We can come up with a convention (use
$self->{__PLUGINS}->{__SESSION} if the module is called CGI::Application::Session). We
could probably even standardize that by using the param method in C::A
and UNIVERSAL::moniker to come up with a key name. And
then we could even wrap that up in a method to be added to the plugin
class quite easily.
Yes, but that reference is getting to be a bit much to type. We could automate Mike's method by using some convention in the case where the user does not provide a name, such that:
package MyApp;
use base 'CGI::Application';
use CGI::Application::Plugin::TT name =>''; # name
defined, but false
use CGI::Application::Plugin::Config::Simple name
=>'conf'; # name defined and true
use CGI::Application::Plugin::MyPlugin; # name not
defined
[snip]
$self->process(...); # TT method clobbers previous
'process' methods
my $param = $self->conf->param(..); # uses user
defined accessor name
my $self->MyPlugin->my_method(..); # 'MyPlugin'
accessor name given automatically by
UNIVERSAL::moniker or some such method for creating
unique names
Maybe on the plugin development side we would have two method attributes. The first would tell the plugin that the method is to be exported 'as is' into the namespace of the module using it. The second would be available through the above mentioned access method.
This would give the plugin designer the ability to define (or redefine) both $self->tt->process and $self->load_tmpl.
Plugin modules should really only be exporting one
or two methods each. In the C::A::Session module, the only really
important method is the 'session' method.
I agree. One or two convencience methods and then a method to get at the underlying object. You don't really need more than that.
I hope Mike's method will still allow for the CGIAppPlugin attribute to specify which methods are 'exported', or, perhaps a better word is 'accessible' - through the accessor.
Oh most definitely.
I also respectfully disagree (with Cees). Namespaces make the sharing of code much much easier and that's what we are trying to do with these plugins right. This is one of the main problems with PHP. They thought it wouldn't be a big issue without namespaces, but sharing of code is really messy in that land.I'm glad you guys are interested in building on
these ideas, 'cause that was what I was hoping for. But I am still not
convinced that the namespace issue is that big of a problem.
I respectfully disagree. I think it is a fundamental problem.
I'd probably be more inclined to look at the strategies of mature, successful projects like apache and jedit and perhaps even jabber. Not sure when I'll have the time though...
Thanks for packagin up the DBI plugin though Cees and giving us something to structure the discussion around!
I agree. Thanks Cees for getting the ball rolling and starting this discussion.
-- Michael Peters Developer Plus Three
--------------------------------------------------------------------- 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]
