Menu
▾
▴
Re: [Swig-devel] Director support for Tcl
|
From: William S F. <ws...@fu...> - 2011-11-18 20:07:49
|
Sounds good, keep us posted on your developments and when you are happy
with your code, post your patch on the SF patch tracker for review.
William
On 18/11/11 16:04, Christian Delbaere wrote:
> Hi William,
>
> This is good feedback.I’ve changed “proxy” to “director”.Here is the
> updated proposal.
>
> Thanks,
>
> Christian
>
> *_Enabling Director Support_*
>
> The SWIG directives will be consistent with SWIG Python. Ex:
>
> %module(directors="1") modulename
> %feature("director") Foo;
> %feature("nodirector") Foo::bar;
>
>
> *_Tcl and incr Tcl_*
>
> SWIG can produce Tcl wrappers for standard Tcl as well as incr Tcl.
> incr Tcl mode is enabled with a command line option. This proposal only
> covers directors with incr Tcl mode *disabled*, but the general goal is
> to make future implementation of SWIG directors for incr Tcl possible.
>
> *_Defining Director Classes_*
>
> Support for directors requires the concept of a class definition
> including callable methods. Since plain Tcl does not have this
> capability built in, the SWIG Tcl director implementation will add a
> very basic mechanism to define director classes including callable
> methods written in Tcl.
>
> When a SWIG module with directors is loaded into the interpreter it will
> define a command called "SWIG_DirectorClass". The general form of the
> command will be:
>
> SWIG_DirectorClass /<className>/ /<baseClassName>/ {
>
> */method1 /*{ /self arg1 arg2 /... } {
> /script1/
> }
>
> *method2 *{ self arg1 arg2 ... } {
> script2
> }
>
> ...
>
> }
>
>
> Calling this command will create a new constructor-style command in the
> interpreter to create objects of type <className> that are "inherited"
> directors of <baseClassName>. The goal here is to reuse and extend the
> existing SWIG Tcl object infrastructure so that the director objects
> have identical behavior with other wrapped objects.
>
> Repeated calls to SWIG_DirectorClass for the same <className> will
> redefine the internal tables so that any instances of the director class
> (old or new) will have the most up-to-date methods.
>
> *_Example_*
>
> Given the following on the C++ side:
>
> %feature("director") Foo;
> class Foo {
> public:
> Foo(int foo);
> virtual void one();
> virtual void two();
> };
>
>
> then at the Tcl side, you can define:
>
> SWIG_DirectorClass myFoo Foo {
>
> one { self } {
> puts "one from tcl"
> }
>
> }
>
>
> Following this definition, you can create instances of the myFoo director:
>
> set foo [myFoo]
>
>
> The "one" method can be called from Tcl (just like any other SWIG Tcl
> objects):
>
> $foo one
>
> And of course, calling code in C++ will call the "one" Tcl method script
> passing in the wrapped object instance as "self".
>
>
>
> On 17 November 2011 02:42, William S Fulton <ws...@fu...
> <mailto:ws...@fu...>> wrote:
>
> Hi Christian
>
> Looks okay to me (but I know a bare minimum of Tcl). Only thing I'd
> say is that the terms used below should be director class instead of
> proxy class. In SWIG a proxy class is already one thing - a target
> language class proxying a C++ class with one to one mappings onto
> the C++ methods, and a director class is a proxy class plus
> additional functionality. The additional functionality of course is
> allowing a target language derived class to be created and be
> callable from C++.
>
> I don't quite understand why there are no proxy classes in the Tcl
> module or what the equivalent is though, perhaps you could enlighten me?
>
> The point is you suggest the term proxy (SWIG_ProxyClass) for the
> class that is derived from a director class (a director in itself is
> an enhanced proxy class). I'm just wondering if this is the best
> term as we already have a proxy class and an enhanced proxy class
> (director) and now this is the an additional type of proxy to muddy
> the waters. In the other language modules this has no name, it is
> just a plain class that inherits a SWIG director.
>
> William
>
>
> On 13/11/11 03:15, Christian Delbaere wrote:
>
> Here's a high-level proposal for how director support will
> operate in Tcl.
>
> _*Enabling Director Support*_
>
>
> The SWIG directives will be consistent with SWIG Python. Ex:
>
> %module(directors="1") modulename
> %feature("director") Foo;
> %feature("nodirector") Foo::bar;
>
> _*Tcl and incr Tcl*_
>
>
> SWIG can produce Tcl wrappers for standard Tcl as well as incr Tcl.
> incr Tcl mode is enabled with a command line option. This
> proposal only
> covers directors with incr Tcl mode *disabled*, but the general
> goal is
>
> to make future implementation of SWIG directors for incr Tcl
> possible.
>
> _*Defining Proxy Classes*_
>
>
> Support for directors requires the concept of a class definition
> including callable methods. Since plain Tcl does not have this
> capability built in, the SWIG Tcl director implementation will add a
> very basic mechanism to define proxy classes including callable
> methods
> written in Tcl.
>
> When a SWIG module with directors is loaded into the interpreter
> it will
> define a command called "SWIG_ProxyClass". The general form of the
> command will be:
>
> SWIG_ProxyClass /<className>/ /<baseClassName>/ {
>
> */method1 /*{ /self arg1 arg2 /... } {
> /script1/
> }
>
> *method2 *{ self arg1 arg2 ... } {
>
> script2
> }
>
> ...
>
> }
>
> Calling this command will create a new constructor-style command
> in the
> interpreter to create objects of type <className> that are
> "inherited"
> proxies of <baseClassName>. The goal here is to reuse and
> extend the
> existing SWIG Tcl object infrastructure so that the proxy
> objects have
> identical behavior with other wrapped objects.
>
> Repeated calls to SWIG_ProxyClass for the same <className> will
> redefine
> the internal tables so that any instances of the proxy class (old or
> new) will have the most up-to-date methods.
>
> _*Example*_
>
>
> Given the following on the C++ side:
>
> %feature("director") Foo;
> class Foo {
> public:
> Foo(int foo);
> virtual void one();
> virtual void two();
> };
>
> then at the Tcl side, you can define:
>
> SWIG_ProxyClass myFoo Foo {
>
> one { self } {
> puts "one from tcl"
> }
>
> }
>
> Following this definition, you can create instances of the myFoo
> proxy:
>
> set foo [myFoo]
>
> The "one" method can be called from Tcl (just like any other
> SWIG Tcl
> objects):
>
> $foo one
>
> And of course, calling code in C++ will call the "one" Tcl
> method script
> passing in the wrapped object instance as "self".
>
> Any feedback on this proposal is welcome.
>
> Thanks,
>
> Christian
>
> On 6 November 2011 07:35, William S Fulton
> <ws...@fu... <mailto:ws...@fu...>
> <mailto:ws...@fu....__uk
> <mailto:ws...@fu...>>> wrote:
>
> On 04/11/11 20:43, Christian Delbaere wrote:
>
> Hello,
> I see that SWIG does not currently support directors for
> Tcl. I am
> considering implementing this feature. Is anyone else
> working on it
> already?
>
>
> Christian, I havn't heard of anyone working on this, so
> please go
> ahead, it'll be a most welcome contribution. If you havn't
> already,
> please get familiar with the test-suite as I'll only accept
> contributions that keep the test-suite working and enhance it.
> Implementing directors is full of pitfalls and we havn't
> actually
> solved every single possible way of C++ and the target language
> interacting in this area. Fortunately for you we have many
> runtime
> tests in the existing languages. Probably you should
> translate all
> of them into Tcl. I think Python has the most extensive set of
> runtime tests. You can easily find the director test cases by
> searching for "director" in the .i files in the test-suite.
>
> William
>
>
>
>
|