From: Christian D. <chr...@gm...> - 2012-03-21 20:47:35
|
I hope it's not too late to propose another project for this year's GSOC for SWIG. I have written a spec for director support under Tcl, and it would be great to see it implemented. Can this project be added? Here's the spec: *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". Thanks, Christian |
From: William S F. <ws...@fu...> - 2012-03-22 21:47:44
|
On 21/03/12 20:47, Christian Delbaere wrote: > I hope it's not too late to propose another project for this year's GSOC > for SWIG. I have written a spec for director support under Tcl, and it > would be great to see it implemented. Can this project be added? > > Here's the spec: > > *_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". > Hi Christian, I presume this is the polished version that was discussed on this mailing list in Nov 2011? I think this should be added to the ideas list. BTW, I understood you were going to implement this. Did you make any progress? Would you be willing to help in mentoring this project? William |
From: Christian D. <chr...@gm...> - 2012-03-23 17:43:13
|
Hi William, Yes, this is the polished proposal that we discussed in Nov. 2011. I did start development, and I would say that it's about 50% complete, but have been very busy and unable to dedicate enough continuous time to finish it off. Unfortunately I can't be a mentor, but I can provide my code so far to anyone who picks it up. Best Regards, Christian On 22 March 2012 17:47, William S Fulton <ws...@fu...> wrote: > > On 21/03/12 20:47, Christian Delbaere wrote: > >> I hope it's not too late to propose another project for this year's GSOC >> for SWIG. I have written a spec for director support under Tcl, and it >> would be great to see it implemented. Can this project be added? >> >> Here's the spec: >> >> *_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". >> >> Hi Christian, > > I presume this is the polished version that was discussed on this mailing > list in Nov 2011? I think this should be added to the ideas list. > > BTW, I understood you were going to implement this. Did you make any > progress? Would you be willing to help in mentoring this project? > > William > |
From: Ashish S. <ash...@gm...> - 2012-03-24 18:51:24
|
Christian, Do you have a public repo for your project? I can put a link to that on the ideas page along with the idea itself. -- Ashish On Fri, Mar 23, 2012 at 11:13 PM, Christian Delbaere < chr...@gm...> wrote: > Hi William, > > Yes, this is the polished proposal that we discussed in Nov. 2011. I did > start development, and I would say that it's about 50% complete, but have > been very busy and unable to dedicate enough continuous time to finish it > off. Unfortunately I can't be a mentor, but I can provide my code so far > to anyone who picks it up. > > Best Regards, > > Christian > > > On 22 March 2012 17:47, William S Fulton <ws...@fu...> wrote: > >> >> On 21/03/12 20:47, Christian Delbaere wrote: >> >>> I hope it's not too late to propose another project for this year's GSOC >>> for SWIG. I have written a spec for director support under Tcl, and it >>> would be great to see it implemented. Can this project be added? >>> >>> Here's the spec: >>> >>> *_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". >>> >>> Hi Christian, >> >> I presume this is the polished version that was discussed on this mailing >> list in Nov 2011? I think this should be added to the ideas list. >> >> BTW, I understood you were going to implement this. Did you make any >> progress? Would you be willing to help in mentoring this project? >> >> William >> > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > > |
From: Christian D. <chr...@gm...> - 2012-03-26 21:22:24
|
Hi Ashish, The code is not in a public repository. Interested developers can contact me via the swig-devel mailing list and I can send it. Thanks, Christian On 24 March 2012 14:51, Ashish Sharma <ash...@gm...> wrote: > Christian, > > Do you have a public repo for your project? I can put a link to that on > the ideas page along with the idea itself. > > -- > Ashish > > On Fri, Mar 23, 2012 at 11:13 PM, Christian Delbaere < > chr...@gm...> wrote: > >> Hi William, >> >> Yes, this is the polished proposal that we discussed in Nov. 2011. I did >> start development, and I would say that it's about 50% complete, but have >> been very busy and unable to dedicate enough continuous time to finish it >> off. Unfortunately I can't be a mentor, but I can provide my code so far >> to anyone who picks it up. >> >> Best Regards, >> >> Christian >> >> >> On 22 March 2012 17:47, William S Fulton <ws...@fu...> wrote: >> >>> >>> On 21/03/12 20:47, Christian Delbaere wrote: >>> >>>> I hope it's not too late to propose another project for this year's GSOC >>>> for SWIG. I have written a spec for director support under Tcl, and it >>>> would be great to see it implemented. Can this project be added? >>>> >>>> Here's the spec: >>>> >>>> *_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". >>>> >>>> Hi Christian, >>> >>> I presume this is the polished version that was discussed on this >>> mailing list in Nov 2011? I think this should be added to the ideas list. >>> >>> BTW, I understood you were going to implement this. Did you make any >>> progress? Would you be willing to help in mentoring this project? >>> >>> William >>> >> >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> >> > |
From: Christian D. <chr...@gm...> - 2012-07-23 18:00:50
|
Hi William, I am thinking about restarting development on this project. What is the procedure to get a branch made so that I can have version control? Thanks, Christian On 21 March 2012 16:47, Christian Delbaere <chr...@gm...>wrote: > I hope it's not too late to propose another project for this year's GSOC > for SWIG. I have written a spec for director support under Tcl, and it > would be great to see it implemented. Can this project be added? > > Here's the spec: > > *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". > > > Thanks, > > Christian > > > |
From: William S F. <ws...@fu...> - 2012-07-23 21:34:13
|
Hi Christian Sounds good. Please send me your SourceForge account name and then I'll configure your account and create a branch for you. William On 23/07/12 19:00, Christian Delbaere wrote: > Hi William, > > I am thinking about restarting development on this project. What is the > procedure to get a branch made so that I can have version control? > > Thanks, > > Christian > > On 21 March 2012 16:47, Christian Delbaere <chr...@gm... > <mailto:chr...@gm...>> wrote: > > I hope it's not too late to propose another project for this year's > GSOC for SWIG. I have written a spec for director support under > Tcl, and it would be great to see it implemented. Can this project > be added? > > Here's the spec: > > *_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". > > > > Thanks, > > Christian > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: William S F. <ws...@fu...> - 2012-07-23 22:11:45
|
Branch is ready: https://swig.svn.sourceforge.net/svnroot/swig/branches/delbaere-tcl. Happy hacking and good luck! William On 23/07/12 22:46, Christian Delbaere wrote: > Hi William, > > My SourceForge account name is "delbaere" > > Thanks, > > Christian > > On 23 July 2012 17:33, William S Fulton <ws...@fu... > <mailto:ws...@fu...>> wrote: > > Hi Christian > > Sounds good. Please send me your SourceForge account name and then > I'll configure your account and create a branch for you. > > William > > > On 23/07/12 19:00, Christian Delbaere wrote: > > Hi William, > > I am thinking about restarting development on this project. > What is the > procedure to get a branch made so that I can have version control? > > Thanks, > > Christian > > On 21 March 2012 16:47, Christian Delbaere > <chr...@gm... > <mailto:chr...@gm...> > <mailto:christian.delbaere@__gmail.com > <mailto:chr...@gm...>>> wrote: > > I hope it's not too late to propose another project for > this year's > GSOC for SWIG. I have written a spec for director support > under > Tcl, and it would be great to see it implemented. Can this > project > be added? > > Here's the spec: > > *_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". > > > > Thanks, > > Christian > > > > > > > ------------------------------__------------------------------__------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest > in malware > threats. > http://www.accelacomm.com/jaw/__sfrnl04242012/114/50122263/ > <http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/> > > > > > _________________________________________________ > Swig-devel mailing list > Swi...@li...urceforge.__net > <mailto:Swi...@li...> > https://lists.sourceforge.net/__lists/listinfo/swig-devel > <https://lists.sourceforge.net/lists/listinfo/swig-devel> > > > |