But I fear for Mr. Waddingham when the citizens storm the Edinburgh
offices with torches and pitchforks after discovering that the code
style they've been using for years is no longer supported. ;)
Odd... I don't recall saying that the short form of object tokens would
be eliminated, I was
Mark Waddingham wrote:
But I fear for Mr. Waddingham when the citizens storm the Edinburgh
offices with torches and pitchforks after discovering that the code
style they've been using for years is no longer supported. ;)
Odd... I don't recall saying that the short form of object tokens would
This sounds and looks just horrible!
I vote to scrap the abbreviations and use the long forms! Should be
easy enough to write a script to translate the short forms to the
long forms, in fact the editor could change them dymanically as you
type, thus getting the best of both worlds!
Just my
David Burgun wrote:
How about if we eliminate both and enforce just a single-character
typing convention for objects and numeric values only for object
identification? That way field 3 of card 7 would come out to f3c7
for a minimum of typing. The engine's parser would, of course,
separate these
David Burgun wrote:
How about if we eliminate both and enforce just a single-character
typing convention for objects and numeric values only for object
identification? That way field 3 of card 7 would come out to f3c7
for a minimum of typing. The engine's parser would, of course,
separate these
David Burgun wrote:
I'm with you: Transcript's existing abbreviations are about as sparse
as I'd like to go.
Yes, I don't really care how they are stored in the script as long as
the editor could expand them to the way the user wants to see them. I
the C/C++ language there are formatters
repeat while(x+1) 10
put word(x+1) of This is a test
Although this is consistent, it still *looks* wrong to me... it looks like
while and word are functions in the example above. Is it just me, or is
this a bug that has been in the engine for a long time?
Well, it's been in the
On 8/26/05 6:02 AM, Mark Waddingham [EMAIL PROTECTED] wrote:
Indeed, the engine is a little too forgiving in places but there are
actually two separate issues here - one related to tokenisation and one
related to parsing.
Thanks for the clarification, Mark... it really helps me understand
Ken-
Friday, August 26, 2005, 7:13:32 AM, you wrote:
How about the opposite? Stop using the *long* form... it means less typing
and you get the same effect (see your subject line)... (he said, dodging
fruit) ;-)
...in that case *all* my stacks would stop working...
fruit
A Modest
Mark Wieder wrote:
Ken-
Friday, August 26, 2005, 7:13:32 AM, you wrote:
How about the opposite? Stop using the *long* form... it means less typing
and you get the same effect (see your subject line)... (he said, dodging
fruit) ;-)
...in that case *all* my stacks would stop working...
On 8/26/05 11:36 AM, Mark Wieder [EMAIL PROTECTED] wrote:
Ken-
Friday, August 26, 2005, 7:13:32 AM, you wrote:
How about the opposite? Stop using the *long* form... it means less typing
and you get the same effect (see your subject line)... (he said, dodging
fruit) ;-)
...in that
Thanks, Mark for those insights on the engine - the more we know how
it works, the more we can get out of rev!
sqb
repeat while(x+1) 10
put word(x+1) of This is a test
Although this is consistent, it still *looks* wrong to me... it looks like
while and word are functions in the
Hi Mark,
f3 c7?
Sunk!
;-)
Le 26 août 05 à 18:36, Mark Wieder a écrit :
A Modest Proposal:
How about if we eliminate both and enforce just a single-character
typing convention for objects and numeric values only for object
identification? That way field 3 of card 7 would come out to f3c7
for
Don't like that. Looks like APL to me. A major point of Transcript is
to be easily HUMAN readable. Consider a rotten apple thrown.
A Modest Proposal:
How about if we eliminate both and enforce just a single-character
typing convention for objects and numeric values only for object
Recently, Lynch, Jonathan wrote:
I want more ways of addressing an object. I could really use an altname
property.
Put 8 into field altname myField
This way I can address a field by either its name or its altname. I have
a definite use for that.
Currently you can address a field by its
Stephen Barncard wrote:
Thanks, Mark for those insights on the engine - the more we know how it
works, the more we can get out of rev!
sqb
repeat while(x+1) 10
put word(x+1) of This is a test
Although this is consistent, it still *looks* wrong to me... it
looks like
while
Lynch, Jonathan wrote:
I want more ways of addressing an object. I could really use an altname
property.
Put 8 into field altname myField
This way I can address a field by either its name or its altname. I have
a definite use for that.
I'll bite: How?
--
Richard Gaskin
Managing Editor,
J. Landman Gay wrote:
Mark Wieder wrote:
How about the opposite? Stop using the *long* form... it means less
typing and you get the same effect (see your subject line)...
A Modest Proposal:
How about if we eliminate both and enforce just a single-character
typing convention for objects and
I want more ways of addressing an object. I could really use an altname
property.
Put 8 into field altname myField
This way I can address a field by either its name or its altname. I have
a definite use for that.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
19 matches
Mail list logo