> Date: Thu, 19 Feb 2004 18:52:07 +
> From: Dave Cragg <[EMAIL PROTECTED]>
> Subject: Re: Transcript and/or ECMA - guess who started it?
> To: <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="us-ascii" ;
On Feb 19, 2004, at 4:20 PM, Alex Rice wrote:
That is the javascript Document Object Model. Serious Javascripter
would be less than enthused if this kind of thing were not available.
But overall, I'm not for Javascript. I'll stick with Transcript any day.
--
Alex Rice | Mindlube Software | http:/
On Feb 19, 2004, at 4:04 PM, Thomas McGrath III wrote:
I just checked. If you install JavaScript OSA then it shows up in the
alternateLanguages in REV.
So that tells me a do as javascript is in REV.
Cool!
Something that I haven't seen mentioned in this thread is the
Javascript DOM. Being able
I just checked. If you install JavaScript OSA then it shows up in the
alternateLanguages in REV.
So that tells me a do as javascript is in REV.
On Feb 19, 2004, at 2:18 PM, Dar Scott wrote:
On Thursday, February 19, 2004, at 11:52 AM, Dave Cragg wrote:
For me, executing javascript would be mor
On Thursday, February 19, 2004, at 11:52 AM, Dave Cragg wrote:
For me, executing javascript would be more useful than having it work
with Rev objects.
Same here.
(I may be missing something.)
Dar
___
use-revolution mailing list
[EMAIL PROTECTED]
http
At 12:27 pm -0500 19/2/04, tuviah snyder wrote:
If the "do" languages were to be expanded beyond AppleScript, I think
Javascript should be high on the list of priorities.
It is supported. See the alternatelanguages function.
But this is Mac only, right? (And is there a Javascript option for this?
> If the "do" languages were to be expanded beyond AppleScript, I think
> Javascript should be high on the list of priorities.
It is supported. See the alternatelanguages function. It's not about
executing JavaScript..it's about getting JavaScript to work with Rev
objects, the debugger, and on all
At 12:05 pm -0700 18/2/04, Dar Scott wrote:
On Wednesday, February 18, 2004, at 11:24 AM, jbv wrote:
One might need so support javascript in loaded web pages. That
person will either need to build javascript with Transcript or use
some other method. If it is available among 'do' languages that
p
On Feb 18, 2004, at 3:56 PM, Jim Lambert wrote:
Tha latest version of Director has now added support for Javascript.
The
main reason given is exactly that - the hope that more programmers
will come
into the Director fold. It remains to be seen if this will happen.
Perhaps
RuntimeRev should jus
Ah! my bad and my apologies...I probably didn't read back far
enough...it's just a "hot button" with me after having been involved
with so many companies that just don't know how to *FOCUS*...and thus
never do anything well, let alone excellent. I must've "jumped in" to
the middle of this and
On 2/18/04 12:48 PM, Ops wrote:
True enough Richard, but, I'm sure Rev resources are not unlimited, and
if this is done at a long-term cost to the efficacy of the existing
product, then I'm sure all would agree that those efforts would be
"foot-shooting"...I for one, would like Rev to stay ontr
On Wednesday, February 18, 2004, at 11:24 AM, jbv wrote:
I do understand that some folks might build browser control, but
well... considering the gorgeous perspectives of building web apps
with Rev, I have the feeling that working on a browser ctrl in
javascript
is a big step backwards somehow...
the more Rev/Transcript is used, the more folks in that category
will appreciate and embrace the virtues of current Transcript.
If implented as Tuviah proposed it may actually have the opposite,
beneficial effect: by allowing the world's most popular scripting language
as a switchable option so
Ops wrote:
> the more Rev/Transcript is used, the more folks in that category
> will appreciate and embrace the virtues of current Transcript.
If implented as Tuviah proposed it may actually have the opposite,
beneficial effect: by allowing the world's most popular scripting language
as a switch
This post is slightly OT, but a nice improvement of the Rev
engine (rather than the Transcript interpreter itself) would be
to break its present monolithic nature and split it into various
librairies (a bit like C librairies).
This feature would be irrelevant in the IDE, but when building
standalon
I'm *really* not following the wisdom of all this...to me, IT'S NOT
BROKE (Transcript language-wise)...if this discussion is based in a
desire for current Rev programmers to have Transcript understand a
syntax that they may be more familiar with, then I think it's insane to
accommodate that des
Yes, I remember that feature of HC.
But still, I'm asking the question : I can understand the benefit
of coding in AppleScript in a MacOS environment, but I'm
wondering who might be interested to script a stack in javascript
(I've completed a few sophisticated web apps in javascript and
that was s
On 2/18/04 11:51 AM, jbv wrote:
This is probably a dumb question, but what kind of new world would
open the possibility to script a stack in javascript (for instance) ?
I was thinking of the way HyperCard handled this. There was a popdown
button at the top of the script editor that allowed the au
On Wednesday, February 18, 2004, at 10:51 AM, jbv wrote:
This is probably a dumb question, but what kind of new world would
open the possibility to script a stack in javascript (for instance) ?
Here is one. Folks might be making browser controls. Some might be
HTML subsets. Some might be speci
On Wednesday, February 18, 2004, at 07:05 AM, tuviah snyder wrote:
Each statement needs to start with a verb.
I am so pleased nobody has suggested LET. -- Dar
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/u
>
> > Each statement needs to start with a verb. Rather than break XTalk it would
> > be more practial support JavaScript as an additional language implemented
> > using one of many javascript interpreters available.
>
> This would be awesome, and would allow all sorts of additional
> flexibility.
On 2/18/04 8:05 AM, tuviah snyder wrote:
Of course someone with knowledge of the parser would have to answer this
one...
Each statement needs to start with a verb. Rather than break XTalk it would
be more practial support JavaScript as an additional language implemented
using one of many javascrip
>Of course someone with knowledge of the parser would have to answer this
>one...
Each statement needs to start with a verb. Rather than break XTalk it would
be more practial support JavaScript as an additional language implemented
using one of many javascript interpreters available.
AFAIK JavaScr
Ken Ray wrote/ schreef:
> Actually, Sjoerd, it is probably possible for the parser to understand
> the context so that a different operator may not be needed at all.
Of course this is possible. I just don't like a symbol to have a
context-dependent meaning.
When I read my script aloud, I want to
> Put into works fine. And if you want to have a shorter
> operator for this, use :=, like Pascal. I mean, because of
> using '=' for 'becomes', they had to use '==' (huu, very
> ugly) for a comparison. xTalks handle this nicely ('=' for a
> comparison), so don't clutter the language up with '
MisterX wrote/ schreef:
> local afld=fld "test"
Please don't adopt this ugly C-like syntax...
Put into works fine. And if you want to have a shorter operator for this,
use :=, like Pascal. I mean, because of using '=' for 'becomes', they had to
use '==' (huu, very ugly) for a comparison. xTalks h
Scott started it with /* and */ and // ;)
dont:
local afld=fld "test"
do:
local q=quote
do "local" && varname & " = fld" && q & afieldname & q
XX) (it's a race car)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Rob Cozens
> Sent: Tuesday, Februa
27 matches
Mail list logo
