Le vendredi 08 avril 2011 à 22:18 +0200, Richard Durr a écrit :
I do hope ^^
This makes working with "native" Javascript-Libraries hard (remembers me of how this is done in ObjJ). Does it look *that* hard?
Another problem is the extension of native JS "types" which can conflict with other libraries as well. I have a feeling that his can be solved by using some form of automatic wrapping like underscore.js uses to extend native JS-Arrays: _(someArray).canCallCoolforEachMethodNow() . Yes, but I like the fact that Jtalk maps Smalltalk constructs one-to-one with JS equivalents.
A ST dispatch method (asSmalltalkObject(someJavascriptObject).nowICanCallSmalltalkObjectsMethods() ) could also swap "undefined" and "null" for nil then automatically. However, this would bring a small runtime cost. Switching to a fully externalized and decoupled message-send implementation like in ObjJ would allow DNU then as well. smalltalkMessageSend(someObject, 'doSomething:', anObject);
That's really interesting. Now, again, I would worry about the runtime cost. Jtalk maps message sends to function calls. That's what makes Jtalk fast. Cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr