Re: Langbinding.Tcl (was: copyright issues)

Hi,

David Abrahams wrote:
> Maciej (or should I call you Sobczak, as you once signed an email?),

My first name is Maciej.

> Please make sure that Daniel Wallin is included in all email
> regarding langbinding.  In fact, it would be better if we could
> pursue this entire discusson on the langbinding mailing list.

Which I therefore do.

> 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 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++. Consider:

setActiveVector(v1);

push_back(...);
push_back(...);

setActiveVector(v2);

push_back(...);


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

>>BTW - Tcl has also another nice feature [...]
>>Simply - a sandbox where no damage can occur.

> That's nice, but it has no bearing on the viability of Langbinding.

Sure!

> 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. Yes, 
the type safety goes to hell, but... there was no type safety there, 
never, remember? :)

Here's the draft of what I do:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/cpptcl/doc/classes.html?rev=1.1

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. This new command is used to "execute" member functions.
When the object is destroyed, its associated command is unregistered 
from the interpreter.


> 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.


>>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:

// imaginary C++ implementation of Tcl internals
class TclObject
{
public:
     // ...
     void setString(string const &s);
     void setInt(int i);
     // ...

     string getString() const;
     int getInt() const;
     // ...

private:
     mutable string strRepresentation;
     mutable int intRepresentation;
     // ...

     mutable enum {eString, eInt, ...} eLastUsedAs;
};

// and, for example:

void TclObject::setInt(int i)
{
     intRepresentation = i;
     eLastUsedAs = eInt;
}

int TclObject::getInt() const
{
     if (eLastUsedAs == eInt)
     {
         return intRepresentation;
     }
     else
     {
         convertWhateverWasLastUsedToInt();
         eLastUsedAs = eInt;
         return intRepresentation;
     }
}

So - you do not have to worry about caching. This is internal business.

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? ;)


> 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. However, *time permitting*, I might offer my 
hands to boost.landbinding.tcl. I will be monitoring the mail list anyway.

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8