Plugins accessing parent state

[hajducko]

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.

I realize that this is all just theory but I'd appreciate any points
in the right direction.

Thanks.

s

 

[Diez B. Roggisch]

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

 

[hajducko]

(e-mail address removed) schrieb:









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)

 

[André]

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é

 

[Bruno Desthuilliers]

André a écrit :

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?...

+1 on this.

And FWIW, *if* you later find out you *really* need to restrict access
to the caller object's attribute (ie: 'self'), it will be as simple as
wrapping it in a decorator (design pattern, not function decorator)
object that will take care of this, ie (Q&D naive implementation):

class RestrictedSelf(object):
allowed_attributes = ('dothis', 'dothat')
def __init__(self, realself):
self.realself = realself
def __getattr__(self, name):
if name.startswith('_') or name not in self.allowed_attributes:
raise AttributeError(
'access to %s.%s is forbidden' % (self.realself, name)
)
return getattr(self.realself, name)


And in the call to the plugin:

plugin.do(msg, RestrictedSelf(self))

<mode='xp-guru'>
But my bet is that YAGNI, so to make a long story short: start with the
simplest thing that could possibly work !-)
</mode>

HTH