Re: [Vala] Question about namespaces..

[Shawn Ferris <shawn ferris gmail com>]

On Wed, 2010-01-06 at 07:51 +0100, Jan Hudec wrote:

> It already exists. It's called a class!

Of course I know what a class is, and I understand (mostly) what they're
capable of. The problem with a separate class to manage the plugins is
scope. (IMO)

> I wanted to suggest you convert the namespace to class (you can have
> inner classes just fine) or create new class, but now I see you can
> just as easily abuse the class you already have. Just make the array
> a static field of the MyApp.Plugin.Instance class and make the "current"
> property a class property of the same (static will do if you only call
> it after any plugin is registered).

To convert the namespace to a class would require every plugin to then
know where the manager metaspace is, just so that it could instantiate
itself. That sounds like a pain, if not a bad idea.

I must admint, I'm not sure I choose the correct term for current..
perhaps visible is better?!? I'm including an example to illustrate
better what I'm talking about. (this is pretty close to how I
implemented it.. and of course, constructive critism is welcome.. it
seems sane-ish to me) 8D

using GLib, Gee;

namespace MyApp.Plugin {
  private Gee.HashMap<string,MyApp.Plugin.Instance> plugins;
  private int counter = 0;

  public void init() {
    plugins = new Gee.HashMap<string,MyApp.Plugin.Instance>
(str_hash,str_equal);
    message("add toplevel plugin specific menu/toolbar entries via
uimanager");
  }

  public static MyApp.Plugin.Instance current() {
    return plugins.get("Foo:0");
  }

  public static void register(string id, MyApp.Plugin.Instance instance)
{
    plugins.set(id,instance);
    message("%s: registered", id);
  }

  public static void unregister(string id) {
    plugins.remove(id);
    message("%s: unregistered", id);
  }
}

public class MyApp.Plugin.Instance : GLib.Object {
  public abstract string name { get; }
  public string id { get; private set; } 

  public void test() {
    message("Got here: %s".printf(this.id));
  }

  public Instance() {
    id = this.name+":"+(counter++).to_string();
    register(this.id,this);
  }
  ~Instance() {
    unregister(this.id);
  }
}

public class MyApp.Plugin.Foo : MyApp.Plugin.Instance {
  public override string name { get{return "Foo";} }

  public Foo() {
    message("foo plugin requires specific menu/toolbar entries via
uimanager");
  }
  ~Foo() {
    message("remove foo plugin specific menu/toolbar entries via
uimanager");
  }
}
public class MyApp.Plugin.Bar : MyApp.Plugin.Instance {
  public override string name { get{return "Bar";} }

  public Bar() {
  }
  ~Bar() {
  }
}

static int main (string[] args) {
  MyApp.Plugin.init();

  new MyApp.Plugin.Foo();
  new MyApp.Plugin.Bar();

  MyApp.Plugin.current().test();

  return 0;
}

I've hardcoded what current() returns for simplicity. In real life, it
returns the first value in my ordered hash structure. I'm not real sure
what the advantage of having Instance implement current is though. If
something external to the plugins knows how to get to a plugin, there's
really no point in having a current, I think.

Take for instance. I have a menu with file->save. If the plugins are
instances editor widgets, only one visiable at a time, then the save
signal would call MyApp.Plugin.current().save() and do the right thing,
in the right instance.

Obviously, converting a namespace to a singleton object would be mostly
cosmetic, I think. I imagine my init() would become a construct{} block
(and I could lose my explicit call to init()) and my current() function
becomes a property. ( MyApp.Plugin.current.test() vs.
MyApp.Plugin.current().test() )

And I agree, namespaces are already useful as they are. I was able to
accomplish everything I set out to do. It just occurred to me, when I
saw the singleton question, that they're sorta singleton by nature
anyway.. wouldn't it be cool if they could also be objects? (apparently,
that's not the best idea) 8D

Regards,
Shawn