Maciej Sobczak <prog@msobczak.com> writes:
Tcl *does* support many types. The problem is that there is no way to discover what is the "current" type of the variable at any given time, because in Tcl a variable can be only converted to reqested type, which can fail or succeed. As a result, I don't see how to implement for example function overloading there. In Python (and in other languages, I think) you can ask what is the type of the variable and get some enum or other type descriptor. In Tcl you can only *try* to convert to any target type. Having a list of types, you can try to convert a given value to all of those types - some will succeed, some will fail...
Actually, that model is almost exactly what Boost.Python uses to do its conversions at function call boundaries, and basically everywhere else. Knowing the source Python type can make the "try" to convert to some type a bit faster, but that's really an implementation detail of the converters.
RE, object vs. procedural: Just like the original C++ implementation mapped to the procedural C, one can perform an equivalent mapping in scripting languages. And you have done this in your TCL binding library so I don't see your issue with it.
There is a lot of cheating there and I'm not comfortable with the idea of inheritance and virtual functions, for example. The way you do this in Python is a lot different from what you can or cannot do in Tcl.
Example 2: Tcl has an object-based approach to interpreters and there can be *many* of them
Same with Lua (and hence LuaBind), and almost the same with Python.
Sorry, the last time I checked it was virtually impossible to have two Python interpreters that would not share any state. This was needed and I failed to see how to do this (even using the low-level Python API), whereas it is straightforward in Tcl.
It doesn't matter, though. Independent interpreters is easy (and often used) in Lua, and that's not at all in conflict with the notion of langbinding.
2. I don't see any *benefit* from building such a "universal" thing. I think that users of different scripting languages form rather disjoint audiences and any overlap here is too small to justify the effort to create a universal language binding.
I think many of the users of other universal binding platforms out there would disagree with you here, for example all the people who use CORBA.
I don't think that the same people are interested in interfacing to *different* languages - that was the point. There are some who want to interface with Python, some who want to interface with Tcl, etc., but I'm not aware of anyone who would ask for more than one language binding.
C++ library authors, in particular, would like to produce bindings for their libraries that work with multiple languages.
Thus, the only purpose of building a "universal" binding would be to have the potential of code reuse and would target not final users, but designers and developers of new bindings - and this is something which I don't believe in. The reasons are as described previously - extreme amount of work, much higher than that needed to create separate bindings, even if each one is implemented separately from scratch, just as was the case with C++/Tcl.
The langbinding library itself is a bit of work to do, but there's absolutely no reason that using it should impose more work than using Boost.Python, Luabind, C++/Tcl, or any of the others. -- Dave Abrahams Boost Consulting www.boost-consulting.com