Posted to tcl by auriocus at Fri Jan 26 06:28:58 GMT 2018view raw

  1.  
  2. Hi Kevin,
  3.  
  4. thank you for this review list. Find below a few comments from my side.
  5.  
  6. Am 25.01.18 um 01:31 schrieb Kevin Kenny:
  7. > Continuing to slog my way up out of the pit of the archaeologic
  8. > excavation and ascend toward the present day:
  9. >
  10. > * TIP 180: Add a Megawidget Support Core Package
  11. >
  12.  
  13. 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:
  14.  
  15. https://chiselapp.com/user/aspect/repository/snot/index
  16.  
  17. 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:
  18.  
  19. https://wiki.tcl.tk/14638
  20.  
  21. 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.
  22.  
  23. 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.
  24.  
  25.  
  26. > * TIP 192: Lazy Lists
  27. >
  28. > This is essentially a proposal to implement generators: objects that
  29. > appear to be lists, but whose content, and perhaps even length, are
  30. > not known until queried. This is surely interesting functionality -
  31. > Python makes use of it heavily - but this is a proposal with truly
  32. > subtle and profound implications.
  33.  
  34. 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:
  35.  
  36. https://www.youtube.com/watch?v=7mCDd-h89gQ
  37. http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/EuroTcl2016-Gollwitzer-EIAS.pdf
  38.  
  39.  
  40. >
  41. > I'm all for having 'iterator' API's, and for having [foreach] work on
  42. > them. For instance, there is no good reason for having [dict for]
  43. > separate from [foreach] other than the fact that its iteration
  44. > mechanism has a different implementation.
  45.  
  46. 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.
  47.  
  48. > * TIP 193: Simple Syntax Help System
  49. >
  50. > This draft is very much a draft - there are numerous 'ToDo' paragraphs
  51. > and a dearth of concrete specification. Donal, are you still
  52. > interested, or have we moved beyond this one?
  53.  
  54. 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
  55.  
  56. >
  57. > * TIP 198: Image Command XPM Extension
  58. >
  59.  
  60. 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.
  61.  
  62. > Given the widespread acceptance of the Img
  63. > extensions, my initial reaction is 'No.'
  64.  
  65. Fully agreed.
  66.  
  67. Christian
  68.  
  69.