Quoting Olaf Merkert (olaf@m-merkert.de):
Hi,
I ran into the next problem:
when I evaluate an expression like
(#_contains "Hello" "Hel")
I think that this is a reasonable restriction. Arguments to method calls undergo automatic conversion from Lisp types to C++ objects if possible in many cases.
But the instance on which a method is being called needs to be a C++ object. So you need to make (and later free) a new QString explicitly in this case.
The reason is that, at this point during (actually, before) method resolution, there is no context to decide what to do. For method arguments, we know which possible argument types to choose from. That isn't the case for instance object.
(Thinking in terms of examples for possible difficulties: CommonQt already supports non-QObjects to some extent. What if we start supporting std strings? We certainly don't want to start guessing whether QString or string was intended. I admit that this example is a bit contrived, but I still wouldn't want to commit to special-casing QString. And what's next? Byte arrays as target objects, getting converted to QByteArray? Lists of things?)
And comparing to other implementations: I believe most other smoke bindings are strictly object-oriented, and the idea of invoking a QString method on the built-in language type for strings would be even more foreign to them than for Lisp.
It would be nice if you didn't have to call #_new manually though; perhaps there could be macro for that. (with-qstring perhaps?)
d.