Re: Langbinding.Tcl

Maciej Sobczak <[email protected]> writes:

> Hi,
>
> David Abrahams wrote:
>> Maciej (or should I call you Sobczak, as you once signed an email?),
>
> My first name is Maciej.

Hi Maciej,

First, congratulations on the first release of your library!  Second,
sorry it took me so long to respond.

>> It seems to me that at the very least you can set sys.path
>> differently and then you'll automatically load different modules
>> with the same names in the different interpreters.
>
> Ouch! :)

I'm not sure that's so painful.  Anyway, there are lots of low-level
hooks that can be used to control module loading.

>> ... I don't know what "emulating artifical scopes" means, but it
>> may not be as painful as you assume.
>
> By emulating artifical scope I mean something like this:
>
> setActiveInterp(i1);
>
> def("fun1", fun1);
> def("fun2", fun2);
>
> setActiveInterp(i2);
>
> def("fun1", fun2);
>
> I find it extremely non-C++. 

Of course.  That's why we have modules.  Modules in langbinding are
language-independent data structures that capture the neccessary
information to wrap... (ahem)... a module.  They can be selectively
loaded into various interpreters later.

For example:

  CPPTCL_MODULE("Mymodule", i)
  {
      langbinding::tcl::bind(
          i, langbinding::load_module("Mymodule"));
  }

in this case, langbinding::load_module is a function that loads a
dynamic library (plugin) object containing the language-neutral
wrapping code:

  module_desiption my_module = 
      module("Mymodule")
      [
          class_< ... >
               .def( ... )
               ...
               ;
      ]

Of course, many people won't care about being able to use one copy of
their wrapping code with arbitrary languages.  They can write:

  CPPTCL_MODULE("Mymodule", i)
  {
      langbinding::tcl::bind(
          i

        , module("Mymodule")
          [
              class_< ... >
                   .def( ... )
                   ...
                   ;
          ]

      );
  }


> I still would like to use different interpreters in separate threads.

Of course.  I don't really see the relationship, though.

>> But not for many user-defined classes.  I assume you _are_ going to
>> support wrapping of C++ classes somehow...?
>
> Yes, although there's a trick in it. I wrap pointers into
> strings. 

I expected something like that.

> Yes, the type safety goes to hell

No more than in Python.

> but... there was no type safety there, never, remember? :)

Not sure what you mean by that.  There's dynamic type safety,
surely?  And on the C++ side there's static type safety.

> Here's the draft of what I do:
>
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/cpptcl/doc/classes.html?rev=1.1

Yes, it's what I expected.

> What's interesting: when the object is created, its address is
> returned in the encoded string form and this sting is immediately
> registered as a new Tcl command. 

Oh.  Well I would tend to use a slightly more descriptive string
(e.g. include the C++ type name), but maybe you have performance
reasons for doing it that way.

> This new command is used to "execute" member functions.  When the
> object is destroyed, its associated command is unregistered from the
> interpreter.

Sounds good.

>> I disagree with your conclusion.  Nobody had overloading in Python
>> either, but it's very much appreciated that a C++ interface that
>> includes overloading can be exposed to Python in a fairly transparent
>> way.
>
> I understand that. On the other hand, I found myself writing Tcl and
> C++ in paraller, which means that usually I can design my C++
> interface (or at least the part that I know I will expose) with the
> Tcl limitations in mind.
> Of course, it depends on what you do.

Right.  If you want to make a general-purpose wrapping library that
will be widely adopted, it makes sense to accomodate other common
usage models.  One of the most important is the non-intrusive
wrapping of an existing C++ interface.

>>>Interestingly, internally, everything is manipulated as "object"
>
>> How can you know when the cache needs to be invalidated?
>
> The object interface is equivalent to this:

<snip explanation of icky Tcl internals>

Yuck.  Well, thanks for the explanation... I think ;-)

> What's worse, Tcl has also lists, so that:
>
> fun "I have 7 cars"
>
> The above calls a command fun with a single parameter.
> This parameter is a string (if you wish!), but it may also be a list
> (if you wish!), and then it has length 4. Third element of this list
> is "7", so you can for example increment it as integer (if you wish!)
> or get its strlen (if you wish!), which is 1.
>
> Funny, isn't it? ;)

Hilarious!

>> Our aim with langbinding is to factor out the commonality between all
>> such libraries (and there is very, very much!) so that your job is
>> reduced, mostly, to figuring out how to "exploit all Tcl goodies."
>
> I'm finishing with my library anyway, so there is no reason to abandon
> it in this late phase. 

Fortunately, I wasn't suggesting that you should.

> However, *time permitting*, I might offer my hands to
> boost.landbinding.tcl. I will be monitoring the mail list anyway.

Great news!  Welcome aboard.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/