Implement GTK interfaces through next concepts

[gavr123456789]

nim-lang/RFCs#168
Implement GTK interfaces through new concepts when they come out, instead of sum types.
This is an issue for the future
For example GtkBuildable now:

proc getBuildableId*(self: Buildable | IconView | Spinner | EntryCompletion | Paned | AnyFilter | Box | CellAreaBox | Overlay | AboutDialog | ActionBar | ShortcutLabel | Viewport | Grid | GridView | ProgressBar | ShortcutController | EmojiChooser | Entry | PageSetupUnixDialog | SearchEntry | TreeExpander | AppChooserDialog | Dialog | FileFilter | EveryFilter | Text | ListBoxRow | ShortcutsGroup | ColorButton | FlowBox | Scale | DropDown | FontChooserWidget | FileChooserWidget | Label | FileChooserDialog | Stack | TreeViewColumn | PopoverMenuBar | Video | ComboBoxText | Picture | LinkButton | ConstraintLayout | Statusbar | Frame | StringList | CenterBox | MultiFilter | FontChooserDialog | CheckButton | CellView | MessageDialog | PasswordEntry | Calendar | Scrollbar | HeaderBar | SearchBar | ColumnView | ListBase | ToggleButton | ShortcutsWindow | DrawingArea | SpinButton | ScaleButton | TreeView | CellArea | Popover | ColorChooserDialog | ColorChooserWidget | StackSidebar | PrintUnixDialog | ShortcutsShortcut | ListStore | LockButton | ListView | ShortcutsSection | TreeStore | ComboBox | Fixed | TextTagTable | TextView | GLArea | AppChooserWidget | MultiSorter | MediaControls | Window | Notebook | Widget | SizeGroup | StackSwitcher | VolumeButton | Image | DragIcon | FontButton | AppChooserButton | Separator | ListBox | Expander | Button | PopoverMenu | EditableLabel | LevelBar | MenuButton | ScrolledWindow | Switch | Range | FlowBoxChild | InfoBar | Revealer | WindowControls | ApplicationWindow | AspectFrame | Assistant | WindowHandle): string =

[gavr123456789]

nim-lang/Nim#17420 (comment)
(((

[StefanSalewski]

instead of sum types.

I think you do not really mean sum types, as sum types refer to Nim's object variants.

I think you mean the or types which we use in gintro as substitute for interfaces?

Have you already working GTK code examples using concepts? Work they really better than our current solution? What are the advantages in detail?

in 2014 concepts where considered as not very reliable, and they where even moves to the experimental section. Some people reported for long compile times when using concepts. Is all that fixed with the new concept design?

[gavr123456789]

Have you already working GTK code examples using concepts?

No, this issue is for the future, now the concepts are in constant processing of ideas, as Yardanico informed me. But according to the existing RFCs, it is clear that they are most likely better suited than the or types. ( I and a few other people in the chat consider this to be generic constraints.

Here's an example of what it might look like.
Vala:

public interface ListModel : Object {
    public abstract Object? get_item (uint position);
    public abstract uint get_n_items ();
    public Object? get_object (uint position);
}

Nim:

type
  ListModel = concept
    proc get_item(position: uint): Object
    proc get_n_items(): uint
    proc get_object(position: uint): Object
    
# kind of interface implementation
proc get_item[T: ListModel](self: T) = 
   ...