About TIP#214: Add New Object Introspection Command
Alexandre Ferrieux
pages on www.tcl.tk don't clearly indicate a better channel... or do
they ?)
TIP#214: http://www.tcl.tk/cgi-bin/tct/tip/214
is more than 2 years old, but still pending a TCT vote.
It proposes to introspect the current representation of an object, to
avoid shimmering.
This is an excellent ambition. But, contrarily to TIP#117 which it
obsoletes, it does so through one level of indirection (a varname):
TIP#117: objtype ?value?
TIP#214: info representation ?varname?
May I ask why this change was made ?
What is the added value of going through one var dereference ?
-Alex
PS: I know about the TCT mailing list archive, but (1) the search
interface is awful (results not threaded), and (2) in this precise case
I found a message by Don Porter
http://aspn.activestate.com/ASPN/Mail/Message/2373172 which made me
even more perplex...
Michael Schlenker
voted for state. If a vote would be called it would probably be rejected.
Introspecting a Tcl_Objs current internal representation is maybe useful
for debugging. But as you state it 'excellent ambition' is exactly the
dangerous state of mind why this probably won't happen, as it is easily
misused for ordinary scripts to introduce types into the Tcl scripting
layer. If your script relies on the fact that no shimmering occurs in a
specific operation it may blow up in any patch release because those are
private and internal details of how Tcl or an extension manages its
objects. A normal script should not need to know the internal type of a
Tcl_Obj. The abstraction between the C layer/internals and the script
layer may be a bit leaky when performance is different due to
shimmering, but in general a Tcl script should not need to know whats
really going on at the C level.
What is your usecase for such functionality? Debugging? Runtime checks
for performance reasons?
Michael
Alexandre Ferrieux
Michael Schlenker wrote:
> I think Don Porter summarized quite good why this is still in the not
> voted for state. If a vote would be called it would probably be rejected.
I understand the objections for the overall concept (both 117 and 214).
What I don't understand though, is why it is clearly NO for 117 but
leaves room for hesitation for 214, while to me 214 is just 117 plus an
extra level of indirection...
> What is your usecase for such functionality? Debugging? Runtime checks
> for performance reasons?
The latter, as far as I'm concerned. But I do realize that script-level
access is not a good idea. Instead, a simple runtime flag like
::tcl_traceShimmer, dumping on stderr, would be perfect. (and a bit
better than an earlier proposal to make it a build flag: I want to be
able to switch the shimmer-microscope on only for specific routines).
-Alex
Kevin Kenny
> I understand the objections for the overall concept (both 117 and 214).
> What I don't understand though, is why it is clearly NO for 117 but
> leaves room for hesitation for 214, while to me 214 is just 117 plus an
> extra level of indirection...
In brief: 214 is still there because nobody's troubled to call the
vote. 117 got voted down in an earlier cleanup.
>>What is your usecase for such functionality? Debugging? Runtime checks
>>for performance reasons?
>
>
> The latter, as far as I'm concerned. But I do realize that script-level
> access is not a good idea. Instead, a simple runtime flag like
> ::tcl_traceShimmer, dumping on stderr, would be perfect. (and a bit
> better than an earlier proposal to make it a build flag: I want to be
> able to switch the shimmer-microscope on only for specific routines).
I think that better still would be to put internal representation
introspection into a 'tclObjDebug' package that can be
[package require]d, with documentation deprecating its use in
deployed applications. I don't believe that we need to go to
the extent of forcing the user to enable it at compile time,
although I'm willing to go along with that if the rest of the
TCT feels strongly about it.
I also want to deprecate Tcl_ConvertToType. That routine has
no legitimate application.
--
73 de ke9tv/2, Kevin
Kevin Kenny
> I understand the objections for the overall concept (both 117 and 214).
> What I don't understand though, is why it is clearly NO for 117 but
> leaves room for hesitation for 214, while to me 214 is just 117 plus an
> extra level of indirection...
In brief: 214 is still there because nobody's troubled to call the
vote. 117 got voted down in an earlier cleanup.
>>What is your usecase for such functionality? Debugging? Runtime checks
>>for performance reasons?
>
>
> The latter, as far as I'm concerned. But I do realize that script-level
> access is not a good idea. Instead, a simple runtime flag like
> ::tcl_traceShimmer, dumping on stderr, would be perfect. (and a bit
> better than an earlier proposal to make it a build flag: I want to be
> able to switch the shimmer-microscope on only for specific routines).
I think that better still would be to put internal representation
Uwe Klein
> Michael Schlenker wrote:
>
>>I think Don Porter summarized quite good why this is still in the not
>>voted for state. If a vote would be called it would probably be rejected.
>
>
> I understand the objections for the overall concept (both 117 and 214).
> What I don't understand though, is why it is clearly NO for 117 but
> leaves room for hesitation for 214, while to me 214 is just 117 plus an
> extra level of indirection...
>
>
>>What is your usecase for such functionality? Debugging? Runtime checks
>>for performance reasons?
I had seen it on the web but can't remember where.
uwe
Uwe Klein
>
> uwe
not pincer but tweezer:
http://wiki.tcl.tk/13230
http://lehenbauer.com/software/tweezer/
uwe