Plugins accessing parent state
andre.roberge at gmail.com
Fri Mar 28 10:58:11 CET 2008
On Mar 28, 6:39 am, "hajdu... at gmail.com" <hajdu... at gmail.com> wrote:
> On Mar 28, 1:58 am, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
> > hajdu... at gmail.com schrieb:
> > > Does anyone have some design ideas ( or can point me at the right
> > > design pattern, because I can't find it. ) for having a plugin being
> > > able to access a parent's state?
> > > For example, let's say I have a class that receives some commands.
> > > When it gets a command, it checks which of the registered plugins
> > > deals with that command and passes the details of the command off to
> > > that plugin. So I'd end up with something like..
> > > result = plugin.do(msg_details)
> > > Now, I want to write a plugin called "help" that loops through all the
> > > registered plugins and prints out their doc strings. If all my plugin
> > > is getting is the msg details, how is it supposed to get the list of
> > > available plugins from the calling class?
> > > Or, for instance, let's say my class loads a configuration file that
> > > lists a set of admins who can enter commands. I want the plugins, if
> > > they so choose, to be able to test if the msg came from an admin, but
> > > again, I'm not passing the admin list into every plugin, it's just in
> > > my calling class. I could make the plugin specify an attribute for
> > > itself, like "admin_only" and test for that before I pass the command
> > > but what if certain parts of the plugin are to be restricted and
> > > others aren't, based on the details of the command sent?
> > > Is this as simple as just passing the instance of my class to each
> > > plugin? It doesn't seem like the proper thing to do, because now the
> > > plugin class has the capability of accessing the whole bot's
> > > interface.
> > Yes, it is simple as that. Of course you can choose *what* you pass, if
> > you want to restrict that - nobody forces you to pass the whole
> > plugin-manager, if that would expose properties/methods you wouldn't
> > want ther.
> > But to be honest: you are thinking much to far there - after all, it's
> > all *your* code, and inside one interpreter. A real isolation isn't
> > available anyway.
> > So just do what fullfills the functional requirements.
> > diez
> Since I want to have a uniform call to all plugins, would it make
> sense to split out the attributes that I do want to share to a
> separate class and then simply create a new instance of that class and
> store it in the main class?
> For instance
> self.utilities = Utilities(self)
I would bypass the step of creating a new instance and write instead
thus having access to all properties/methods of the calling object.
Why restrict it?...
More information about the Python-list