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 <[email protected]>
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
