What sorts of introspection are there? What sorts should there be? This is the omnium gatherum of introspective issues in Tcl.
Please add to this if you can. Examples and discussions of implementation issues are particularly welcome!
See the Introspection package by Bruce Adams too.
See tkinspect.
DKF
What have I missed? :^) - DKF
Just noting that my inspiration for the last two on the list is to enable the creation of monitors (written in Tcl) for safe-Tcl interpreters to stop a whole extra bunch of denial-of-service attacks. That they would be useful for other things is just a happy bonus...
DKF
AK
OK, for channels, I suppose we want to know what channels are available, and whether they are opened for reading and/or writing (in addition to the information currently available with [fconfigure], that is.) We do not want to have a mechanism for determining if a particular channel is ready for reading or writing, since we want to enforce the use of the event-based mechanism. Do we want to have introspection of the event system?
Being able to tell if a particular command is an alias (and what it is an alias to, if that is in the same interpreter) would be nice. In fact, it might be nice to have a mechanism that says what kind of command a particular name is referring to. The kinds that people ought to be able to ask about (for commands in their own interpreter) should include:
Why not let programs introspect on aliases coming in from other interpreters? Well, this might allow a script running under SafeTcl to figure out exactly what commands were being monitored by its interpreter's master. This information is probably not useful in any respect - though I cannot see how it could be used to damage the integrity of the system, you cannot give a name for an interpreter that is not yourself or a child of yourself. In other words, there is no meaningful value that the introspection system could return!
DKF
AK
What resources (X, Windows, Mac) does a particular widget or command use, what values can that resource hold?
What environment variables does a particular command or widget use?
LWV
Isn't the first Tk introspection, and not Tcl introspection? Not that it is a bad thing, but...?
The second is probably not always possible to tell without actually running the code (computed env-var names!)
DKF
Besides Bruce's package, what tools are available for introspection? Does anyone know of anyone interested in supporting Tkinspect?
Well - I've been doing that for a bit now. It's being done within the tkcon project in sourceforge. Look to http://sourceforge.net/projects/tkinspect The current version has support for inspection when used with windows and can cope with incr tcl and namespaces. There is also tixinspect PT
What about registered signal handlers? Generally overlooked, but an important behavioural characteristic of programs. I've always wished that sighandlers had become a standard 'section' of man pages.
ATW
I've always thought that TCL's greatest introspection feature was most powerfully demonstrated by the rmt demo. Being able to determine the command set of another application at runtime is pretty useful introspection. A nice extension to rmt would be to actually have it query the other app and build a menu dynamically!
ATW, again :)
EE: If you liked the rmt demo, you'll love tkcon... building a menu of available commands, though? why? just do [lsort [info commands]]], and you've got the complete ordered list.
escargo 4 Dec 2002 - I was losing some sleep over some questions having to do with introspection and GUI Building Tools. If I have a GUI Building Tool, and I update my implementation of Tcl/Tk (say from 8.3 to 8.4), is it possible for the tool to know about new commands (e.g., panedwindow, labelframe), so that it can, through introspection, automatically be able to create GUIs using them.
Similarly, what would user-created megawidgets need to do to be able to make themselves known as widgets by the GUI Building Tools so that they could automatically be known.
In a full object system with inheritence or interfaces or protocols, new objects that obey the right protocol could be automatically managed. In Tcl and Tk, if I develop a new geometry manager, how would a GUI builder know that it existed and how to communicate with it?
Certainly individual commands that obey cget and configure will respond with their options, but how would a GUI builder know that a command produces a container or a widget that can be put into a container? Or that it's something as exotic as a new geometry manager that puts things into containers?
I see this as a way of using introspection to keep GUI Building Tools from becoming obsolete, and to easily be extended with new widgets (or even new OO extensions).
LV See also Browse available extensions and their commands.
Event Loop: How to tell if there is an event loop running? How to tell if a new '''vwait''' might not be conflicting with existing vwaits? (See the bottom of [vwait] wiki page.)