Plugins accessing parent state

[André]

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)
> ...
> plugin.do(msg,self.utilities)

I would bypass the step of creating a new instance and write instead
plugin.do(msg, self)
thus having access to all properties/methods of the calling object.
Why restrict it?...

André