Re: [TCLCORE] The Big TIP Round-Up! (#60)

[David G. <dav...@po...>]

"Donal K. Fellows" <don...@ma...> wrote:

>David Gravereaux wrote:
>
>>The patch does take on a life of it's own for differentiating what
>>"exportable" really means.  All over tclInt.h you'll see prototypes for
>>functions not in the Stubs table but end-up being exported by using the
>>EXTERN macro.
>>
>>Honestly, I'm thoroughly confused..  If functions are meant to be in global
>>scope internally across the source files, why are they exported but not in
>>the private Stubs table?  All the Tcl_ObjCmdProcs are this way and some
>>variables that are structures, too.  Should they really be 'extern'
>>instead?  What is the reason for using 'EXTERN' on them?
>>  
>>
>
>As you know, any function that is referenced from outside the file in 
>which it is defined needs to be 'extern' in some sense.  But we need to 
>define what that sense is:
>
>    * Public API (in public stubs table) with hard guarantees about
>      compatability across versions
>    * Private API (in private stubs table) with best-effort guarantees
>      about compatability across versions
>    * Private Implementation (not in any stubs table) which should not
>      be called by anything outside the core ever, often because there
>      is either a different way to access the functionality or because
>      there's only half a piece of functionality there.  :^)
>
>Command implementations are all PrivImpl; if you want to call them, use 
>Tcl_EvalObjv() or Tcl_Eval() or ...

Tcl_CmdInfo info;
Tcl_GetCommandInfo(interp, "someCmd", &info);
if (info.isNativeObjectProc) {
   result = (info.objProc)(cData, interp, objc, objv);
} else {
   result = (info.objProc)(cData, interp, objc, argv);
}

We can always do that if needed.  So those really don't have to be
exported.  I've made Stubs tables for some extensions, and oddly, I've been
more comfortable placing the Tcl_ObjCmdProcs in its public Stubs table.
But that was for [Incr Tcl] because [Incr Tk] called a couple directly.
For the core, I could go either way, but would just like to see what we
export and what we Stubify to match a bit more than it does.

>Generally speaking, people have written EXTERN in any place where 
>'extern' was needed.  Mind you, this has worked just fine on Unix so 
>unless Windows people complain, it's unlikely to change of its own 
>accord.  ;^)

What I fear is that some people may actually be using functions (or
variables) that are exported but not in the Stubs table for special issues.

Just a quick look at the HEAD, and we have 922 exported symbols. In the
Stubs table (all combined) it looks like 676 give or take.  So there are
about 250 extra items being exported.

>Perhaps we need to assess the list of exported unstubbed functions and 
>determine whether they should be placed in the stub table.

Count me in.

>  After that, 
>would it be sufficient to change everything thats EXTERN but unstubbed 
>to extern?

Sure.

>  Can we rely on the standard stub headers to do the EXTERN 
>stuff for us and just use extern everywhere in the source?  (The last 
>one would be nice for people working with a number of source code tools.)

Yes.  Speaking of source code tools, Andreas Kupries mentioned to me that
EXTERN might be better prefixed as TCL_EXTERN as one person mentioned to
him it doesn't play well.  I don't remember the details.  It was something
about mixing tcl with other libraries.  It might have been a name collision
or just that EXTERN is just out-of-style by not being prefixed to show its
origin.

If we can rename it, and retain the old one too, adding the order shifting
aspect of the attribute should be painless.  two line changes in
genStubs.tcl and some more macro meat in tcl.h is all that it is.  In the
big picture, reviving Borland pre 5.5 compiler support isn't a particularly
gainful feature, but doesn't look to be all that painful either.

For variables that are getting exported, we might want to consider some
TclGet* functions if the reasons are valid.

>I don't think any of this needs to be done through the TIP process; 
>instead, it's more of a case of educating people into doing the right 
>magic for making things work with stubs.  We could sell that general 
>story fairly easily.
>
>Donal.

Donal, thanks for your time on this.
-- 
David Gravereaux <dav...@po...>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]