[Pharo-project] jtalk fun

Richard Durr richard.durr at googlemail.com
Fri Apr 22 16:20:34 CEST 2011

On Mon, Apr 18, 2011 at 9:51 AM, Nicolas Petton <petton.nicolas at gmail.com>wrote:
> >
> > This makes working with "native" Javascript-Libraries hard (remembers
> > me of how this is done in ObjJ).
> Does it look *that* hard?
Yes, it makes me work with Javascript and not Smalltalk. Well maybe hard is
not the real word, ugly fits better.

> > 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.

Yeah, that is obviously nice but the change would be invisible to the
smalltalk user.

> > 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.

In a trivial test I did with Objective J, it did cost about half of the
speed, but gives sending to null and undefined as well als DNU.

Sigh. It would be so cool to have the compatability of CoffeeScript with the
Synta and Functionality of Smalltalk without having to write JS.^^

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110422/bf19672d/attachment.htm>

More information about the Pharo-project mailing list