Re: Statically-typed read-only attributes

Sven Panne wrote:

> > [...] This raises the problem: what if I have also "instance Positioned 
> > Window"? Well, this problem has many solutions, the simplest of wich is 
> > *not* to have statically read-only attributes. I would rather try other 
> > solutions, however they might complicate the class and type hierarchy.
> > 
> > What do you all think about this?
> 
> I think that the distinction (read-only, write-only, read-write) is very
> important for a good API design:

Reminder: under Xt, an attribute has three such "flags":

[C] Can be set when the widget is created (XtCreateWidget etc).
[S] Can be set after the widget is created (XtSetValues etc).
[G] Can be retrieved (XtGetValues etc).

These are all independent, although some combinations are more common
than others:

+ Attributes tend to be CSG unless there is a reason to the contrary.

+ Callback lists are invariably C; once the widget is created, you
have to use Xt{Add,Remove}Callback rather than replacing the entire
list.

+ C without S is quite common; attributes which dictate a specific
"role" for a widget (e.g. XmNrowColumnType) usually can't be changed.

+ S without C typically corresponds to attributes types for which a
value can't reasonably be constructed before the widget has been
created. E.g. for compound widgets (e.g. OK/Cancel dialogs), the
attributes which specify the child widgets (e.g. the OK/Cancel
buttons) are SG.

+ The absence of G is not uncommon; this typically means that the
resource value is converted to an internal form in a way that can't
readily be reversed.

+ Just G (i.e. read-only) is common for values which are computed
rather than stored (e.g. XmNancestorSensitive).

-- 
Glynn Clements <[email protected]>