Rene Rivera wrote:
Tcl *does* support many types.
Is that support internal? Or is it lexical?
It's internal. In fact, the internal representation of type is something kind of union that keeps and caches "the last used representation". It was different in early versions of Tcl where everything was string, but for some time the internal representation is typed for obvious performance reasons. For example: set i 7 incr i After this, 'i' is a variable that holds value 8, which internal representation is integer, since this is how it was used the last time. If you want to again use 'i' as a number, no conversion is needed and the operations will be performed directly on the integer representation. However, if you do this: set j [string length $i] then 'j' will be set to... 1 (a number), because that's the string-wise length of 'i' and because the last used representation of 'i' is now string ("8"), it will be stored as a string from now on. Until, of course, you will try to use it as something else, when it can again change its internal representation.
I must say that's a big annoyance.
Depends on what you want to do. It is just the way it was done and from the Tcl point of view there is nothing bad with it. Moreover, there is still nothing bad if you interface with C. The problem begins only when you try to do something "modern" in C++ binding and totally breaks with function overloading, for example.
Only thing I can think of to do is that in the TCL binding case the call dispatch just has to try each, in some preferred order, until something, or nothing works.
In what purpose? I don't try each, I just don't overload commands. The command name unambiguosly leads me to the list of expected types (one for each parameter position) and I *know* the target type, so no need to "try" until found. If the conversion fails, then the parameters are just wrong. This greatly simplifies the library and, what's most important, is not surprising to Tcl programmers. It may be seen as limitations from the C++ side ("I cannot export my funky set of overloaded functions!"), but I don't see it being a problem in so-called "practice", at least in the domain where I use it.
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.
Interestingly I'm one of those asking for more than one language :-)
Cool! Are you using more than one scripting language? Then, use for example Boost.Python to export to Python and C++/Tcl to export to Tcl. I think you can even squeeze the definition blocks in the same .cpp file, or even help yourself with some preprocessor stuff to reduce code repetition. The fact that these two do not share any logic internally does not change the way you can use it.
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.
That might be true for TCL, but as Dave said it's not true for Python and Lua. And likely is not true for most object oriented languages.
And I don't question it. I'm just convinced that for any framework there exist a language that does not fit. Knowing Tcl a little bit I'm convinced that it will not fit into langbinding, whatever it ends up to be. Having said that, there are three things that will never fly at Boost: - universal language binding - universal database access lib - universal GUI framework The whys of it are not only technical. I think that Boost is old enough (and has deep enough mail archives ;) ) to back this claim. This is my very *humble* opinion of course, and I wish Boost that I'm mistaken.
Just voicing opinions as an interested party.
-- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/