McParen/croatoan

Class hierarchy and naming of position slots/accessors

McParen opened this issue · 7 comments

McParen commented

At the moment, the simple croatoan class hierarchy looks like this:

widget --> window  --> screen
                   --> sub-window
                   --> extended-window
                   --> pad --> sub-pad
                   --> panel

       --> element --> field
                   --> button
                   --> label
                   --> checkbox --> menu-item
                   --> menu     --> menu-window --> dialog-window
                                --> menu-panel
                                --> checklist

       --> form    --> form-window

For historical reasons, both window and element have separate slots and differently named accessors for the position, window-position and element-position, because just "position" is taken by cl:position, which is unfortunate.

I would like to fix that and have a single accessor for the position of all visible widgets, which would mean moving the y and x slots from element and window up to the parent widget class, but I am uncertain about what accessor name should be picked that would sound most "natural" for all visible objects.

Alternative 1: Use "widget-position" for everything. That would lead to calls like (widget-position win) and (widget-position field), etc., which is okay but for me doesnt sound "nice" and "natural" in this context.

Alternative 2: Add widget-position, but also keep using different accessors that accomplish the same, window-position, element-position, etc.

Alternative 3: Shadow cl:position and use the fully qualified name crt:position, which would be the cleanest solution, but which would lead to naming conflicts to everybody who :uses the whole package.

Any thoughts about this?

cage2 commented
foggynight commented

Hello McParen and cage2,

I would prefer option 3, but I'm also not looking at dealing with any breakage as I don't :use, option 2 is a close second.

foggynight

cage2 commented
McParen commented

Hello cage and foggynight,

thank you both for weighing in. Thank you also cage for a later discussion on the channel.

Specializing a single generic function on a parent class and all of its children is how other toolkits (CAPI, cl-gtk, nodgui/ltk) handle this.

So using

(defgeneric widget-position (object))

(defmethod widget-position ((object widget)) ...)
(defmethod widget-position ((object window)) ...)
(defmethod widget-position ((object field))  ...)

instead of defining several separate accessors

(defmethod widget-position (widget) ...)
(defmethod window-position (window) ...)
(defmethod field-position (field) ...)

makes most sense I think.

Having an accessor "position" without a prepended class name "widget-position" would be nice, but dealing with symbol name clashes with the default CL package is not really worth it.

Other bindings like CAPI and cl-gtk, which have rather deep class hierarchies, do prepend every accessor with the class name, like gtk-widget-width-request or text-input-pane-callback, which is a naming style I must say I do not really like. I do not know whether there are drawbacks to omitting class names from accessors names, but in general that is the way I like it better.

Thanks for your comments.

  • 👍2
cage2 commented

Hi!

FWIW i just updated my code to reflect the changes (from window-position to widget-position) in the library and everything works fine! :)

Bye!
C.

McParen commented

Hello cage, I did not expect code to break (because I ran tests on the changes in the code) but rather wanted to hear your opinions about changes in the naming of the public API. So thanks. ;)

foggynight commented

Hello,

Just wanted to note that I misspoke in my comment above weighing in on this, I meant to say I would prefer option 3 but option 1 was a close second. I would much prefer either to using different accessors (option 2)!

  • 👍1