Re: [TCLCORE] RFE for new variable and command resolver API

[Will D. <wi...@wj...>]

This appears to be a change to the C interface; as Snit is
pure-Tcl, there's no immediate benefit.  It sounds interesting,
though.

Will

On Aug 23, 2007, at 7:27 AM, Tom Krehbiel wrote:

> Miguel, Arnulf,
>
> Bravo! For working on rationalizing OO within the tcl core. Are  
> Will Duquette
> (snit) and Uwe Zdun (XOtcl) aware of this work? If not it would be  
> a good idea
> to get their take on the changes. It would be great if this work  
> could also make
> life easier for them.
>
> Tom Krehbiel
>
>> Arnulf Wiedemann wrote:
>>> I have posted a RFE on SF for a new variable and command resolver
>> API: 1779249
>>>
>>> Here is a description on what it should do:
>>>
>>> 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.
>>
>> My take on this is:
>>
>> (a) the resolvers are a bit of a pain in the core. AFAIU, their only
>> user is itcl
>>
>> (b) Arnulf is writing a brand new itcl code running on top of TclOO
>> (bravo!), and trying his utmost not to require internal Tcl apis or
>> structs (BRAVO!!). It does require special name resolution under some
>> circumstances
>>
>> (c) We discussed, and he implemented in this patch, the  
>> possibility to
>> flag the current CallFrame to have special resolution rules for  
>> commands
>> and/or variable names. This will typically be used by commands  
>> that push
>> a CallFrame.
>>
>> This is much cleaner than what we have now - both interp and  
>> namespace
>> resolvers take over the core's resolution, even when the extension's
>> code is not running. With this new approach, every non-itcl piece of
>> code works normally, without interference. If a command requires  
>> special
>> resolution, it gets it - but it goes away as soon as the command
>> returns, and it is not inherited by normal Tcl code that it may eval.
>>
>> If we can *replace* the current interp|namespace resolvers with ones
>> specific to a CallFrame, I think it is a net win. AFAIK, itcl is the
>> only user of the current resolver infrastructure. It might even be
>> possible to modify the regular itcl to use this new approach.
>>
>> (I confess that I have not yet looked at the patch in detail)
>>
>> Miguel
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a  
>> browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills