[Python-ideas] Method chaining notation

[Stephen J. Turnbull]

spir writes:
 > On 02/23/2014 06:06 AM, Andrew Barnert wrote:
 > > All you're arguing here is that PyGtk is badly designed, or that
 > > Gtk is not a good match for Python, so you have to write
 > > wrappers. There's no reason the wrapper has to be fluent instead
 > > of declarative.

 > That's what I was about to argue. I don't understand why the python
 > wrapper does not let you construct widgets in one go,

*Because* it's a *wrapper*, which leverages the gobject-introspection
FFI.  (gobject-introspection is an export-oriented FFI, rather than an
import-oriented FFI like ctypes.)

 > with all their "equipment", since it's trivial and standard style
 > in python (except, certainly, for adding sub-widgets to containers,
 > as the sub-widgets exist and need to defnied by themselves).

I don't think you need to except subwidgets.  They could be defined
recursively by including calls to their constructors in the
"description" of the parent.  It might be tricky to find a pleasant
way to express placement in containers with flexible placement
disciplines, but for single-child, column, row, and grid widgets I
don't see a problem at all.

Now, that would be nice for initialization, but the GTK+ v3 API is
very dynamic and insanely complicated.  I think it would take a huge
amount of work to do this at all well, and I suspect that your program
would benefit only from beautification of initialization -- everything
else would still look the same.  (Of course many programs don't need a
dynamic UI; I suppose that would be a benefit.)

In any case, I don't find a "chained" API for something like GTK any
more attractive than the repetition of object being mutated.  They're
both quite ugly, an accurate reflection of the underlying library
which tried to be a better Xt, but ended up equally messy, compounded
by being a lot bigger (and more poorly documented).