Tcl Source Code

Tcl_ObjType(3) states that writers of new object types
need to
call tcl_RegisterObjType.  tk, for one, does not do
this
with any of the ObjTypes it manipulates.  It certainly
is not
self-evident that extensions can maintain private
Object
types unknown to the tcl core.  If maintaining private
Object types is considered legal,  then the Tcl_Obj(3)
man page
should state this.

For example, tcl might decide to verify that typePtr in
the
Tcl_Obj structure is something valid, possibly by
checking
against the registered types.  This would break tk.

Logged In: YES 
user_id=72656

I'm going to leave it as-is, because while it is 
not "necessary", I think it is the good citizenship thing 
to do.  I don't see the problem in making people 
(suggesting that they) register when it isn't strictly 
necessary in the code.

Logged In: YES 
user_id=79902

Checked in.  I'll let Jeff figure out whether to close this
bug... :^)

Logged In: YES 
user_id=80530

So membership in the internal stub table is just a
judgment call, then?  In that case, I agree it's
not helpful to put it in.

The patch looks good.  I've applied it and no new
test failures result.  If you're looking for 
approval for commit, you've got it from me.

Logged In: YES 
user_id=79902

I don't think its useful to put TkRegisterObjTypes() in the
stub table; it only really needs calling when Tk is first
loaded (currently it is called immediately after stub table
initialisation IIRC, which should be good enough.)  Calling
it again will just keep the reinit the types to the same
value, which ought to be harmless enough...

Logged In: YES 
user_id=80530


Much better.  One more question:  should the new
internal function TkRegisterObjTypes() go into
the internal stub table ?  How does one decide
whether a new non-static internal function goes
in the internal stub table or not?

File Deleted - 9520:

File Added - 9564: tkobj.patch

Logged In: YES 
user_id=79902

That's a much larger change, and Tk wasn't exactly clean in
that respect either.  Still, here's a revised version (which
is also unfortunately a much larger patch...)

Logged In: YES 
user_id=80530


The Tcl_ObjType's that are no longer static
after this patch is applied -- shouldn't
they be renamed to have a "tk" prefix?

Logged In: YES 
user_id=148712

Comments and patch clearly mark this as a Tk bug. Jeff, I'm
passing the ball to you :)

File Added - 9520: tkobj.patch

Logged In: YES 
user_id=79902

Here's a patch to fix Tk by registering all its object types

Logged In: YES 
user_id=80530


I agree with this report that Tk ought to
register its Tcl_ObjType's with appropriate
calls to Tcl_RegisterObjType.  This would
allow things like Tcl_ConvertToType to work
with the Tk types.

From that perspective, this is a Tk bug.