Re: [Vala] Question about namespaces..

["Jan Hudec" <bulb ucw cz>]

Hello,

On Wed, January 6, 2010 01:35, Shawn Ferris wrote:
> Now the question. Well, more of a thought. Perhaps this is even possible
> already, and I'm just not finding it in the documentation. Regardless, I
> was trying to develop something like a plugin manager and keep
> everything related to the plugins under a nested namespace. (IE:
> MyApp.Plugin)
>
> I'd then have a class (MyApp.Plugin.Instance) that the plugins would
> inherit from and automatically control some of the setup. I also needed
> a way to track the order in which the plugins were registered, and more
> importantly, the notion of a current plugin. (This is not exactly a
> plugin manager, but it was the best example I could relate to)
>
> So, I created an ordered type hash structure in MyApp.Plugin to track
> all the instantiated plugins. And then figured a property would handle
> the current plugin by just returning the first element in the ordered
> hash. This way there's no need to shuffle a variable when plugins are
> unregistered/unselected. It's just removed from the ordered hash, and
> viola, current will automatically reference the next one in line.
> (Obviously, I didn't realize right away that namespaces couldn't contain
> properties, which is not really a problem either, because I just
> replaced it with a method instead)
>
> .. but then someone posted a message regarding Singletons, and I'm
> thinking, why couldn't namespaces be Singleton Objects? Instead of
> instantiating it with new, they could be initialized. (EG: initialize
> Namespace;) Even better, perhaps we don't have a choice, it just gets
> initialized upfront?

It already exists. It's called a class!

Each class has a "class struct" (as called by GLib; or metaobject in
terminology of some other languages), which is initialized when you
first access the type. The type is accessed by
 - creating an instance,
 - calling a class method (vala has "static" methods and "class" methods,
   the former being just functions, while the later are methods of the
   metaobject),
 - accessing class field (note though, that subclasses have their own
   instances of class fields),
 - accessing class property,
 - calling typeof(TheClass) or
 - doing any of the above for any subclass.

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

> Seems to me, it'd be useful.. or am I just kidding myself? or worse,
> designing bad code? 8D

Namespaces are useful as they are and better stay that way. All you want
is already provided by classes (and their metaobjects).

-- 
                                        - Jan Hudec <bulb ucw cz>