From: Maciej Sobczak (prog_at_[hidden])
Date: 2005-10-03 02:27:24
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
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
> 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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk