Re: Properties on interfaces
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Properties on interfaces
- Date: 18 Feb 2003 14:40:06 -0500
So, if I understand correctly:
* You like the idea of properties on interfaces because:
- GTK+ can check that the class is implementing
the properties it needs to implement.
- Documentation and other introspection will work
correctly.
* You think that the way to implement such a property
is to simply install a property with the same name
on the instance class.
* To deal with the nick/blurb issue, you want to
introduce a TRANSLUCENT (*) flag which means
"if nick or name is NULL, look for a property
of the same name on a parent class or interface"
and get it from there.
Is that a good summary?
It sounds basically reasonable to me. I'm a little concerned
by the fact that the default and range need to be specified...
sounds like a good way to introduce subtle bugs, but
it isn't the end of the world.
As for CONSTRUCT properties on interfaces, I was thinking
to disallow them, but if we go with the above scheme,
I don't really see any reason to disallow them, except
possibly that there are some questions about their exact
behavior which are hard to answer without a concrete
use case. (**)
Owen
(*) I like Matthias's idea of INHERITED better for
a name.
(**) If a property is specified as CONSTRUCT in an interface,
is it allowed to be non-CONSTRUCT as implemented? If a
property is specified as non-CONSTRUCT in an interface,
is it allowed to be CONSTRUCT as implemented? Same
questions for CONSTRUCT_ONLY.
A good argument for not-allowing CONSTRUCT parameters
on interfaces is that since we don't require CONSTRUCT
properties to be passed to g_object_new(), they
are basically implementation details. But CONSTRUCT_ONLY
makes an application-visible difference.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]