I'm no expert so correct me if I'm wrong, but as I understand it, constants
are a structurally different kind of thing from variables, and there is a
bit more to it than scripting style preference.
The major difference I don't think anybody has mentioned is that since the
value of a constant is
Hi Martin,
I would see global constants as a worthwhile
addition, and while mimicing them with variables is obviously workable
right now, I don't think it's really equivalent, or as good a solution.
I must note that, while Alex's global constant concept struck a chord
with me, it isn't getting
On 10/25/03 6:05 AM, Martin Baxter wrote:
I'm no expert so correct me if I'm wrong, but as I understand it, constants
are a structurally different kind of thing from variables, and there is a
bit more to it than scripting style preference.
The major difference I don't think anybody has mentioned
In the first case, x must be typed internally as an integer. In the
second case, x must be typed internally as a string.
Programmer error, Jacque: constants 123 and 123 are not the same
and should not be used interchangeably.
--
Rob Cozens
CCW, Serendipity Software Company
On Saturday, October 25, 2003, at 09:49 AM, Rob Cozens wrote:
Programmer error, Jacque: constants 123 and 123 are not the same and
should not be used interchangeably.
Do you mean as compiled? Or as a matter of style?
I have gotten the impression that these are exactly equivalent. When
used
Programmer error, Jacque: constants 123 and 123 are not the same
and should not be used interchangeably.
Do you mean as compiled? Or as a matter of style?
I have gotten the impression that these are exactly equivalent.
When used in arithmetic in a handler, the value is converted to
internal
This is the best argument I've seen for global constants. I get it.
sqb
The major difference I don't think anybody has mentioned is that since the
value of a constant is known at compile time, it can be inserted directly
into the resulting object code. So the value has only to be looked up once
On Saturday, October 25, 2003, at 10:39 AM, Rob Cozens wrote:
Programmer error, Jacque: constants 123 and 123 are not the same
and should not be used interchangeably.
Do you mean as compiled? Or as a matter of style?
I have gotten the impression that these are exactly equivalent. When
used in
this is exactly what Compilit! gave to Hypercard -- and allowed one
to create externals to do anything...faster..in Hypertalk code.
Tom Pittman, where are you now?
It occurs to me that, for what I want to accomplish, perhaps my
focus should be more on compiler directives or symbol tables than
On Saturday, October 25, 2003, at 11:07 AM, Stephen Quinn Barncard
wrote:
This is the best argument I've seen for global constants. I get it.
sqb
The major difference I don't think anybody has mentioned is that
since the
value of a constant is known at compile time, it can be inserted
On Saturday, October 25, 2003, at 08:58 AM, Rob Cozens wrote:
In essence, what I want is the ability to declare symbol names
values to the compiler. If support for data structures and tool box
names were included in such symbol tables, we would be one step closer
to supporting direct access
Martin Baxter wrote:
The major difference I don't think anybody has mentioned is that since the
value of a constant is known at compile time, it can be inserted directly
into the resulting object code. So the value has only to be looked up once
- at compile time - whereas a variable always
On Saturday, October 25, 2003, at 11:15 AM, Dar Scott wrote:
A year ago I ran some tests that did some timing measurements that
demonstrate a little about constants. I don't know if I have it
around. Maybe I can reconstruct that. The behavior might not be the
same today, anyway.
The button
I don't see how a compiled script can see a constant as other than a
special global variable that cannot be changed.
I could address this a little better in relation to HyperCard...where
I at least thought I understood what was interpreted and what was
compiled and when.
A compiled script
On Saturday, October 25, 2003, at 02:33 PM, Rob Cozens wrote:
I don't see how a compiled script can see a constant as other than a
special global variable that cannot be changed.
I could address this a little better in relation to HyperCard...where
I at least thought I understood what was
On Saturday, October 25, 2003, at 03:13 PM, Rob Cozens wrote:
Transcript already allows a rich representation of values and is
suitable for representing values to be configured as structures or
whatever for system calls.
OK, Dar, show me and I will grovel in mortification...especially if it
The button script below indicates that an unquoted numeral value for
a constant is basically the same as a quoted numeral.
Which is basically a result of XTalk's aversion to variable typing, sez I.
Does this mean both Jacque and I were wrong in our assessments, Dar?
Looking back on all the time
To keep this discussion simple, this can represented in XML format.
How would one get values for pointers, handles, and addresses of call
back routines via Transcript, Dar?
--
Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.net/who.htm
And I, which was two fooles, do so grow
On Saturday, October 25, 2003, at 04:10 PM, Rob Cozens wrote:
To keep this discussion simple, this can represented in XML format.
How would one get values for pointers, handles, and addresses of call
back routines via Transcript, Dar?
Ow!
Handles can be simply numbers. They have no use except
On Saturday, October 25, 2003, at 04:02 PM, Dar Scott wrote:
...and notice, I didn't even ask you to address the issue of passing
a pointer as an argument. :{`)
That should fall out in the above scheme.
I clicked the wrong something in the middle of writing this and the
above was sent
Martin Baxter wrote:
The major difference I don't think anybody has mentioned is that since the
value of a constant is known at compile time, it can be inserted directly
into the resulting object code. So the value has only to be looked up once
- at compile time - whereas a variable always
Dar Scott wrote:
I don't see how a compiled script can see a constant as other than a
special global variable that cannot be changed.
Well I'm wading deeper into my ignorance here but I guess that from the
compiler's point of view a constant would presumably look the same way that
a variable
On 10/24/03 9:52 AM, Rob Cozens wrote:
I have no doubt this is workable; but I see nothing here to convince me
that a cat skinned your way is necessarily better or worse than a cat
skinned my way.
Nope. My only point is that there is already a reasonable way to
implement global constants, and
Regarding using custom properties as global constants. I understand one of
the issues here is the possibility of the program (or other programmer)
modifying the 'constant' --in this case the custom prop. But, one could
easily envision a setProp handler which would make this impossible.
I use
Le jeu 23/10/2003 04:20, J. Landman Gay a crit :
On 10/22/03 8:44 PM, Stephen Quinn Barncard wrote:
But wouldn't a custom property, which can only be modified using the
IDE, a script or the message box be more of what you want than a
constant (which would have to be defined anyway in a
sez [EMAIL PROTECTED]:
On Tuesday, October 21, 2003, at 12:16 PM, Dar Scott wrote:
On Tuesday, October 21, 2003, at 12:08 PM, Alex Rice wrote:
Maybe I should be submit a feature request?
Joel and Rob- I think a global constant feature would be a really
good enhancement request.
It is not
Although incorporate any changes in myConstantList.txt at runtime
maybe too much to hope for- would the script have to recompile
whenever the file is changed?
Hi again, Alex.
Since I don't fully understand how Revolution's interpreter/compiler
work,I'm inclined to agree with you. Probably the
Rob Cozens wrote:
I'm afraid I don't see any need for global
constants when we've got custom properties that can do essentially the
same thing.
Hi Jacque,
Do you really see custom properties as the preferred means of
declaring constants? Suppose pi was not a built-in constant. Would
Although incorporate any changes in myConstantList.txt at runtime
maybe too much to hope for- would the script have to recompile
whenever the file is changed?
Alex, et al:
Ideally (?), include file references would be resolved at startup or
the first time each script containing an include
On 10/23/03 7:05 AM, Rob Cozens [EMAIL PROTECTED] wrote:
Do you really see custom properties as the preferred means of
declaring constants? Suppose pi was not a built-in constant. Would
you get the piConstant of this stack for every stack that used pi?
Would you get the piConstant of stack
Good morning, Richard.
I understand where you Jacque are coming from storing constants as
stack properties; but the more I think about it, the more I see the
wisdom of Alex's global constants.
One can define the scope of variables:
global myGlobalVariable
local
On Thursday, October 23, 2003, at 03:04 AM, Pierre Sahores wrote:
The same feeling here : unneed keywords may add unneed confusion in the
ways we can get the best from transcript
Judging from a lot of responses to this thread, we may as well throw
out constant, and global keywords as well
Judging from a lot of responses to this thread, we may as well throw
out constant, and global keywords as well because we can just
use custom properties for every variable.
Alex, et al:
In general, I am not persuaded to drop the quest to see a particular
feature implemented correctly just
Judging from a lot of responses to this thread, we may as well throw
out constant, and global keywords as well because we can just
use custom properties for every variable.
While the resulting functionality may be perceived to be the same,
the underlying mechanisms are different. Each has it's
On 10/23/03 9:05 AM, Rob Cozens wrote:
Hi Jacque,
Do you really see custom properties as the preferred means of declaring
constants? Suppose pi was not a built-in constant. Would you get the
piConstant of this stack for every stack that used pi? Would you get
the piConstant of stack
On Thursday, October 23, 2003, at 09:23 AM, Rob Cozens wrote:
Judging from a lot of responses to this thread, we may as well throw
out constant, and global keywords as well because we can just use
custom properties for every variable.
While the resulting functionality may be perceived to be
On Thursday, October 23, 2003, at 08:43 AM, Alex Rice wrote:
I was being sarastic when I made that suggestion :-)
I usually never make a comment about typo errors mainly because I do it
so often myself, but...
If you are sarastic perhaps you should check your ass into an emergency
room real
On Thursday, October 23, 2003, at 09:51 AM, Mark Brownell wrote:
On Thursday, October 23, 2003, at 08:43 AM, Alex Rice wrote:
I was being sarastic when I made that suggestion :-)
I usually never make a comment about typo errors mainly because I do
it so often myself, but...
If you are
I was being sar[c]astic when I made that suggestion :-)
I eventually picked up that tone when rereading your message, Alex;
but I wasn't.
Your syntax, fleshed out to include local constants so constants can
persist across the same scopes as variables, makes sense to me and
eliminates my main
Jacque, et al:
* My primary constant list is, in effect, an index to lines of text
in a file and/or variable. It is there to facilitate handler
readability, comprehension, and debugging.
Example:
constant badInputWarning = 244
answer sdbMessage(badInputWarning)
tells me a lot more than
On 10/23/03 12:13 PM, Rob Cozens wrote:
Jacque, et al:
* My primary constant list is, in effect, an index to lines of text in a
file and/or variable. It is there to facilitate handler readability,
comprehension, and debugging.
Example:
constant badInputWarning = 244
answer
Joel and Rob- I think a global constant feature would be a really
good enhancement request.
It is not clear to me what this would look like. Would this go into
the first stack, as startup does?
Just like global vars can't be declared outside any handlers, global
constants could not either.
global constant kVersion=1.234
and have kVersion be so defined in script in the entire project.
One can accomplish most of this today:
constant kVersion=1.234
The downside here is one has defined a constant that can be
changed, and even globals need to be defined in each script that uses
On Wednesday, October 22, 2003, at 07:44 AM, Rob Cozens wrote:
One can accomplish most of this today:
constant kVersion=1.234
The downside here is one has defined a constant that can be changed,
and even globals need to be defined in each script that uses them.
Err- not really the same
On Wednesday, October 22, 2003, at 09:23 AM, Alex Rice wrote:
Like global, it would be usable in all scripts.
Unlike global, it would not have to be declared in each handler using
it.
Like constant, it would be directly usable in any handler that wants
it.
Would each script that uses it, but
On Wednesday, October 22, 2003, at 09:23 AM, Alex Rice wrote:
Like global, it would be usable in all scripts.
Unlike global, it would not have to be declared in each handler using it.
Like constant, it would be directly usable in any handler that wants it.
Would each script that uses it, but not
On Wednesday, October 22, 2003, at 04:56 PM, Robert Brenstein wrote:
The latter might not be correct. At least I haven't managed to get it
working that way, so I consider it a glitch in documentation.
Details of usage Rev team can figure out better than us.
Works for me:
global g
on doit
Please excuse the obvious, but can't a custom property, say in the
main stack, act as a global constant? Set it in the IDE and it will
persist through standalone creation forever...
sqb
On Wednesday, October 22, 2003, at 09:23 AM, Alex Rice wrote:
Like global, it would be usable in all
On Wednesday, October 22, 2003, at 05:36 PM, Stephen Quinn Barncard
wrote:
Please excuse the obvious, but can't a custom property, say in the
main stack, act as a global constant? Set it in the IDE and it will
persist through standalone creation forever...
Nope, the custom property can be
On Wednesday, October 22, 2003, at 05:36 PM, Stephen Quinn Barncard
wrote:
Please excuse the obvious, but can't a custom property, say in the
main stack, act as a global constant? Set it in the IDE and it will
persist through standalone creation forever...
You are quite right. I left that
Lokking at all the various options, my vote goes for accessor functions.
They keep the value assignments in one place, are universally accessible,
and can be done easily.
I like the global constant option for the future, though. Simple,
elegant...
--
Richard Gaskin
Fourth World Media
But wouldn't a custom property, which can only be modified using the
IDE, a script or the message box be more of what you want than a
constant (which would have to be defined anyway in a script which
would have to be run) ?
The property is just there, with nothing to do to set it, and
On Wednesday, October 22, 2003, at 04:56 PM, Robert Brenstein wrote:
The latter might not be correct. At least I haven't managed to get
it working that way, so I consider it a glitch in documentation.
Details of usage Rev team can figure out better than us.
Works for me:
global g
on doit
On Wednesday, October 22, 2003, at 07:44 PM, Stephen Quinn Barncard
wrote:
doesn't this make a 'constant global'? -- One has to trust one's own
code somewhere, even if you had constants in Rev, they wouldn't be any
different than a variable as far as Rev cares -- it's still places
data in
On 10/22/03 8:44 PM, Stephen Quinn Barncard wrote:
But wouldn't a custom property, which can only be modified using the
IDE, a script or the message box be more of what you want than a
constant (which would have to be defined anyway in a script which would
have to be run) ?
The property is
: http://www.sonsothunder.com/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Joel Rees
Sent: Wednesday, October 22, 2003 11:21 PM
To: How to use Revolution
Subject: Re: cross-stack globals, also, file inclusion
Global constant proponents
Hi, Rob, and thanks for the comments ...
Is there an easy way to set up something similar to file inclusion?
Not that I've found or read of so far...and it would be nice if one existed.
Example: Serendipity Library defines about 265 constants; but much
of the code independence is lost
On Monday, October 20, 2003, at 10:57 PM, Joel Rees wrote:
Rob wrote:
Example: Serendipity Library defines about 265 constants; but much
of the code independence is lost because a constant must be defined
in each script that uses it rather than in a master list that can be
included in each
On Tuesday, October 21, 2003, at 12:08 PM, Alex Rice wrote:
Maybe I should be submit a feature request?
Joel and Rob- I think a global constant feature would be a really
good enhancement request.
It is not clear to me what this would look like. Would this go into
the first stack, as startup
On Tuesday, October 21, 2003, at 12:16 PM, Dar Scott wrote:
On Tuesday, October 21, 2003, at 12:08 PM, Alex Rice wrote:
Maybe I should be submit a feature request?
Joel and Rob- I think a global constant feature would be a really
good enhancement request.
It is not clear to me what this would
On Tuesday, October 21, 2003, at 12:39 PM, Alex Rice wrote:
global constant kVersion=1.234
and have kVersion be so defined in script in the entire project.
Hmmm. This will require a decision on what is done if there is a
conflict since all scripts are compiled independently. Would this also
On Tuesday, October 21, 2003, at 12:53 PM, Dar Scott wrote:
On Tuesday, October 21, 2003, at 12:39 PM, Alex Rice wrote:
global constant kVersion=1.234
and have kVersion be so defined in script in the entire project.
Hmmm. This will require a decision on what is done if there is a
conflict
On Tuesday, October 21, 2003, at 12:53 PM, Dar Scott wrote:
On Tuesday, October 21, 2003, at 12:39 PM, Alex Rice wrote:
global constant kVersion=1.234
and have kVersion be so defined in script in the entire project.
Hmmm. This will require a decision on what is done if there is a
conflict
Hello Joel,
Is there an easy way to set up something similar to file inclusion?
Not that I've found or read of so far...and it would be nice if one existed.
Example: Serendipity Library defines about 265 constants; but much
of the code independence is lost because a constant must be defined
64 matches
Mail list logo
