>> I would suggest that for now we leave the [info script] behavior >> alone. It doesn’t hurt anyone that I can see, and it would break > > do you mean you want to keep that ugly hack in Rivet_SendContent?
If you want to remove it, I’m fine with that. Just know that it creates an incompatibility. Now, what are the chances someone is using [info script] in Rivet to determine the .rvt file path? Probably slim to none seeing as [env SCRIPT_FILENAME] would be the more common method. All that said, it’s probably easier to just remove the hack and then stop trying to hack [info script] at all. If you want info about your Rivet request, use ::rivet::inspect. And then push people toward that in the docs. > we have ::rivet::inspect now (whose manual page needs further > elaboration). It's easy to place those variables in a new dictionary > returned by it. > > I chose the name 'inspect' to avoid conflict with 'info'. I new core > commands were in the namespace ::tcl but I didn't know they were an > ensemble and, as a matter of fact, I didn't know of the -map option of > namespace configure either I forgot about inspect. We should continue to enhance that command and remove any hacks like [info script]. A whole doc page on introspection would be nice as it would lay out exactly what you can query from Rivet. > OK, but I don't see it as the mine field it could look like at first. > The only problem I can think of is implementing a simple and safe way > for keeping the state of of a request processing and depending on it > calling either our implementation of 'info script' or Tcl's. The crux of > the problem is that we need to run our info script only during the > execution of any script/template referenced by the URL and call the > default implementation from any other script (ChildInitScript, > BeforeScript, AfterScript, ErrorScript etc). > > The method of remapping a Tcl command would make possible to simply > extend both 'info' and 'source' provided also this one is an ensemble > method. A URL referenced file name should be stored in the > rivet_interp_globals structure and a method of ::rivet::inspect could be > used to read it. I think everything could be done within > Rivet_ExecuteAndCheck but the transition between those 3 procedures > (where the state has to change in order to drive our wrappers of 'info' > and 'source') isn't marked by anything, as scripts are simply > concatenated and then executed. > > I think the problem is leaning more on mod_rivet rather than Tcl. I love that Tcl lets you override commands, including core commands. Other language purists can argue it’s a bad thing, whatever, I’m not interested in a debate. The problem is when you do it in a framework like Rivet where other people are expected to build on top of your work. Everything you rename and install your own proc over the top of creates another level of indirection and the added performance cost of a proc call. Which is bad, mmm’kay. ESPECIALLY if you do it to a command like [info] that gets called thousands of times per request. Currently, we don’t “override” anything. We just use Tcl’s already-provided mechanism (info script ?filename?) to set the script name within the Rivet request. Any call to [info script] still maps directly to the C function and costs nothing except setting the script once when setting up the request. I guess what I’m trying to figure out is what the hell all this is for. Remove the hack to [info script], that’s great. Note it in the CHANGES that we no longer do that and point them at ::rivet::inspect. But let’s not “fix it” by adding another hack somewhere else. If we want to extend ::rivet::inspect (which should also be an ensemble, by the way), then extend it to have an [inspect script] command or whatever. But let’s not fix one “hack” by hacking something else. Trying to override the source command and/or ::tcl::info::script just sounds like an all-around bad idea. What do we gain for the performance loss? What’s the point? And… who’s asking for it? Did someone get confused using [info script] and report a bug or ask for support that I missed? If you just want to remove the (arguable) hack, then remove the hack. D --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
