[Tcl-bugs] [Patch #103327] Fix for accepted Tcl Patch #102471 (it is Tk though)

[<no...@so...>]

Patch #103327 has been updated. 

Project: tktoolkit
Category: None
Status: Open
Submitted by: pgbaum
Assigned to : nobody
Summary: Fix for accepted Tcl Patch #102471 (it is Tk though)

Follow-Ups:

Date: 2001-Feb-01 21:59
By: dgp

Comment:
Some of the comments talk about caching of the object
type pointer, but the patch #103327 I see registered
doesn't do any caching.  Am I seeing an outdated
version of the patch?

Anyhow, the semantics for Tcl_RegisterObjType(typePtr)
do not support the caching of object types by extensions.
From Tcl_RegisterObjType(3):

    ...If the type table already containes a type with
    the same name as in typePtr, it is replaced with the
    new type.  ...

If we wanted the Tcl core to support caching of object
types by extensions, we would need to change
Tcl_RegisterObjType() so that it reports an error
(panics?) on the second attempt to register an object
type under the same name.

As is, Tcl_RegisterObjType lets extensions replace
object types with customized replacements.  (Though
in that case the extension has the responsibility of 
providing a compatible replacement -- much like an
extension which replaces one of Tcl's built-in
commands has the responsibility to provide a
compatible replacement.)

Looks like the choice is between letting extensions
cache object type pointers (efficiency) and letting
extensions provide customized versions of built-in
object types (extensibility) and that choice has
already been made in favor of extensibility.

So, the patch looks fine to me now, but the caching
idea won't fly.
-------------------------------------------------------

Date: 2001-Feb-01 07:37
By: dkf

Comment:
Hmm.  It is probably safe to cache the value of Tcl_GetObjType("double") in
a local variable; I don't anticipate it changing over the life of any
program.

Has anyone given any thought to what happens if I pass in an integer object
instead?
-------------------------------------------------------

Date: 2001-Jan-30 23:44
By: pgbaum

Comment:
After a short email discussion with Andreas Kupries:
here is the revised patch, which only uses the
tcl_Obj-interface. 

A short benchmark shows, that the difference in
execution time is low. So better use the clean
interface.
-------------------------------------------------------

Date: 2001-Jan-26 05:46
By: pgbaum

Comment:
You mean something like 

... SetMMFromAny( ... )
{
   static Tcl_ObjTyp *doubleObj = Tcl_GetObjType("double");
...
  if( objPrt == doubleObj )
...

that's definitely better!

Should "*doubleObj" be function local, file scope or global?
I don't want to make it global, because I want to have I
small patch, which is hopefully accepted faster.

But if I get a hint, what would be accepted, I make
a new patch.
-------------------------------------------------------

Date: 2001-Jan-26 05:40
By: pgbaum

Comment:
You mean something like 

... SetMMFromAny( ... )
{
static Tcl_ObjTyp *doubleObj( 
-------------------------------------------------------

Date: 2001-Jan-26 04:22
By: andreas_kupries

Comment:
The direct access through the typePtr of the Tcl_Obj is a bit icky. What
about querying Tcl for the pointer to the "double" type structure and
storing this in a Tk global ? Fast comparison without having to use
'tclDoubleType' directly. We simply get it through the approved API and
cache that.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=103327&group_id=12997