[Kde-bindings] Smoke: On classes and objects

[Luca Fascione]

Sorry if I insist on this, but my knowledge of the inner workings of 
both Perl (which I can kind of script with) and Ruby (which I just never 
used) I scarce at best...

Can we discuss the concept of classes and objects in the various 
languages for a minute? I am under the impression that the way we have 
to use Smoke this time is going to be quite different...

TCL doesn't have types and so doesn't have type control.

This is why I was proposing to do that {<type> <address>} trick, because 
you have to do type control yourself.

This way when you in TCL write

$myButton setText "OK"

on the C(++) side you end up in function call with an interface on the 
lines of

int myMethodCaller (/*some context information, like the interpreter 
address */,
    char* className,
    char* objPointer,
    char* methodName,
    int argc,
    char** argv)

whose body in turn I was imagining to be on the lines of

{
    /* ?check if the pointer and the type make sense together? */

    /* ask Smoke if the method is somewhere in the hierarchy of classes
       of the object pointed to by objPointer */

    /* ask Smoke to grab the interface of the actual method to be used */

    /* convert the data in argv as appropriate from its string 
representation */

    /* ask Smoke to run the method on the given arguments, interestingly 
enough, arguments will be in an
       array of unions or some similar fairly dark magic... */

    /* convert all the results and relevant side effects back to strings 
as appropriate */

    return TCL_OK;
}

The only thing TCL knows about is strings. (Ok, it's a lie, but it is 
much easier to get it this way... Actually TCL "things" (I avoid the 
word objects on purpose here, the C side of TCL is C, not C++) are 
internally typed, but it is only for efficiency reasons, not for use in 
stuff like type-enforcement. As far as types are concerned everything is 
a string, that's it)

I guess with some patience subclassing can be actually made to work, but 
it would be completely simulated, with basically no support from the 
language. So when you do subclassing what happens is that you would have 
to teach Smoke of the existance of a new derived class, and its position 
in the class hierarchy. Then you would have to manually handle virtual 
calls and overloading. Virtual calls don't look too bad, yet overloading 
is not supported by the language (which being untyped wouldn't have a 
clue on what is happening anycase), so would be part of the code of a 
single function with variable argument list.

Does this picture make any sense to you guys? (basically everything 
happens by name through strings)

Lukes

-- 
Luca Fascione
Pipeline Engineer - Weta Digital

+644 388 9307 (x4702) / +64 21 0764 862