Hmm, that's an idea. PyGtk implements other special proprerties, like
__doc__ (which gives you back class documentation including signals,
properties, etc), __signals (user-registered signals), __properties
(user-registered properties), etc. What should we do about those?
From a documentation and code readibilty angle, these magic vars are always a little difficult to understand.
alot of those look like they should be part of the reflection stuff ???
__doc__ = $x = new ReflectionClass($object); $x->getDoc();
__signals = GSignal::list_in_object($object);
__properties = $x = new ReflectionClass($object); $x->getUserDefinedProperties();
I'm still annoyed you snuck __get / __set / __call in rather than using a new language construct :)
Regards
Alan
-- definatly move them to the class :) - I dont think that would be the bottleneck for performance (eg. compared to the rendering on the screen of the widget)
Okay. They'll actualy be in top-level class namespace, that is
Gtk::TOOLBAR_TEXT, rather than GtkToolbar::TEXT.
I was also thinking about registering classes for each enum type, for
example GtkAttachOptionsType that will have ->enum_values property that
lists all enums belonging to the type, and also a method to take an
integer enum and give you back its name (debugging). Thoughts?
-Andrei
<yaragn> ever seen that movie? The Matrix?
<yaragn> with those green lines of flying text?
<yaragn> *THAT'S* Perl