[cl-gtk2-devel] Property accessors naming

[Maciej Katafiasz]

Hi,

I'm working on wrapping GooCanvas with CL-GTK2 (as Dmitry already
knows from previous private correspondence), and while it's generally
very helpful, one thing that irks me are the prefixes in generated
property accessors. That is, the accessor for left-padding child
property in GooCanvasTable is called TABLE-CHILD-LEFT-PADDING instead
of simply CHILD-LEFT-PADDING. IMHO that's completely unnecessary, and
in the particular case of GooCanvas, pretty harmful as it leads to an
explosion of names because of how the inheritance tree is organised.
Namely, many common properties are not defined in the parent classes,
but instead are defined separately in each subclass. This means I have
dozens of differently-named accessors, all wrapping "width", "height",
etc. A similar situation arises in child properties, as there are two
classes, GooCanvasTable and GooCanvasTableModel, both defining the
exact same child properties as they're each other's functional
equivalents, but because they're not directly related by inheritance,
I end up with a separate set of TABLE-MODEL-CHILD-* mirroring all of
TABLE-CHILD-*. That's very much suboptimal.

I don't believe there should ever be any reason to disambiguate the
accessors' names, as they all wrap simple properties, so all have
compatible lambda lists and can freely be defined as methods of a
single generic function. So the only reason remaining is the somewhat
prevalent convention of naming accessors CLASS-NAME-SLOT-NAME.
However, I think it's particularly ugly, as well as unecessarily leaky
with regard to abstractions; it shouldn't matter what exact class the
accessor has been defined for, it still accesses the same slot and
represents the same conceptual operation. Adding the prefix only makes
the code more brittle and prone to breakages when the class hierarchy
changes.

So, to sum up, I'd like to request a change in how the autogenerated
names in DEFINE-CHILD-PROPERTY and DEFINE-G-OBJECT-CLASS forms are
constructed for properties: from the current CLASS-NAME-PROP-NAME to
simple PROP-NAME. That would obviously be an API breakage, but one
that should be trivial to deal with (not to mention the amount of code
depending on CL-GTK2 is still fairly small), and if it was absolutely
critical, the old names could be still provided in the previously
published classes. It would be good, however, to clean it up before
eventually moving to the long-term goal of fully introspected
definitions backed by gobject-introspection, to avoid gratitious
incompatibilities and ugliness in the resulting APIs.

Cheers,
Maciej

PS. That's mail 1 resulting from the last two days of my hacking; mail
2 will be coming soon to deal with some changes I had to do in CL-GTK2
to beL able to cope with GooCanvas mimicking-but-not-deriving its
child properties mechanism from GTK+'s one.