That might not always work. If you are providing a library of "classes"
which people can extend, then you should provide them as javascript and
lingo, as you can only extend a lingo Parent script in lingo, and you can
only use a javascript "class" as a prototype for another javascript "class".


It is also the case that lingo cannot contruct javascript objects and vice
versa, although given a reference either language can use objects written in
the other language. Therefore, you should provide factory methods (e.g.
createMyObject()) rather than expecting people to call new MyObject or
script("MyObject").new().

Ben

-----Original Message-----
From: Robert Tweed [mailto:robert-lists@...]
Sent: 10 March 2004 12:14
To: openLingo@yahoogroups.com
Subject: Re: [openLingo] javascript in MX 2004

----- Original Message -----
From: "David Turk" <mediasense@...>
>
> I would wait to DMX 2005 prior to considering JavaScript in a serious way.

JFTR, I think that openLingo should progress as previously forseen, but we
should make sure the flexbility is there that any module can be either Lingo
or ECMAScript, depending on which is most appropriate for the task. For
anyone who is pre-judging one as better than the other, we should bear in
mind that tests people have done on other lists have shown that ECMAScript
is actually quite a bit faster than Lingo in some circumstances. You also
have nice things like regular expressions. However, there are still a couple
of things that don't seem to be quite there yet, so basically it's like
this: given two implementations, one in ECMAScript and one in Lingo, we
simply test to see which is best and use that one.

- Robert




Yahoo! Groups Links