Tcl Source Code

View Ticket
Login
Ticket UUID: 1779249
Title: alternate var and command resolver
Type: RFE Version: None
Submitter: wiede Created on: 2007-08-22 08:23:05
Subsystem: 45. Parsing and Eval Assigned To: msofer
Priority: 5 Medium Severity: Minor
Status: Open Last Modified: 2015-07-21 16:37:00
Resolution: None Closed By: nobody
    Closed on:
Description:
The purpose of this RFE is to to provide a different api for namespace/interp variable and command resolvers. It is based on a CallFrame dependent interface, so only commands which want to use it will get involved. The idea is for variables to look them up in a different namespace, for commands to look up constructs like ns1::command1 (no :: at the beginning!!) in a different namespace, which cannot be handled by namespace path.

For Itcl the usage is tohave all variables in subnamespaces of i.e. ::itcl::variables in an object specific namespace with the class namespace as a subnamespace for every class in the objects hierarchy

::itcl::variables::object1::class1::var1
::itcl::variables::object1::class2::var2
::itcl::variables::object2::class1::var1

for classes special command lookup for commands works as follows:
object1 class1::command1 will find a command in i.e. ::ns1::ns2::class1
and
object1 class2::command2 will find a command in ::ns3::class2 

The resolution using the stored resolvers is done using Tcl_FindCommand and Tcl_FindNamespaceVar. The call of these functions is dependent on a flag like FRAME_HAS_RESOLVER which has to be put into isProcCallFraem from the caller of the command (so it is only working locally)

A prototype implementation can be found in the attached file (this has been tested with a new Itcl implementation)
User Comments: dgp added on 2015-07-21 16:37:00:
Been swimming in the Itcl 4 sources lately, and just now got
led here to this core patch request.

I cannot vouch fully for what's proposed here; haven't reviewed
it.  But I can say that this points in the right direction, addressing
a pretty seriously fundamental flaw in the public interface Tcl/OO
offers to extensions.

Name resolution -- definitely variables, likely commands too -- is
very deeply a per-CallFrame operation.  Different callframes ought
to produce different resolutions.  Tcl offers no way at all to discover
the current CallFrame in its public interface, nor does it offer 
resolver hooks that key off CallFrame state.  All the existing resolver
interfaces are either interp-wide, or are attached to namespace contexts.
This isn't sufficient, as TclOO implementation itself demonstrates.

Look at ProcedureMethodCompiledVarConnect() in tclOOMethod.c .  In order
to perform var name resolution properly, it simply must read the value
of iPtr->varFramePtr .  There is no other way to do the job right.  Certainly
no way with only namespace info, and most certainly no way that respects NRE.

Truly a shame we dropped this ball so many years ago when Arnulf had
got us down to touchdown range.

dgp added on 2007-09-01 01:13:36:

File Added - 243781: 1779249.patch

Logged In: YES 
user_id=80530
Originator: NO


Here's the corrected patch in
more conventional format.
File Added: 1779249.patch

wiede added on 2007-09-01 00:34:43:
Logged In: YES 
user_id=558925
Originator: YES

dgp, sorry there is a one line bug in the attachement:
@@ -1257,6 +1260,23 @@
                localPtr->flags |= VAR_RESOLVED;
            }
        }
        if (frame_has_resolver &&
                !(localPtr->flags & (VAR_ARGUMENT|VAR_TEMPORARY)) &&
                (iPtr->varFramePtr->resolvePtr != NULL)) {
-            *resolvePtr = iPtr->varFramePtr->resolvePtr;
+           Tcl_Resolve *resolvePtr = iPtr->varFramePtr->resolvePtr;
            varPtr->flags = localPtr->flags;
            varPtr->value.objPtr = NULL;
            if (resolvePtr->varProcPtr != NULL) {
                    Var *resolvedVarPtr;

Arnulf

wiede added on 2007-09-01 00:17:57:

File Added - 243776: diff_resolver_20070831.txt

Logged In: YES 
user_id=558925
Originator: YES

File Added: diff_resolver_20070831.txt

wiede added on 2007-08-31 04:13:07:
Logged In: YES 
user_id=558925
Originator: YES

I will add an uptodate patch 
Arnulf

dgp added on 2007-08-30 23:35:26:
Logged In: YES 
user_id=80530
Originator: NO


The patch appears to be damaged.

Can you supply one that applies to
the current Tcl HEAD please?

wiede added on 2007-08-22 15:23:06:

File Added - 242260: CallFrameResolvers.txt

Attachments: