André a écrit :
> On Mar 28, 6:39 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>> On Mar 28, 1:58 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
(snip)
>>> But to be honest: you are thinking much to far there - after all, it's
>>> all *your* code, and inside one interpreter. A real isolati
On Mar 28, 6:39 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> On Mar 28, 1:58 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>
>
>
> > [EMAIL PROTECTED] schrieb:
>
> > > Does anyone have some design ideas ( or can point me at the right
> > > design pattern, because I can't find it. ) for
On Mar 28, 1:58 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] 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,
[EMAIL PROTECTED] 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,
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 plugi
