Mail to Tcl core 25.01. 08:20

Hi Kevin,

thank you for this review list. Find below a few comments from my side.

Am 25.01.18 um 01:31 schrieb Kevin Kenny:
> Continuing to slog my way up out of the pit of the archaeologic
> excavation and ascend toward the present day:
>
> * TIP 180: Add a Megawidget Support Core Package
>

Actually, a core megawidget package is surely missing. At the moment, the most flexible one is Snit, which uses its own object system.  What is needed IMHO today is a "TkOO" megawidget system which comes with the core. Fortunately, there exists a project which ports over most of the Snit functionality to TclOO:

    https://chiselapp.com/user/aspect/repository/snot/index

There are a few (minor?) things still missing: delegate options and widgetadaptors. snit::widgetadaptor is a megawidget which modifies an existing widget and makes some interesting designs possible; for example adding traits to existing widgets, like an "undo" functionality which can be added to both entry, ttk::entry or ttk::combobox. See:

    https://wiki.tcl.tk/14638

I think that with a little bit extra work this "snot" could become the core-blessed TkOO package. Another option is often mentioned by dkf: the Unix file dialogs are based on a small ad-hoc megawidget system (tk::Megawidget) based on TclOO. My gut feeling is that snot is much more usable as of today than tk::Megawidget, but maybe the latter one can provide some inspiration.

It is really hard to explain that a megawidget package is built into Tkinter (using Pythons object system) but you need 3rd party extensions when coding in Tcl, which use a different, incompatible object system than the core. My vote (though I can't vote) would be to deprecate this TIP in favour of one which adds a snot-based solution into the core.


> * TIP 192: Lazy Lists
>
> This is essentially a proposal to implement generators: objects that
> appear to be lists, but whose content, and perhaps even length, are
> not known until queried. This is surely interesting functionality -
> Python makes use of it heavily - but this is a proposal with truly
> subtle and profound implications.

A true generator thing is obviously a slight violation of EIAS - once you iterated over the list, the generator is exhausted. Will the values be cached? Will the generator start over? Are only "random access generators" allowed? You might find interesting my talk about Tcl-implementable Tcl_ObjTypes, which demonstrates lazy lists as one of the examples:

    https://www.youtube.com/watch?v=7mCDd-h89gQ
    http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/EuroTcl2016-Gollwitzer-EIAS.pdf


>
> I'm all for having 'iterator' API's, and for having [foreach] work on
> them. For instance, there is no good reason for having [dict for]
> separate from [foreach] other than the fact that its iteration
> mechanism has a different implementation.

YES PLEASE! But I think it should be first done in the C API side - this one will be tricky enough to get right. Script level is another problem, since the non-EIASness of the machine necessarily leaks through as soon as you allow this.

> * TIP 193: Simple Syntax Help System
>
> This draft is very much a draft - there are numerous 'ToDo' paragraphs
> and a dearth of concrete specification. Donal, are you still
> interested, or have we moved beyond this one?

I think TIP 457 "named arguments" covered this and much more. A named arg implementation could easily provide the help. The named arg spec would be the help as well as the implementation, which is a Good Thing because there can be no divergence between those two. Until there is no consensus on TIP 457 it'll make no sense to keep TIP 193

>
> * TIP 198: Image Command XPM Extension
>

The TIP text claims that XPM has become a "standard". This is outdated. The today's standard is PNG for which there is core support already.

> Given the widespread acceptance of the Img
> extensions, my initial reaction is 'No.'

Fully agreed.

    Christian