Re: [Vala] Question about namespaces..


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:

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]